แนวคิดที่ไม่ควรใช้กับ Story Point
Published in
2 min readOct 6, 2019
Story Point ถือว่าเป็นตัวช่วยให้ทีมสามารถประเมิน Story ได้ด้วยหลัก Relative estimation ที่ประเมิน story point ด้วยการเปรียบเทียบจากขนาดของ Story ที่มีขนาดคล้ายคลึงกันนั่นเอง ถ้าทีมไหนได้ใช้ไประยะหนึ่งก็จะสามารถใช้ได้อย่างถูกต้อง แต่ก็พบว่ามีหลายทีมมีความเข้าใจผิดในเรื่องของ Story Point เหมือนกัน ซึ่งสามารถสรุปได้คร่าวๆ ดังนี้
- การนำ Story point ไประบุค่า(Value) ของโพรดัคส์
โดยปกติแล้วทีมประเมิน Story point จากการความยากง่าย ความซับซ้อนที่จะทำการพัฒนาออกมาเป็นตัวเลข แต่ตัวเลขที่ได้นี้ไม่ใช่ตัวระบุ Value ของ Story นะจ๊ะ สิ่งที่จะระบุค่าของ Story point คือ Business Value จาก Product Owner เท่านั้น - พยายามแปลง Story point ไปสู่ “ชั่วโมง”
ก่อนอื่นขอแจ้งไว้ก่อนว่าการแปลง Story point เป็นชั่วโมงเป็นสิ่งที่ไม่ผิด แต่การที่นำ “ชั่วโมง” มาใช้กับ Story point ก่อให้เกิดความเสี่ยงในการประเมินมากกว่าเพราะว่า requirement อาจเปลี่ยนแปลงได้และไม่สมบูรณ์ และตัวเลขที่ได้นั้นจะผิดพลาดได้มากกว่า การใช้การประเมินแบบ Relative estimation รวมทั้งสร้างความกดดันให้กับทีมอีกด้วย - โหวต Story point แบบให้จบๆ ไป
หลายครั้งที่เวลาโหวด Story point แล้วเกิดมีการโหวดเท่านั้นระหว่างตัวเลข เช่น โหวด 4 points:4 คน , 5 points:4 คน หลายทีมจะชอบเปลี่ยนเลขโหวตเพื่อให้ point ใด point หนึ่งชนะเสมอโดยไม่มีการต่อรองหรือชี้แจง การคิดแบบนี้อาจส่งผลให้ทีมไม่ได้แสดงว่าคิดเห็นจริงๆ และอาจตัดสินใจผิดพลาดในการให้ story point ที่ถูกได้ - เปลี่ยนแปลง Story point ใน Sprint
เมื่อทีมเริ่มทำงานใน Sprint แล้วเจอปัญหา ทีมไม่ควรปรับคะแนนของ Story Pointถึงแม้ว่าการประเมินของพวกทีมจะไม่ถูกต้อง และสุดท้าย Velocity รวมจะอยู่ในท้ายของ Sprint เอง และในที่สุดการประเมินทั้งหมดใน Sprint จะเป็น History ที่ใช้ระบุความเร็วในอดีตของทีมนั่นเอง - กำหนด Story Point ให้ Defect
เมื่อเจอ Defect ในระหว่างพัฒนา software ทีมไม่ควรให้ Story point แก่ Defect นั้นเนื่องจาก Story point ได้ถูกประเมินไปใน Story ที่เกิด Defect แล้ว ดังนั้นการแก้ไข Defect จึงเป็นความรับผิดชอบของ Developer ที่จะทำการแก้ไขปัญหาและส่งงานให้ทันตาม Time boxed โดยไม่ได้ Story point จ๊ะ - เพิ่ม Task เข้าใน Sprint พร้อม Story point
ในบางครั้งทีมมีงานด่วนที่ต้องการวิเคราะห์ และหา root cause ของปัญหาที่สามารถทำเสร็จได้ภายใน Sprint ในกรณีนี้ทีมไม่จำเป็นต้องเพิ่ม Story point ให้กับ Task และควรสร้าง Task ให้กับงานประเภทนี้ไม่ใช่สร้าง Story นะจ๊ะ - แก้ไข Story Point ของ Story ที่ทำไม่เสร็จใน Sprint ที่ผ่านมา
ถ้าทีมไม่สามารถทำ Story ให้เสร็จได้ภายใน Sprint เราไม่จำเป็นต้องแก้ไข Story point ก่อนนำไปไว้ที่ Product Backlog แล้วเนื่องจากเราถือว่าจบ Sprint แล้วเราวัดกันที่ Velocity ของทั้งทีม และงานที่เหลือ(Tasks)ใน Story ที่ถูกยกไปใน Sprint อื่นจะถูกประเมินงานที่เหลือในลักษณะเป็นชั่วโมงแทนจ๊ะ - พยายามให้คะแนน Story point ตามผู้เชี่ยวชาญที่คาดว่าจะทำ Story นี้
การให้คะแนน Story point ตามที่ผู้เชี่ยวชาญเพราะคาดว่าคนนี้จะเป็นคนทำงานบน Story สิ่งนี้ไม่ควรทำอย่างยิ่งเพราะในอนาคตคนที่ทำ Story นี้อาจจะไม่ได้เป็นคนทำแต่คนอื่นที่อาจไม่มีทักษะมาก่อนก็ได้ ฉะนั้นการให้ Story point ควรโหวตเพื่อให้ได้คะแนนที่เป็นกลางมากที่สุด - โหวต Story Point ตามผู้ที่มีความเชี่ยวชาญใน Story
อย่างที่กล่าวในข้อ 8 ข้างบนนี้ เราไม่ควรให้คะแนนตามคนที่เชี่ยวชาญหรือถนัดใน Story ฉะนั้นเราควรเปลี่ยนเป็นให้คนที่มีความถนัดในเรื่องเป็นคนอธิบายให้คนในทีมเข้าใจเพื่อที่จะสามารถโหวต Story point ได้ด้วยความเข้าใจของตัวเองจ๊ะ
สุดท้ายนี้ ถึงแม้ทฤษฎีการให้ Story point จะเขียนไว้ให้เข้าใจง่าย แต่ไม่ใช่เรื่องง่ายเลยที่จะนำ Story point มาใช้ให้ถูกต้องและมีประสิทธิภาพที่สุด เพราะแต่ละคนอาจมีความเข้าใจในวิธีใช้ที่แตกต่างกัน ฉะนั้นการใช้ Story point จึงควรมีความระมัดระวังและพยายามให้ทั้งทีมเข้าใจไปในทางเดียวกันเพื่อให้เกิดผลสำเร็จในการให้ Story point และเป็น Self Organize ทีมอย่างแท้จริง
