15 กุมภาพันธ์ 2026 · โดย รักษิต หนองบัว
Story Points vs Hours: ทีมของคุณควรใช้อะไรดี?
ในวงการ Agile แทบไม่มีหัวข้อไหนที่จะถูกถกเถียงกันยาวนานและเผ็ดร้อนเท่ากับคำถามที่ว่า "ควรประเมินงานเป็น Story Points หรือชั่วโมงดี?" ทั้งสองฝั่งต่างมีเหตุผลที่น่ารับฟัง ความจริงก็คือไม่มีคำตอบที่ถูกที่สุดสำหรับทุกคน แต่ขึ้นอยู่กับขนาดทีม ความเป็นมืออาชีพ ความสัมพันธ์กับลูกค้า และเป้าหมายของการประเมินงานของคุณ บทความนี้จะเจาะลึกทั้งสองแนวทางเพื่อให้คุณตัดสินใจได้อย่างถูกต้อง
Story Points คืออะไร?
Story Points คือหน่วยวัด "ความพยายามสัมพัทธ์" (Relative Effort) ความซับซ้อน และความเสี่ยงในการทำงานให้สำเร็จ คำสำคัญคือ "สัมพัทธ์" งาน 5 แต้มไม่ใช่ 5 ชั่วโมง หรือ 5 วัน แต่มันหมายความว่าทีมเชื่อว่างานนี้ยากกว่างาน 1 แต้มประมาณ 5 เท่า และยากน้อยกว่างาน 8 แต้มเล็กน้อย
Story Points จะขึ้นอยู่กับบริบทของแต่ละทีมโดยเฉพาะ งาน 5 แต้มของทีมอาวุโส 8 คน ย่อมต่างจากงาน 5 แต้มของทีมรุ่นใหม่ 3 คน ซึ่งนี่ไม่ใช่ข้อเสียแต่มันคือ "ฟีเจอร์" เพราะทีมจะติดตาม Velocity (จำนวนแต้มที่ทำเสร็จต่อสปริ้นท์) ของตัวเองและใช้มันเป็นฐานในการคาดการณ์สปริ้นท์ถัดไป
ข้อดีที่สำคัญคือ Story Points จะไม่พังเมื่อมีการเปลี่ยนสมาชิกในทีม หากมีวิศวกรคนใหม่เข้ามา Velocity จะค่อยๆ ปรับตัวตามธรรมชาติในหนึ่งหรือสองสปริ้นท์ โดยไม่ต้องมานั่งปรับจูนคะแนนประเมินใหม่ทั้งหมดใน Backlog
การประเมินแบบชั่วโมง (Hour-Based) คืออะไร?
การประเมินแบบชั่วโมงคือสิ่งที่เราคุ้นเคยกันดี: งานแต่ละชิ้นจะถูกระบุเวลาที่คาดว่าจะใช้จริง เช่น งานนี้ใช้เวลา 8 ชั่วโมง หรือประมาณหนึ่งวันทำงานของนักพัฒนา
ในทางทฤษฎี การประเมินแบบชั่วโมงควรจะนำไปใช้ได้กับทุกคน (Portable) งาน 8 ชั่วโมงควรจะใช้เวลาเท่ากันไม่ว่าใครจะทำ แต่ในทางปฏิบัติมันแทบจะไม่เป็นความจริง เพราะนักพัฒนาแต่ละคนมีความเร็วและความชำนาญในแต่ละส่วนของ Codebase ไม่เท่ากัน
เสน่ห์ของการประเมินเป็นชั่วโมงคือความ "รูปธรรม" ผู้บริหารหรือลูกค้าที่คุ้นเคยกับการคิดค่าจ้างตามเวลาทำงานจะเข้าใจได้ทันทีว่า "ฟีเจอร์นี้ใช้เวลา 80 ชั่วโมง" ซึ่งนำไปคำนวณงบประมาณและวางแผนทรัพยากรได้ง่ายกว่า Story Point
ทำไมทีม Agile ส่วนใหญ่ถึงชอบ Story Points?
ทีม Agile ที่มีประสบการณ์ส่วนใหญ่มักจะลงเอยที่การใช้ Story Points หลังจากได้ทดลองใช้แบบชั่วโมงมาแล้ว นี่คือ 5 เหตุผลสำคัญ
1. ชั่วโมงคือ "คำสัญญา" แต่แต้มคือ "การคาดการณ์"
เมื่อนักพัฒนาบอกว่า "งานนี้ใช้เวลา 8 ชั่วโมง" คนฟังมักจะถือว่าเป็นคำมั่นสัญญา หากทำจริงใช้ 12 ชั่วโมง จะถูกมองว่า "ประเมินผิด" ทันที สิ่งนี้เปลี่ยนการประเมินงานให้เป็นการประเมินผลงาน (Performance Evaluation) ซึ่งทำให้คนประเมินต้องเผื่อเวลา (Pad estimates) เพื่อป้องกันตัวเอง แต่ Story Points ไม่มีภาระทางใจนี้เพราะมันไม่ใช่หน่วยเงินเดียวกับเงินเดือนหรือกำหนดส่งงาน
2. มนุษย์เก่งในการเปรียบเทียบมากกว่าการประเมินค่าคงที่
งานวิจัยทางจิตวิทยาพบว่ามนุษย์เก่งในการ "เปรียบเทียบ" สิ่งสองสิ่งว่าอันไหนใหญ่กว่ากัน การถามว่า "งานนี้ยากกว่างานที่แล้วไหม?" เป็นคำถามที่นักพัฒนาตอบได้แม่นยำกว่าการถามว่า "งานนี้ต้องใช้กี่ชั่วโมง?" ซึ่งขึ้นอยู่กับปัจจัยที่ควบคุมไม่ได้หลายอย่าง
3. Velocity มีความเสถียรกว่าในระยะยาว
การใช้ Story Points ช่วยให้ทีมเห็น Velocity ที่นิ่งได้ภายใน 3-5 สปริ้นท์ ในขณะที่การประเมินเป็นชั่วโมงมักจะพลาดเรื่องเวลาประชุม การรีวิวโค้ด หรือการสลับบริบทงาน (Context switching) ทีมที่ใช้ชั่วโมงมักพบว่า "เวลาที่ใช้จริง" สูงกว่าที่ประเมินไว้ 40-60% เสมอ
4. โฟกัสที่ความซับซ้อน ไม่ใช่ความเร็วของรายบุคคล
การประเมินเป็นชั่วโมงมักจะเผลอประเมินตามตัวบุคคล เช่น "ถ้าแอนทำใช้ 4 ชม. แต่ถ้าบอมทำใช้ 8 ชม." สิ่งนี้ทำให้การวางแผนยากขึ้น แต่ Story Points วัดความยากของ "ตัวงาน" เอง ไม่ว่าใครจะเป็นคนทำความยากของเนื้องานก็ยังเท่าเดิม
5. ต้นทุนการประเมินใหม่ต่ำกว่า
Backlog มีการเปลี่ยนแปลงตลอดเวลา หากใช้ Story Points คะแนนประเมินคร่าวๆ ในตอนแรกจะยังคงมีประโยชน์แม้จะมีการปรับรายละเอียดงานไปบ้าง แต่ถ้าใช้ชั่วโมง การเปลี่ยนแปลงเพียงเล็กน้อยอาจทำให้ตัวเลขเดิมใช้ไม่ได้เลยและต้องมานั่งประเมินใหม่ทั้งหมด
เมื่อไหร่ที่การประเมินเป็น "ชั่วโมง" เมคเซนส์กว่า?
แม้ Story Points จะมีข้อดีมาก แต่ในบางบริบท การประเมินเป็นชั่วโมงก็เป็นเครื่องมือที่ถูกต้องกว่า
การคิดเงินลูกค้าตามเวลาทำงานจริง (Time & Materials) หากคุณต้องส่งใบแจ้งหนี้ตามชั่วโมงทำงาน คุณจำเป็นต้องเก็บสถิติชั่วโมงจริง Story Points ไม่สามารถนำไปใส่ในใบแจ้งหนี้ได้โดยตรง
ข้อกำหนดทางกฎหมายหรือการตรวจสอบ (Compliance) บางอุตสาหกรรม เช่น งานภาครัฐหรือการเงิน มีข้อกำหนดให้ต้องลงบันทึกเวลาทำงานในระดับ Task เพื่อการตรวจสอบ (Audit)
สัญญา SLA ที่ระบุเวลาการแก้ไขงานชัดเจน หากสัญญาบอกว่า "ต้องแก้ Bug ภายใน 48 ชั่วโมง" ทีมจำเป็นต้องประเมินและวางแผนงานตามเวลาในปฏิทินจริง
ทีมขนาดเล็กมากหรือโปรเจ็กต์คนเดียว ถ้าคุณทำงานคนเดียวหรือมีกันแค่สองคน การใช้ Story Points อาจเพิ่มความยุ่งยากเกินความจำเป็น การใช้ชั่วโมงอาจจะง่ายและได้ผลลัพธ์ใกล้เคียงกัน
ใช้ทั้งคู่ได้ไหม?
ได้ครับ — และทีมที่มีวุฒิภาวะหลายทีมก็ทำแบบนั้น โดยใช้แต่ละระบบตามวัตถุประสงค์ของมัน หัวใจสำคัญคือต้องแยกสองระบบนี้ออกจากกัน และห้ามสร้าง "สูตรแปลงแต้มเป็นชั่วโมง" เด็ดขาด
ความล้มเหลวที่มักจะเกิดคือการที่ทีมเริ่มคำนวณว่า "1 แต้มเท่ากับกี่ชั่วโมง" เพื่อไปคุยกับลูกค้า สิ่งนี้จะทำลายข้อดีของ Story Points ไปทันทีและเพิ่มงานซ้ำซ้อน หาก Stakeholder ถามว่า "1 แต้มคือการทำงานกี่ชั่วโมง?" คำตอบควรจะเป็น "มันแปรผันตามแต่ละสปริ้นท์และปัจจัยอื่นๆ" ไม่ใช่ตัวเลขตายตัว
วิธีเปลี่ยนจากชั่วโมงมาใช้ Story Points
Step 1
หา "งานอ้างอิง" เพื่อใช้เป็นเกณฑ์
หางานที่ทำเสร็จไปแล้วที่ทุกคนยอมรับว่ามีความยากระดับ "ปานกลาง" แล้วกำหนดให้เป็น 5 แต้ม งานถัดไปทั้งหมดจะถูกเปรียบเทียบกับงานชิ้นนี้
Step 2
รันควบคู่กันไปในช่วง 2 สปริ้นท์แรก
ประเมินทั้งแบบแต้มและชั่วโมงไปก่อน แต่ใช้ชั่วโมงเป็นเพียง "ตาข่ายนิรภัย" ทางจิตใจเท่านั้น เมื่อทีมเริ่มมั่นใจค่อยตัดการประเมินแบบชั่วโมงออกไป
Step 3
ห้ามแปลง Velocity ในช่วงแรกกลับเป็นชั่วโมง
อย่ารีบคำนวณว่า "1 แต้ม = 7.6 ชั่วโมง" ในช่วงแรกๆ เพราะข้อมูล Velocity จะยังไม่นิ่งพอ และมันจะทำให้ทีมกลับไปติดหล่มปัญหาเดิมๆ
Step 4
สื่อสารการเปลี่ยนแปลงกับผู้เกี่ยวข้องให้ชัดเจน
อธิบายว่าทีมกำลังเปลี่ยนไปใช้ระบบคาดการณ์ที่แม่นยำกว่า ซึ่งอิงจากข้อมูลจริงในอดีต (Empirical data) แทนที่จะเป็นการเดาเวลาล่วงหน้า
บทสรุป
สำหรับทีมพัฒนาส่วนใหญ่ Story Points คือเครื่องมือประเมินงานที่ดีกว่า เพราะช่วยให้เกิดการพูดคุยถึงความซับซ้อนของงานอย่างซื่อสัตย์ และช่วยให้การคาดการณ์อนาคตแม่นยำขึ้นในระยะยาว
ใช้ชั่วโมงเฉพาะเมื่อมีพันธะภายนอกบังคับจริงๆ เช่น เรื่องการคิดเงินหรือข้อกฎหมาย และหากต้องใช้ ให้ใช้มันควบคู่ไปกับ Story Points โดยแยกวัตถุประสงค์ให้ชัดเจน
ไม่ว่าคุณจะเลือกอะไร สิ่งที่มีค่าที่สุดไม่ใช่ตัวเลข แต่คือ "การที่ทีมได้นั่งคุยรายละเอียดงานด้วยกัน" การทำ Planning Poker ที่ทำให้เห็นจุดยากที่ซ่อนอยู่ถือเป็นความสำเร็จแล้ว แม้ผลการประเมินสุดท้ายจะคลาดเคลื่อนไปบ้างก็ตาม
เริ่มประเมินงานกับทีมของคุณ