Scrum Guide | 23. คะแนนเรื่องราวและการประมาณค่าใน Scrum

ในบทความของวันนี้ เราจะกล่าวถึงหัวข้อการประมาณค่าและคะแนนเรื่องราวใน Scrum การสร้างค่าประมาณใน Scrum ช่วยในการทำนายความซับซ้อนและเวลาที่ต้องใช้ในการทำงานให้เสร็จสิ้น ด้วยการวิเคราะห์อดีต ทีม Scrum ทั้งหมดจะร่วมกันคาดการณ์ว่าอนาคตจะเป็นอย่างไร

ดังนั้น ยิ่ง Scrum Team มีประสบการณ์มากเท่าไหร่ ค่าประมาณก็จะยิ่งแม่นยำมากขึ้นเท่านั้น ทีมงานยังร่วมมือในการกำหนดเวลาโดยประมาณเพื่อทำงานให้เสร็จในระหว่าง Sprint Planning โดยคำนึงว่าไม่ใช่การผูกมัดขั้นสุดท้าย แต่เป็นการคาดการณ์ ความแม่นยำขึ้นอยู่กับตัวแปรมากมายที่ได้รับการเปลี่ยนแปลงที่คาดไม่ถึงและสถานการณ์ที่ไม่คาดฝันอย่างต่อเนื่อง โชคดีที่ระเบียบวิธี Scrum มีเทคนิคและเครื่องมือต่างๆ ที่เอื้อให้เกิดความแน่นอนในระดับหนึ่ง และวันนี้เราจะมาพูดคุยกันในรายละเอียดเพื่อให้คุณเข้าใจและนำไปใช้ได้ทันที!

คะแนนเรื่องราวและการประมาณค่าใน Scrum – สารบัญ:

1. บทนำ
2. ความสำคัญของ Story Points ใน Scrum
3. Story Points เป็นหน่วยที่สัมพันธ์กัน ซึ่งหมายความว่า:
4. เทคนิคการประมาณค่าสัมพัทธ์
5. สรุป

บทนำ

ในแต่ละ Sprint Planning เจ้าของผลิตภัณฑ์จะนำเสนอ User Stories ใหม่แก่ทีม Product Owner เลือกพวกเขาจาก Product Backlog เพื่อนำไปใช้ใน Sprint ถัดไป จากนั้นสมาชิกทีม Scrum จะร่วมกันประมาณการปริมาณงานที่จำเป็นเพื่อให้งานชุดใหม่นี้เสร็จสมบูรณ์ การมอบหมายงานประเภทนี้เป็นการประมาณการ การประมาณ ความต้องการ

ดูเหมือนว่าวิธีที่ง่ายที่สุดคือกำหนดเวลาที่จำเป็นในการทำงานให้เสร็จเป็นชั่วโมงหรือเป็นวัน อย่างไรก็ตาม การปฏิบัติและการวิจัยที่ดำเนินการมาตั้งแต่ทศวรรษ 1940 ได้พิสูจน์ให้เห็นเป็นอย่างอื่น มนุษย์ไม่สามารถประมาณเวลาที่ต้องใช้ในการทำงานให้เสร็จสิ้นได้อย่างแม่นยำ นอกจากนี้ จำนวนชั่วโมงที่จำเป็นในการทำงานให้เสร็จสมบูรณ์นั้นขึ้นอยู่กับว่าใครทำงานอยู่ และสิ่งใดที่เคยทำหรือไม่เคยทำมาก่อน นี่คือเหตุผลที่ Scrum มักใช้หน่วยที่เรียกว่า Story Points

ความสำคัญของ Story Points ใน Scrum

ทีมพัฒนาแต่ละทีมนำคุณค่าของ Story Point มาปฏิบัติโดยดึงจากประสบการณ์และขนาดของงานแต่ละอย่าง กล่าวคือ ตามหลักการของประสบการณ์นิยม ส่วนใหญ่ ในระหว่างการวางแผน Sprint Scrum Master จะเลือกตัวอย่าง User Stories ที่เสร็จสมบูรณ์อย่างน้อยหนึ่งตัวอย่าง ซึ่งทำหน้าที่เป็น จุดอ้างอิงสำหรับกำหนดมูลค่าของ User Stories ที่จะพัฒนา

นั่นเป็นสาเหตุที่คุณไม่สามารถกำหนดค่าใน Story Points ได้โดยไม่มีบริบท ตัวอย่างเช่น ถ้างานแรกมีค่าเท่ากับ 10 งานต่อๆ มาจะถูกประเมินโดยเทียบกับงานนั้นว่ามากหรือน้อย ด้วยวิธีนี้ ภายในโปรเจ็กต์ Scrum Team งาน ทั้งหมดใน Product Backlog จะสัมพันธ์กัน ซึ่งหมายความว่างานที่คล้ายกันที่ดำเนินการโดยทีมพัฒนาหนึ่งทีมจะได้รับคะแนนเท่ากัน

Story Points เป็นหน่วยที่สัมพันธ์กัน ซึ่งหมายความว่า:

ค่า Story Point เกี่ยวข้องกับงานที่ทำโดย Scrum Team เท่านั้น Story Points อธิบายความเร็วในการทำงานให้เสร็จของทีมหนึ่งทีม กล่าวอีกนัยหนึ่ง User Story ประมาณ 10 Story Points โดยทีม A สามารถรับ 50 โดย Team B ได้ เนื่องจากดังที่เราได้กล่าวไปแล้ว คุณค่าของพวกเขาถูกคำนวณค่อนข้างเทียบกับงานอื่นๆ ที่ดำเนินการโดยทีมนั้น และประสบการณ์ของพวกเขากับงานที่คล้ายคลึงกัน .

มูลค่าของ Story Points ที่สำเร็จใน Sprint เดียวไม่สามารถเป็นพื้นฐานสำหรับการเปรียบเทียบประสิทธิภาพของ Scrum Teams สองทีมได้ เพื่อหลีกเลี่ยงข้อผิดพลาดในการจัดการโปรเจ็กต์ Scrum สิ่งสำคัญคือต้องจำไว้ว่า Speed ​​of a Development Team ที่แสดงใน Story Points ที่ทำใน Sprint เดียวไม่สามารถใช้เปรียบเทียบประสิทธิภาพของสองทีมได้ เนื่องจากพวกเขาสามารถทำงานแบบเดียวกันใน Sprints แบบคู่ขนาน ซึ่งทีมหนึ่งประมาณ 10 และอีกทีมที่ 50 Story Points

ไม่ควรลืมว่า การประมาณค่ามีองค์ประกอบที่ไม่รู้จักจำนวนมาก และสร้างขึ้นบนพื้นฐานของข้อมูลที่ไม่สมบูรณ์ ด้วยเหตุนี้ การคาดคะเนของทีม Scrum ที่มีประสบการณ์มากในบางครั้งอาจแตกต่างอย่างมากจากความพยายามที่แท้จริงที่จำเป็นในการทำให้ User Story เสร็จสมบูรณ์

เทคนิคการประมาณค่าสัมพัทธ์

เทคนิคการประมาณค่าที่มีประสิทธิภาพที่สุดใน Scrum คืออะไร? ไม่มีวิธีการใดที่เหมาะกับแต่ละทีม

ในบรรดาเทคนิคการประมาณค่าภายในวิธีการแบบเปรียว ที่พบบ่อยที่สุดคือ:

• การวางแผนโป๊กเกอร์ วิธีการที่เกี่ยวข้องที่ได้รับความนิยมมากที่สุดนี้ใช้เกมไพ่เพื่อคำนวณปริมาณงานเพื่อให้งานสำเร็จ เป็นกฎและขั้นตอนโดยละเอียดที่เราจะกล่าวถึงในบทความแยกต่างหาก
• เกมประเมินทีม สิ่งนี้เกี่ยวข้องกับการกำหนดการดำเนินการของ User Stories ใน Sprint ที่กำหนดด้วยค่าตัวเลขที่เหมาะสมที่เลือกจากลำดับ Fibonacci เราได้อุทิศบทความแยกต่างหากสำหรับมันด้วย

ในทางกลับกัน Scrum ปฏิเสธวิธีการประมาณค่าแอบโซลูทแบบคลาสสิกของวิธีการจัดการโครงการแบบดั้งเดิม วิธีประมาณการงานคือการกำหนดล่วงหน้าเดือนคน ระยะเวลา และต้นทุนของทั้งโครงการ นี่เป็นกระบวนการที่ยาวนาน ยากที่จะนำไปปฏิบัติ และต้องการการมีส่วนร่วมของผู้เชี่ยวชาญที่มักจะสร้างเหตุผลและหลักจรรยาบรรณ แต่ไม่ดำเนินการใด ๆ ที่ไม่จำเป็นต้องปฏิบัติงานตามมูลค่าที่พวกเขาประเมินไว้ กล่าวอีกนัยหนึ่ง ไม่เพียงแต่น่าเบื่อแต่ยังไร้ประสิทธิภาพอย่างสูงอีกด้วย

ประเด็นเรื่องและการประมาณการ- สรุป

การประมาณค่าเป็นทักษะที่สำคัญมากซึ่งกำหนดลักษณะเฉพาะของ Scrum Teams ที่เป็นผู้ใหญ่ทั้งหมด การประมาณเวลาและความพยายามที่จำเป็นในการทำงานแต่ละอย่างให้เสร็จกลายเป็นจุดสนใจหลักของเทคนิคการประมาณค่าสัมพัทธ์หลายอย่าง เช่น Planning Poker หรือ Team Estimation Game

เรื่องราวของผู้ใช้ที่มี Story Points เป็นอีกหนึ่งเทคนิคการวัดที่มีประสิทธิภาพที่เราอธิบาย โดยหวังว่าจะช่วยให้ผู้อ่านของเรามีเครื่องมือที่มีประโยชน์ อย่างไรก็ตาม สิ่งสำคัญคือต้องจำไว้ว่าตัวเลขของพวกเขาเกี่ยวข้องกับ งานเฉพาะที่ดำเนินการโดย Scrum Team เท่านั้น ดังนั้นจำนวน Story Points จึงไม่สามารถเป็นพื้นฐานในการเปรียบเทียบความเร็วของทีมพัฒนาต่างๆ ได้

หากคุณชอบเนื้อหาของเรา เข้าร่วมชุมชนผึ้งที่วุ่นวายบน Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest

ผู้เขียน: แคโรไลน์ เบ็คเกอร์

ในฐานะผู้จัดการโครงการ Caroline เป็นผู้เชี่ยวชาญในการค้นหาวิธีการใหม่ๆ เพื่อออกแบบเวิร์กโฟลว์ที่ดีที่สุดและเพิ่มประสิทธิภาพกระบวนการ ทักษะในการจัดองค์กรและความสามารถในการทำงานภายใต้แรงกดดันของเวลาทำให้เธอเป็นคนที่ดีที่สุดในการเปลี่ยนโครงการที่ซับซ้อนให้กลายเป็นจริง

ดูกระทู้ทั้งหมด

คู่มือการต่อสู้:

1. อภิธานศัพท์ของคำศัพท์พื้นฐาน บทบาท และแนวคิด
2. Scrum คืออะไร?
3. ค่าการต่อสู้
4. วิธีใช้งาน Scrum ในบริษัทของคุณ
5. Scrum Team - มันคืออะไรและทำงานอย่างไร?
6. เจ้าของผลิตภัณฑ์คือใคร?
7. ข้อผิดพลาดที่พบบ่อยที่สุดของ Product Owner
8. Scrum Master คือใคร?
9. ลักษณะของ Scrum Master ที่ดี
10. ข้อผิดพลาดที่พบบ่อยที่สุดของ Scrum Master
11. สถิติและตัวชี้วัดใดที่ Scrum Master ควรติดตาม
12. ความร่วมมือระหว่าง Product Owner และ Scrum Master
13. ทีมพัฒนาใน Scrum
14. ข้อผิดพลาดที่พบบ่อยที่สุดของ Developers
15. สิ่งประดิษฐ์การต่อสู้
16. สเกลการต่อสู้
17. Sprint Backlog
18. Backlog สินค้าคืออะไร?
19. เรื่องราวของผู้ใช้คืออะไร?
20. สร้าง User Story ที่ดีที่สุดกับ INVEST
21. ข้อผิดพลาด User Story ที่พบบ่อยที่สุด
22. เกณฑ์การยอมรับเรื่องราวของผู้ใช้
23. การประมาณค่าและจุดเรื่องราวใน Scrum
24. การวางแผนโป๊กเกอร์
25. เกมประเมินทีม
26. กำหนดส่วนเพิ่ม
27. เหตุการณ์การต่อสู้
28. Sprint ใน Scrum คืออะไร?
29. ความมุ่งมั่นของทีม Scrum - เป้าหมายผลิตภัณฑ์ เป้าหมาย Sprint และคำจำกัดความของความสำเร็จ
30. แผนภูมิ Burndown คืออะไร?
31. จะสร้างและตีความแผนภูมิเบิร์นดาวน์ได้อย่างไร?
32. ข้อดีและข้อเสียของแผนภูมิการเบิร์นดาวน์
33. กระดาน Kanban ใน Scrum และ Scruban
34. Velocity in Scrum - ความเร็วของทีมพัฒนา
35. การต่อสู้รายวัน
36. การวางแผนการวิ่ง
37. Sprint Review
38. Sprint Retrospective คืออะไร?
39. ข้อผิดพลาดทั่วไประหว่าง Sprint Retrospective
40. บำรุง Backlog สินค้า