คำนวณ Story Points ฟรี!

Story points คือหน่วยวัดที่ใช้ใน agile development เพื่อบอกว่า user story หรืองานชิ้นนึงต้องใช้ effort แค่ไหน แทนที่จะนับเป็นชั่วโมง story points เป็นแบบ relative นะ — มันบอกว่างานชิ้นนี้ใหญ่แค่ไหนเมื่อเทียบกับงานที่ทีมเคยทำมาแล้ว แทนที่จะพยากรณ์ว่าจะใช้เวลาเท่าไหร่ตรงๆ

ความแตกต่างนี้สำคัญมากในทางปฏิบัติเลย การประมาณเป็นชั่วโมงสร้าง commitment โดยนัย — ถ้า dev ประมาณงานว่า "สี่ชั่วโมง" แต่ใช้เวลาแปดชั่วโมง ทั้ง dev และ stakeholder ก็จะรู้สึกว่ามีอะไรผิดพลาด Story points หลบกับดักนี้เลย story ที่ประมาณ 5 points กับ story ที่ประมาณ 3 points ควรมีสัดส่วน effort ใกล้เคียงกัน — แต่ไม่มีตัวเลขไหนที่บอกว่าต้องใช้กี่ชั่วโมงทำงาน

Story points จับสามมิติพร้อมกันเลย: ปริมาณงาน, complexity (ยากแค่ไหนที่จะ implement ให้ถูกต้อง?), และความไม่แน่นอน (เราเข้าใจสิ่งที่ต้องทำดีแค่ไหน?) story อาจมีปริมาณงานน้อยแต่ complexity สูง — เช่น ต้องแตะ legacy system ที่เปราะบางและไม่มี documentation — ก็ควรได้ point สูงขึ้นเพื่อสะท้อนความยากนั้น ส่วน CRUD endpoint ตรงๆ อาจต้องพิมพ์เยอะแต่ความไม่แน่นอนน้อย ก็ควร size ตามนั้น

เมื่อเวลาผ่านไป ทีมจะสะสม velocity — จำนวน story points เฉลี่ยที่ทำเสร็จต่อ sprint velocity กลายเป็นเครื่องมือ forecast ที่น่าเชื่อถือ: ถ้าทีม average 32 points ต่อ sprint และ backlog ที่เหลือรวม 128 points ก็ประมาณได้ว่าต้องใช้อีกสี่ sprint เพื่อถึงเป้า release ได้เลย ทั้งนี้ทำงานได้ก็ต่อเมื่อการประมาณสม่ำเสมอและซื่อสัตย์ นั่นคือเหตุผลที่ planning poker technique — กับการเปิดการ์ดพร้อมกัน — ออกแบบมาเพื่อปกป้องความน่าเชื่อถือของการประมาณนั่นเอง

facilitator อ่าน user story ออกเสียง — หรือวางไว้ใน description ของห้อง — แล้วตอบคำถาม clarify เบื้องต้น จากนั้นแต่ละคนเลือกการ์ดจาก deck ของตัวเองแบบ private เพื่อแสดง effort estimate พอทุกคนโหวตแล้ว การ์ดทุกใบก็เปิดพร้อมกันเลย

ถ้าโหวตทุกคนกระจุกอยู่ในหนึ่งหรือสองค่า ทีมก็ consensus แล้วสามารถใช้ค่า median หรือสูงสุดเป็น estimate ของ story ได้เลย แต่ถ้ากระจายกว้าง — สมมติมีคนโหวต 2 กับคนโหวต 13 — facilitator จะถามทั้งสองฝั่งให้อธิบาย reasoning นี่คือส่วนที่มีคุณค่ามากที่สุดของ process เลยนะ คนที่โหวตต่ำอาจมี implementation ที่ง่ายกว่าในใจ ส่วนคนที่โหวตสูงอาจรู้ถึง dependency หรือ edge case ที่คนอื่นไม่รู้ หลังถกกันแล้วก็โหวตใหม่จนได้ consensus

ทั้ง process มี time-box นะ story นึงแทบไม่ควรใช้เวลาเกินห้าถึงสิบนาทีในการประมาณ ถ้าถกกันไปเรื่อยๆ โดยไม่ได้ consensus มักเป็นสัญญาณว่าควร table story นั้นไว้ก่อน นัด refinement session แยกกับ product owner แล้วค่อยไปต่อ