Scrum Guide | 11. สถิติและตัวชี้วัดที่ Scrum Master ควรติดตาม
เผยแพร่แล้ว: 2022-04-21เหตุใด Scrum Master จึงต้องการสถิติและเมตริก ขั้นแรกเพื่อตรวจสอบว่าวิธีการทำงานของเขาในการทำนายผลลัพธ์และปรับปรุงประสิทธิภาพของทีมนั้นมีประสิทธิภาพหรือไม่ แต่ยังต้องติดตามว่าการกระทำของพวกเขาส่งผลต่อทีมพัฒนาอย่างไร นั่นคือวิธีที่พวกเขากำหนดประสบการณ์ผู้ใช้ของพนักงาน (UX) ดังนั้นในบทความนี้ เราจึงแนะนำสถิติและเมตริกที่ Scrum Master ควรติดตาม
สถิติและเมตริกที่สำคัญสำหรับ scrum master – สารบัญ:
- การวัดผลการทำงานของทีมพัฒนา
- การตรวจสอบประสบการณ์ผู้ใช้ของพนักงาน นักพัฒนา
- สรุป
การวัดผลการทำงานของทีมพัฒนา
สถิติและเมตริกที่ใช้บ่อยที่สุดที่ Scrum Master ควรติดตามคือสถิติที่ อธิบายจังหวะและโฟลว์ของการดำเนินการงาน เหล่านี้คือแผนภูมิ Burnup แผนภูมิ Burnup และแผนภูมิการไหลสะสม เป็นการวัดทั้งการพัฒนาผลิตภัณฑ์และประสิทธิภาพของทีม แต่ละรายการช่วยให้คุณเข้าถึงปัญหาเหล่านี้ได้จากมุมมองที่ต่างกัน ดังนั้นจึงควรแสดงร่วมกัน เป็นเครื่องมือที่มีประโยชน์ในการประเมินความคืบหน้าในระดับต่างๆ ระหว่าง Sprint และกระบวนการพัฒนาผลิตภัณฑ์ทั้งหมด
แผนภูมิการเผาไหม้
แผนภูมิการเบิร์นดาวน์ จะแสดงให้ Scrum Master และทีมพัฒนาเห็นว่ามีงานที่ทำเสร็จแล้วเหลืออีกมากเพียงใด แกน X แสดงเวลาที่เหลือในการทำงานให้เสร็จ แกน Y แสดงจำนวนงานที่เหลือที่ต้องทำซึ่งวางแผนไว้ใน Sprint Backlog หรือ Product Backlog
แผนภูมินี้ยัง ช่วยในการกำหนดความเร็วของทีมพัฒนา ซึ่งเราจะอุทิศบทความแยกต่างหากให้ด้วย ในที่นี้เราจะพูดถึงว่าจำนวนงานเฉลี่ยที่ทำในหนึ่ง Sprint เท่านั้น
เครื่องมือง่ายๆ นี้ช่วยให้ Scrum Master ไม่เพียงแต่เห็น ว่าทีมทำงานได้อย่างมีประสิทธิภาพเพียงใด นอกจากนี้ยังช่วยตอบคำถาม:
- ส่วนไหนของงานที่ทำเสร็จแล้ว?
- เหลืออีกกี่งานที่ต้องทำให้เสร็จ?
- ใช้เวลานานเท่าใดในการพัฒนาผลิตภัณฑ์?
เมื่อใช้แผนภูมิเบิร์นดาวน์ Scrum Master จะต้องจำไว้ว่านี่ไม่ใช่เครื่องมือเดียวในการประเมินความคืบหน้าของทีมในทางสถิติ ทำงานได้ดีที่สุดสำหรับโครงการที่มีการกำหนดขอบเขตและทราบขอบเขตของงาน ไม่สามารถทำงานได้ดีกับการสร้างโซลูชันที่เป็นนวัตกรรมใหม่กับลูกค้ารายใหม่ จากนั้นปริมาณงานที่ต้องทำในทั้งโครงการ – นั่นคือเนื้อหาของ Backlog ของผลิตภัณฑ์ – สามารถเปลี่ยนแปลงได้อย่างมากในระหว่างโครงการ ทำให้ยากต่อการใช้แผนภูมิการเผาไหม้
แผนภูมิการเผาไหม้
แผนภูมิ Burnup เป็นสิ่งที่ตรงกันข้ามกับแผนภูมิ Burndown ที่กล่าวถึงข้างต้น ที่นี่เช่นกัน แกน Y แสดงจำนวนงานที่เหลืออยู่ที่ต้องทำ ในทางกลับกัน แกน X แสดงเวลาที่เสร็จสิ้นซึ่งแสดงเป็นจำนวน Sprints หรือในวันที่
อย่างไรก็ตาม Scrum Master ใช้ Burnup Chart เพื่อจุดประสงค์ที่แตกต่างกันเล็กน้อย เนื่องจากไม่เพียงแต่ช่วยคุณในการวัดความก้าวหน้าของผลิตภัณฑ์และความก้าวหน้าของทีมเท่านั้น ตัวชี้วัดนี้ยังประเมินว่าขอบเขตของงานในโครงการเปลี่ยนแปลงอย่างไรเมื่อเวลาผ่านไป ดังนั้นจึงทำงานได้ดีสำหรับโครงการที่มีขอบเขตตัวแปร
Burnup Chart ยังเป็นเครื่องมือในการวางแผนที่มีประสิทธิภาพมากขึ้นเมื่อเวลาผ่านไป ซึ่งจะให้คำตอบสำหรับคำถามว่าทีมพัฒนาคาดว่าจะทำงานมากเพียงใดใน Sprint ถัดไป
แผนภาพการไหลสะสม
ไดอะแกรมประเภทที่สามที่มีผลอย่างมากในงานของ Scrum Master กับทีมพัฒนาคือ แผนภาพการไหลสะสม มีการวิเคราะห์ ว่าความเร็วและประสิทธิผลของทีมพัฒนามีความเสถียรเพียงใด เลย์เอาต์ของแกนจะเหมือนกับ Burnup Chart ดังนั้นจึงมักเรียกกันว่าเวอร์ชันที่ซับซ้อนกว่า
อย่างไรก็ตาม แผนภาพการไหลสะสมไม่ได้เป็นเพียงการกำหนดจำนวนงานที่เสร็จสมบูรณ์ในช่วงเวลาที่กำหนดเท่านั้น นอกจากนี้ยังคำนึงถึงจำนวนงานที่รอดำเนินการอยู่ในคิว ด้วยเหตุนี้ จึงทำให้สามารถวินิจฉัยสิ่งที่เรียกว่า "คอขวด" ซึ่งเป็นช่วงเวลาของกระบวนการที่ทำให้การสร้างผลิตภัณฑ์ช้าลง
คุณลักษณะการวินิจฉัยนี้ทำให้เป็น หนึ่งในตัวชี้วัดที่มีประโยชน์ที่สุดในมือของ Scrum Master เนื่องจากช่วยให้จัดระเบียบงานใหม่ในลักษณะการกระจายจุดแข็งของทีมพัฒนาให้แตกต่างออกไปและหลีกเลี่ยงการหยุดทำงาน
การตรวจสอบประสบการณ์ผู้ใช้ของพนักงาน นักพัฒนา
การบำรุงรักษาและการวิเคราะห์สถิติอย่างสม่ำเสมอและพิถีพิถันเป็นส่วนสำคัญของงานของ Scrum Master ที่มีประสิทธิภาพ อย่างไรก็ตาม เขา/เธอต้องคำนึงถึงประสบการณ์การใช้งานของพนักงานของนักพัฒนาก่อน เช่น วิธีที่พวกเขารับรู้งานในทีม Scrum อย่างไรก็ตาม ไม่ใช่คุณภาพของเมตริกที่จะตัดสิน แต่เป็น วิธีที่ Scrum Master ใช้
หากสถิติถูกเก็บไว้ตามหลักการของ Scrum - สถิติเหล่านี้โปร่งใส เป็นสาธารณะ และเข้าใจได้สำหรับนักพัฒนาที่เกี่ยวข้อง - อาจเป็นวิธีจูงใจให้ทีมทำงานอย่างมีประสิทธิภาพมากขึ้น หรือให้รางวัลสำหรับผลลัพธ์ที่ยอดเยี่ยม อย่างไรก็ตาม สถิติสามารถใช้เป็นเครื่องมือในการกดดันทีมพัฒนาได้ จากนั้นสิ่งบ่งชี้ของพวกเขาก็กลายเป็นเครื่องกำเนิดข้อกล่าวหาและความขุ่นเคือง พวกเขาสามารถมีส่วนทำให้ขวัญกำลังใจของทีมแย่ลงและทำให้การทำงานเป็นทีมแย่ลง
ปัจจัยสำคัญประการที่สองของประสบการณ์พนักงานของ Developers ซึ่ง Scrum Master ที่ทำงานกับเครื่องมือทางสถิติต้องดูแลคือ วิธีจัดการเวลา เนื่องจาก Scrum Master จำเป็นต้องมีเวลาเพียงพอในการดูแลทีมพัฒนา ด้วยเหตุผลนี้ กรณีของโครงการขนาดใหญ่ ควรพิจารณาเพิ่มบุคคลเพิ่มเติมในทีม Scrum เขา/เธอจะทำหน้าที่เป็นผู้จัดการโครงการและดูแลเมตริก ต้องขอบคุณสิ่งนี้ มันจะช่วยลด Scrum Master – และ Product Owner – ในระดับหนึ่ง – จากงานที่ทำให้เขาเสียสมาธิจากการทำงานร่วมกับทีมพัฒนา
สถิติและเมตริก – สรุป
Scrum Master ควรติดตามสถิติพื้นฐานที่อธิบายการทำงานของทีมพัฒนา การตีความอย่างชำนาญของพวกเขาจะเพิ่มโอกาสในการระบุปัญหาในการทำงานของทีมและตอบสนองต่อปัญหาอย่างรวดเร็ว อย่างไรก็ตาม สิ่งที่สำคัญกว่าการรักษาแผนภูมิคือสิ่งที่ Scrum Master ทำกับแผนภูมิเหล่านั้น พวกเขาไม่ควรปฏิบัติต่อตัววัดเป็นเครื่องมือในการประเมินทีม แต่ควรปฏิบัติต่อพวกเขาว่าเป็นเครื่องมือที่มีประโยชน์ในการจูงใจทีมและวินิจฉัยวิธีการทำสิ่งต่างๆ ของพวกเขาเอง เนื่องจากตัวชี้วัดจะเป็นเครื่องมือที่มีประโยชน์ก็ต่อเมื่อช่วย อำนวยความสะดวกให้กับทีมและกระบวนการปรับปรุงผลิตภัณฑ์
หากคุณชอบเนื้อหาของเรา เข้าร่วมชุมชนผึ้งที่วุ่นวายบน Facebook, Twitter, LinkedIn, Instagram, YouTube
ผู้เขียน: แคโรไลน์ เบ็คเกอร์
ในฐานะผู้จัดการโครงการ Caroline เป็นผู้เชี่ยวชาญในการค้นหาวิธีการใหม่ๆ เพื่อออกแบบเวิร์กโฟลว์ที่ดีที่สุดและเพิ่มประสิทธิภาพกระบวนการ ทักษะในการจัดองค์กรและความสามารถในการทำงานภายใต้แรงกดดันของเวลาทำให้เธอเป็นคนที่ดีที่สุดในการเปลี่ยนโครงการที่ซับซ้อนให้กลายเป็นจริง
คู่มือการต่อสู้:
- อภิธานศัพท์ของคำศัพท์พื้นฐาน บทบาท และแนวคิด
- Scrum คืออะไร?
- ค่าการต่อสู้
- วิธีใช้งาน Scrum ในบริษัทของคุณ
- Scrum Team - มันคืออะไรและทำงานอย่างไร?
- เจ้าของผลิตภัณฑ์คือใคร?
- ข้อผิดพลาดที่พบบ่อยที่สุดของ Product Owner
- Scrum Master คือใคร?
- ลักษณะของ Scrum Master ที่ดี
- ข้อผิดพลาดที่พบบ่อยที่สุดของ Scrum Master
- สถิติและตัวชี้วัดใดที่ Scrum Master ควรติดตาม
- ความร่วมมือระหว่าง Product Owner และ Scrum Master
- ทีมพัฒนาใน Scrum
- ข้อผิดพลาดที่พบบ่อยที่สุดของ Developers
- สิ่งประดิษฐ์การต่อสู้
- สเกลการต่อสู้
- Sprint Backlog
- Backlog สินค้าคืออะไร?
- เรื่องราวของผู้ใช้คืออะไร?
- สร้าง User Story ที่ดีที่สุดกับ INVEST
- ข้อผิดพลาด User Story ที่พบบ่อยที่สุด
- เกณฑ์การยอมรับเรื่องราวของผู้ใช้
- การประมาณค่าและจุดเรื่องราวใน Scrum
- การวางแผนโป๊กเกอร์
- เกมประเมินทีม
- กำหนดส่วนเพิ่ม
- เหตุการณ์การต่อสู้
- Sprint ใน Scrum คืออะไร?
- ความมุ่งมั่นของทีม Scrum - เป้าหมายผลิตภัณฑ์ เป้าหมาย Sprint และคำจำกัดความของความสำเร็จ
- แผนภูมิ Burndown คืออะไร?
- จะสร้างและตีความแผนภูมิเบิร์นดาวน์ได้อย่างไร?
- ข้อดีและข้อเสียของแผนภูมิการเบิร์นดาวน์
- กระดาน Kanban ใน Scrum และ Scruban
- Velocity in Scrum - ความเร็วของทีมพัฒนา
- การต่อสู้รายวัน
- การวางแผนการวิ่ง
- Sprint Review
- Sprint Retrospective คืออะไร?
- ข้อผิดพลาดทั่วไประหว่าง Sprint Retrospective
- บำรุง Backlog สินค้า