Scrum Guide | 18. Product Backlog คืออะไร?

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

Backlog สินค้าคืออะไร? – สารบัญ:

1. บทนำ
2. Product Backlog ประกอบด้วยอะไรบ้าง?
3. รูปทรงของ Product Backlog
4. การปรับปรุง Backlog ของผลิตภัณฑ์
5. สรุป

บทนำ

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

Product Backlog ประกอบด้วยอะไรบ้าง?

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

ภาษาธุรกิจเป็นตัว กำหนดรายการใน Product Backlog กล่าวอีกนัยหนึ่งคืออธิบายมูลค่าของผลิตภัณฑ์จากมุมมองของผู้มีส่วนได้ส่วนเสีย

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

• ขอบเขตของ การปรับเปลี่ยนผลิตภัณฑ์
• วัตถุประสงค์ใน การปรับเปลี่ยนผลิตภัณฑ์
• ประเภทของผู้ใช้ ที่การแก้ไขนี้เกิดขึ้น

รูปทรงของ Product Backlog

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

งานที่มี กำหนดเวลาที่ห่างไกล มักจะเป็น งานขนาดใหญ่ทั่วไป คำอธิบายของพวกเขาไม่มีรายละเอียด แต่มีเพียงโครงร่างของการทำงานที่ควรรับรู้ นอกจากนี้ยังสามารถค้นหางานที่ไม่มีวันสิ้นสุดได้

รายการใน Product Backlog อาจนำเสนอ ทางเลือกอื่น และความคิดของลูกค้าที่อาจล้าสมัย ไม่เป็นประโยชน์ หรือด้วยเหตุผลอื่นใด จะไม่เข้าสู่ขั้นตอนการนำไปปฏิบัติ นั่นคือเหตุผลที่บางครั้ง Product Backlog จึงถูกเรียกติดตลกว่า "Customer's wish list"

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

กิจกรรมพื้นฐานอย่างหนึ่งในระหว่างการปรับปรุง Product Backlog คือ การแบ่งงานที่ อยู่ใน Product Backlog ออกเป็นส่วนๆ ด้วยเหตุนี้ โครงร่างทั่วไปของฟังก์ชันการทำงานจึงถูกนำเสนอในรูปแบบของหน่วยที่มีขนาดเล็กลง มีรายละเอียดมากขึ้นและกำหนดไว้อย่างแม่นยำ

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

การปรับปรุง Backlog ของผลิตภัณฑ์

ขณะทำงานกับผลิตภัณฑ์ เจ้าของผลิตภัณฑ์ จะแก้ไขและให้รายละเอียด Backlog ของผลิตภัณฑ์โดยร่วมมือกับทีมพัฒนา ตามคำแนะนำของเจ้าของผลิตภัณฑ์ ระหว่าง Sprint Planning ทีมจะเลือกคุณสมบัติที่จะนำไปใช้จาก Product Backlog จากนั้นจะย้ายไปยัง Sprint Backlog และแบ่งออกเป็นงานที่ต้องทำให้เสร็จ งานที่ย้ายไปยัง Sprint Backlog มีการอธิบายในภาษาทางเทคนิค ซึ่งมีประโยชน์มากที่สุดสำหรับนักพัฒนา

ขนาดงาน เป็นตัวชี้วัดที่สำคัญจากมุมมองของทีมพัฒนา การประมาณค่าที่เหมาะสมมีความสำคัญอย่างยิ่งเมื่อเลือก User Stories จาก Product Backlog ไปจนถึง Sprint Backlog

ทีมพัฒนาเรียนรู้เมื่อเวลาผ่านไปเพื่อ ประเมินเวลาและความพยายาม ที่จำเป็นในการกรอก User Story ให้เสร็จสมบูรณ์ ซึ่งแสดงเป็นวัน ชั่วโมงการทำงาน หรือ Story Points และให้ค่าประมาณที่เรียกว่า Team Velocity

สรุป

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

• รายละเอียดงานมีรายละเอียดมากขึ้น
• ขอบเขตของงานมีขนาดเล็กลง
• กำหนดขอบเขตของงานได้ดีขึ้น

ทีม Scrum ดูแลงาน Product Owner จะจัดการและแก้ไข Product Backlog

หากคุณชอบเนื้อหาของเรา เข้าร่วมชุมชนผึ้งที่วุ่นวายบน 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 สินค้า