Scrum Guide | 40. การบำรุงเลี้ยง Backlog ของผลิตภัณฑ์
เผยแพร่แล้ว: 2022-07-21การบำรุงเลี้ยง Product Backlog เป็นหนึ่งในงานหลักของเจ้าของผลิตภัณฑ์ กระบวนการดูแลรวมถึงการกำหนดรายละเอียดและเพิ่มเรื่องราวของผู้ใช้ใหม่ใน Backlog ของผลิตภัณฑ์ อย่างไรก็ตาม สิ่งสำคัญที่สุดของงานการเลี้ยงดูคือการทำให้แน่ใจว่ารายการที่อยู่ใน Backlog อยู่ในลำดับที่ถูกต้อง กล่าวคือ มีการจัดลำดับความสำคัญ
การบำรุงเลี้ยง Backlog ของผลิตภัณฑ์ – สารบัญ:
- บทนำ
- วัตถุประสงค์ของการบำรุงเลี้ยง Backlog ของผลิตภัณฑ์
- ข้อผิดพลาดในการบำรุงรักษา Backlog ของผลิตภัณฑ์
- การบำรุงรักษา Backlog เทียบกับเมตริกที่ใช้ใน Scrum
- สรุป
บทนำ
Product Backlog เป็นหนึ่งในสิ่งประดิษฐ์ของ Scrum ประกอบด้วยรายการลำดับความสำคัญของงานที่จำเป็นในการสร้างผลิตภัณฑ์ กล่าว คือ เป็นรายการเรื่องราวของผู้ใช้ที่จำเป็นต่อการบรรลุเป้าหมายผลิตภัณฑ์ คุณสามารถดูคำอธิบายโดยละเอียดเกี่ยวกับเรื่องราวของผู้ใช้ได้ในบทความนี้ และนี่คือรายละเอียดเกี่ยวกับคุณสมบัติและวิธีดูแลรักษา Product Backlog
Product Backlog nrturing ยังใช้ชื่อต่อไปนี้:
- การจัดลำดับความสำคัญงานในมือ,
- การปรับแต่ง Backlog,
- สเกลงานค้าง.
วัตถุประสงค์ของการบำรุงเลี้ยง Backlog ของผลิตภัณฑ์
เจ้าของผลิตภัณฑ์จัดการ Product Backlog ทักษะที่สำคัญ ได้แก่ การ จัดลำดับความสำคัญของงาน เมื่อใกล้ถึงกำหนดส่ง เนื่องจากเป้าหมายของการดูแล Product Backlog คือการทำให้แน่ใจว่าฟังก์ชันต่างๆ ของผลิตภัณฑ์มาพร้อมกับมูลค่าทางธุรกิจสูงสุด กล่าวคือ สิ่งที่สำคัญที่สุดจากมุมมองของลูกค้า อยู่ที่ด้านบนสุดของรายการสิ่งที่ต้องทำ และคำอธิบายก็ชัดเจนและมีรายละเอียดเพื่อให้การใช้งานสามารถเริ่มต้นได้ใน Sprint ถัดไป
Product Backlog สามารถอัปเดตได้ทุกวันหากจำเป็น เจ้าของผลิตภัณฑ์สามารถเพิ่ม User Stories ใหม่ลงใน Product Backlog หลังจากพูดคุยกับผู้มีส่วนได้ส่วนเสียและทีมพัฒนา หรือโดยการสรุปและจัดรูปแบบ User Stories ที่เขียนไว้แล้วใน Product Backlog
การอัปเดต Backlog แบบบังคับเป็นหนึ่งในงานที่ดำเนินการระหว่าง Sprint Review เราได้อธิบายกระบวนการนั้นโดยละเอียดในบทความนี้ โดยปกติ ในระหว่างการประชุมนี้ ทีม Scrum จะพูดคุยไม่เฉพาะงานที่ต้องทำให้เสร็จใน Sprint ถัดไป นอกจากนี้ยังระบุเรื่องราวของผู้ใช้เบื้องต้นและการนำไปใช้ใน Sprint สองหรือสามรายการถัดไป วิธีการทำสิ่งนี้ช่วยให้ Scrum Team และกิจกรรมต่างๆ มองเห็นทิศทางในระยะยาวได้กว้างขึ้น ช่วยให้นึกถึงงานที่กำลังดำเนินการอยู่จากมุมมองของการพัฒนาใน Sprints ที่ตามมา
ข้อผิดพลาดในการบำรุงรักษา Backlog ของผลิตภัณฑ์
ปัญหาที่พบบ่อยที่สุดประการหนึ่งเกี่ยวกับการบำรุงเลี้ยง Product Backlog คือการ ปล่อยให้ขยายออกไปอย่างไม่สามารถควบคุมได้ เนื่องจากในขณะที่ทำงานกับผลิตภัณฑ์ ฟังก์ชันและงานเพิ่มเติมต่างๆ ที่เสนอโดยทั้งผู้มีส่วนได้ส่วนเสียและสมาชิกทีม Scrum จะปรากฏขึ้นเองตามธรรมชาติ ดังนั้น การจำกัดการเติบโตของขอบเขต Product Backlog (การคืบคลานของขอบเขต) จึงเป็นหนึ่งในงานที่สำคัญที่สุดที่ดำเนินการโดยเจ้าของผลิตภัณฑ์ ข้อผิดพลาดที่พบบ่อยที่สุดที่เจ้าของผลิตภัณฑ์กังวล:
- การเบี่ยงเบนจากวัตถุประสงค์ของผลิตภัณฑ์ – การเพิ่มแนวคิดมากเกินไปใน Product Backlog นอกเหนือจากวัตถุประสงค์พื้นฐานของผลิตภัณฑ์นั้นไม่ใช่แนวทางปฏิบัติที่ดี เนื่องจากจะทำให้ความสามารถในการอ่านลดลงอย่างมาก การรวบรวมแนวคิดสำหรับการทำงานเพิ่มเติมในเอกสารแยกต่างหากจะดีกว่า
- การทำสำเนาเนื้อหา – การป้อนแนวคิดซ้ำๆ หรือคล้ายกันมากจากผู้มีส่วนได้ส่วนเสียต่างๆ ลงใน Backlog – ก่อนที่จะเพิ่มรายการอื่นใน Backlog เจ้าของผลิตภัณฑ์ควรตรวจสอบให้แน่ใจว่ารายการใหม่ไม่ซ้ำกับรายการที่มีอยู่
- ขาดมุมมองที่กว้างขึ้น – คุณควรสั่งซื้อรายการ Product Backlog ตามมูลค่าที่เกี่ยวข้องกับเป้าหมายผลิตภัณฑ์ อย่างไรก็ตาม พึงระลึกไว้เสมอว่าการจัดลำดับความสำคัญควรคำนึงถึง Sprint หลายๆ ครั้งถัดไป เพื่อให้งานที่ดำเนินการใน Sprint ที่กำหนดจะเชื่อมโยงกับทั้ง Sprint ก่อนหน้าและ Sprint ที่ตามมาในทันที
คุณไม่สามารถหลีกเลี่ยงข้อผิดพลาดประเภทนี้ได้ อย่างไรก็ตาม การตระหนักรู้ถึงเหตุการณ์ที่เกิดขึ้นอาจทำให้เจ้าของผลิตภัณฑ์ระมัดระวังมากขึ้นในการเพิ่ม User Stories ใหม่ใน Product Backlog เพื่อหาสมดุลที่เหมาะสม เนื่องจากเป็นความผิดพลาด ที่จะให้ Backlog ตัด และกำจัดรายการที่มีงานที่คล้ายกันซึ่งแตกต่างกันมากเกินไป ตัวอย่างเช่น การอธิบายฟังก์ชันของผลิตภัณฑ์ที่คล้ายกันซึ่งแตกต่างกันอย่างมากในแอปพลิเคชัน
การบำรุงรักษา Backlog เทียบกับเมตริกที่ใช้ใน Scrum
Product Backlog ประกอบด้วย คำอธิบายของงานที่เหลือตลอดทั้งโครงการ อย่างไรก็ตาม เฉพาะ Backlog ที่เป็นปัจจุบันและได้รับการดูแลอย่างสม่ำเสมอเท่านั้นที่สามารถประมาณอัตราส่วนของปริมาณงานที่เสร็จสมบูรณ์ต่อยอดรวมได้อย่างแม่นยำ หากต้องการแสดงปริมาณงานที่เสร็จสมบูรณ์ คุณควรใช้ แผนภูมิการเผาไหม้ ที่เราเขียนไว้ในบทความนี้
เมตริกยอดนิยมอีกตัวหนึ่งที่อธิบายการทำงานของ Scrum Team คือ Velocity คุณสามารถวัดได้โดยการเปรียบเทียบจำนวนรายการ Product Backlog ที่แปลงเป็น Increment ระหว่าง Sprint เดียว เราได้อธิบายรายละเอียดเพิ่มเติมเกี่ยวกับ Velocity ในบทความนี้
สรุป
เจ้าของผลิตภัณฑ์ดำเนินการบำรุงเลี้ยง Product Backlog เมื่อ Product Backlog ได้รับการดูแลอย่างดี ทีม Scrum จะมี มุมมองที่ชัดเจนเกี่ยวกับงานที่เหลืออยู่ นอกจากนี้ยังสามารถรับมุมมองที่กว้างขึ้นและมองไปข้างหน้าว่าเส้นทางไปสู่เป้าหมายผลิตภัณฑ์เป็นอย่างไร นี่คือเหตุผลที่เจ้าของผลิตภัณฑ์จำเป็นต้องตรวจสอบให้แน่ใจว่าเรื่องราวของผู้ใช้ที่รวมอยู่ใน Product Backlog นั้นอยู่ในลำดับความสำคัญเพื่อให้เสร็จสิ้น และงานที่ต้องทำให้เสร็จใน Sprints ที่จะมาถึงนั้นได้อธิบายไว้อย่างละเอียด
หากคุณชอบเนื้อหาของเรา เข้าร่วมชุมชนผึ้งที่วุ่นวายบน Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest
ผู้เขียน: แคโรไลน์ เบ็คเกอร์
ในฐานะผู้จัดการโครงการ 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 สินค้า