Product Backlog: วิธีสร้างและจัดลำดับความสำคัญอย่างมีประสิทธิภาพ
Product backlog คือกลไกสำคัญของการพัฒนาแบบ Agile ทุกฟีเจอร์ การแก้ไขข้อผิดพลาด การปรับปรุง และงานทางเทคนิคที่อาจถูกสร้างขึ้นจะอยู่ใน backlog ซึ่งจัดเรียงตามลำดับความสำคัญ กำหนดขนาดสำหรับการประมาณการ และพร้อมที่จะถูกดึงเข้าสู่ sprint
backlog ที่ได้รับการจัดการอย่างดีเป็นหนึ่งในสัญญาณที่ชัดเจนที่สุดของทีม Agile ที่มีวุฒิภาวะ backlog ที่ถูกละเลย — มีหลายร้อยรายการ หลายรายการไม่เกี่ยวข้อง ลำดับความสำคัญไม่ชัดเจน ไม่มีการประมาณการ — เป็นหนึ่งในสัญญาณที่แน่นอนที่สุดว่ากระบวนการของทีมต้องการการดูแล
คู่มือนี้ครอบคลุมวิธีการสร้าง product backlog ตั้งแต่เริ่มต้น วิธีการบำรุงรักษา และวิธีตรวจสอบให้แน่ใจว่ามันขับเคลื่อนการพัฒนาจริง ๆ แทนที่จะเป็นเพียงกองไอเดียที่ไม่มีการจัดการ
Product Backlog คืออะไร?
ใน Scrum, product backlog คือรายการที่จัดเรียงของทุกสิ่งที่อาจทำได้เพื่อปรับปรุงผลิตภัณฑ์ Product Owner เป็นเจ้าของและเป็นแหล่งความจริงเดียวสำหรับสิ่งที่ทีมจะทำงาน
backlog ประกอบด้วย:
- User stories — ฟีเจอร์ที่อธิบายจากมุมมองของผู้ใช้
- Bug fixes — ข้อบกพร่องที่ต้องแก้ไข
- Technical debt — การปรับปรุงคุณภาพโค้ด สถาปัตยกรรม หรือโครงสร้างพื้นฐาน
- Spikes — งานวิจัยเพื่อลดความไม่แน่นอนก่อนที่จะมุ่งมั่นกับฟีเจอร์
- Non-functional requirements — การปรับปรุงประสิทธิภาพ ความปลอดภัย การเข้าถึง
ทุกรายการใน backlog ควรมีเหตุผล: มันแสดงถึงคุณค่าที่เป็นไปได้สำหรับผู้ใช้หรือธุรกิจ รายการที่ไม่แสดงถึงคุณค่าอีกต่อไปควรถูกลบออก ไม่ใช่แค่ลดลำดับความสำคัญ
บทบาทของ Product Owner
Product Owner (PO) มีหน้าที่รับผิดชอบ backlog ซึ่งหมายถึง:
- การเพิ่มรายการใหม่เมื่อระบุได้
- การลบรายการที่ไม่เกี่ยวข้องอีกต่อไป
- การจัดเรียง backlog ตามลำดับความสำคัญตลอดเวลา
- การตรวจสอบให้แน่ใจว่าส่วนบนสุดของ backlog พร้อมสำหรับทีมพัฒนาที่จะทำงาน
PO ไม่ได้สร้าง backlog โดยลำพัง ข้อมูลมาจากผู้ใช้ ผู้มีส่วนได้ส่วนเสีย นักพัฒนา และข้อมูล แต่ PO เป็นผู้ตัดสินใจขั้นสุดท้ายเกี่ยวกับลำดับความสำคัญ
โมเดลเจ้าของคนเดียวนี้เป็นหนึ่งในหลักการที่สำคัญที่สุดของ Agile backlog ที่จัดการโดยคณะกรรมการหรือการลงคะแนนแบบคณะกรรมการมักจะนำไปสู่การประนีประนอมมากกว่าการจัดลำดับความสำคัญที่ชัดเจน และทีมก็มักจะทำงานทุกอย่างพร้อมกัน
การเขียนรายการ Backlog ที่ดี
"User can export data"
"As a user I can filter"
"Add pagination to list"
รูปแบบ User Story
รูปแบบ User Story มาตรฐานคือ:
ในฐานะ [ประเภทผู้ใช้], ฉันต้องการ [การกระทำบางอย่าง] เพื่อให้ [ได้รับประโยชน์บางอย่าง]
ตัวอย่าง: “ในฐานะผู้จัดการโครงการ ฉันต้องการกรองงานตามผู้รับมอบหมาย เพื่อให้ฉันสามารถดูปริมาณงานของทีมได้อย่างรวดเร็ว”
รูปแบบนี้บังคับให้คุณระบุว่าใครได้รับประโยชน์ พวกเขาต้องการอะไร และทำไม ซึ่งเป็นบริบทสามส่วนที่ป้องกันไม่ให้มีการสร้างคุณสมบัติด้วยเหตุผลที่ผิด
เกณฑ์การยอมรับ (Acceptance Criteria)
ทุกรายการใน backlog ควรมีเกณฑ์การยอมรับ: เงื่อนไขที่เฉพาะเจาะจงและสามารถทดสอบได้ ซึ่งต้องเป็นจริงเพื่อให้รายการนั้นถือว่าเสร็จสมบูรณ์
ตัวอย่างเกณฑ์การยอมรับสำหรับเรื่องการกรองงาน:
- ผู้ใช้สามารถกรองตามผู้รับมอบหมายหนึ่งคนหรือหลายคนพร้อมกันได้
- มุมมองที่กรองแล้วจะอัปเดตแบบเรียลไทม์โดยไม่ต้องโหลดหน้าใหม่
- สถานะการกรองจะถูกเก็บไว้เมื่อผู้ใช้นำทางออกไปแล้วกลับมา
- งานที่ไม่ได้มอบหมายจะปรากฏขึ้นเมื่อเลือก “ไม่ได้มอบหมาย”
หากไม่มีเกณฑ์การยอมรับ “เสร็จสมบูรณ์” จะไม่ถูกกำหนด เมื่อมีเกณฑ์เหล่านี้ ทั้งนักพัฒนาและผู้ทดสอบจะทราบอย่างชัดเจนว่าต้องตรวจสอบอะไร
เกณฑ์ INVEST
User Story ที่ดีต้องเป็นไปตามเกณฑ์ INVEST:
| ตัวอักษร | ความหมาย |
|---|---|
| I | Independent — สามารถพัฒนาได้โดยไม่ต้องพึ่งพา Story อื่น |
| N | Negotiable — รายละเอียดสามารถปรับเปลี่ยนได้ในการสนทนา |
| V | Valuable — มอบมูลค่าให้กับผู้ใช้หรือธุรกิจ |
| E | Estimable — ทีมสามารถประเมินความพยายามที่ต้องใช้ได้ |
| S | Small — สามารถทำให้เสร็จได้ในหนึ่ง Sprint |
| T | Testable — มีเกณฑ์การยอมรับที่ชัดเจน |
Story ที่ไม่ผ่านเกณฑ์เหล่านี้ — โดยทั่วไปเนื่องจากมีขนาดใหญ่เกินไป คลุมเครือเกินไป หรือไม่สามารถส่งมอบได้อย่างอิสระ — จำเป็นต้องได้รับการปรับปรุงก่อนที่จะเข้าสู่ Sprint
เทคนิคการจัดลำดับความสำคัญของ Backlog
การจัดลำดับความสำคัญคือจุดที่การตัดสินใจเกี่ยวกับผลิตภัณฑ์และข้อมูลมาบรรจบกัน มีกรอบการทำงานหลายอย่างที่ช่วยจัดโครงสร้างการตัดสินใจในการจัดลำดับความสำคัญ
วิธี MoSCoW
จัดหมวดหมู่แต่ละรายการเป็น Must have (ต้องมี), Should have (ควรมี), Could have (อาจมี), หรือ Won’t have (จะไม่มีในรุ่นนี้) ซึ่งจะสร้างระบบลำดับความสำคัญสี่ระดับที่เข้าใจง่ายและผู้มีส่วนได้ส่วนเสียสามารถมีส่วนร่วมได้
การให้คะแนน RICE
RICE ย่อมาจาก Reach (การเข้าถึง), Impact (ผลกระทบ), Confidence (ความมั่นใจ), Effort (ความพยายาม) แต่ละรายการจะถูกให้คะแนนในมิติเหล่านี้และจัดอันดับตามคะแนน RICE: (Reach × Impact × Confidence) / Effort
นี่คือการจัดลำดับความสำคัญเชิงปริมาณ ซึ่งทำงานได้ดีเมื่อคุณมีข้อมูลเกี่ยวกับการเข้าถึงและผลกระทบ และต้องการการจัดอันดับที่น่าเชื่อถือมากกว่าความรู้สึกเพียงอย่างเดียว
เมทริกซ์คุณค่าเทียบกับความพยายาม
วางแต่ละรายการใน backlog ลงบนเมทริกซ์ 2x2: คุณค่าบนแกนหนึ่ง ความพยายามบนอีกแกนหนึ่ง รายการในช่องที่มีคุณค่าสูงและใช้ความพยายามต่ำคือชัยชนะที่รวดเร็วและควรได้รับการจัดลำดับความสำคัญ รายการในช่องที่มีคุณค่าต่ำและใช้ความพยายามสูงเป็นผู้สมัครที่จะถูกลบออก
โมเดล Kano
โมเดล Kano จัดหมวดหมู่คุณสมบัติตามผลกระทบต่อความพึงพอใจของผู้ใช้:
- ความต้องการพื้นฐาน — การไม่มีอยู่ทำให้เกิดความไม่พอใจ; การมีอยู่เป็นสิ่งที่คาดหวัง (สิ่งที่ต้องมี)
- ความต้องการด้านประสิทธิภาพ — ยิ่งมีมากยิ่งดี (คุณสมบัติหลัก)
- สิ่งที่สร้างความพึงพอใจ — คุณสมบัติที่ไม่คาดคิดที่เพิ่มความพึงพอใจอย่างมาก
กรอบการทำงานนี้ช่วยสร้างสมดุลระหว่างสิ่งที่ต้องมีกับการสร้างสรรค์นวัตกรรม
การปรับปรุง Backlog (Refinement)
การปรับปรุง Backlog หรือที่เรียกว่า backlog refinement คือกระบวนการทบทวน อัปเดต และปรับปรุงรายการใน Backlog อย่างต่อเนื่อง ใน Scrum โดยทั่วไปจะเกิดขึ้นหนึ่งครั้งต่อ Sprint ในรูปแบบของการประชุมแยกต่างหาก
เซสชันการปรับปรุง Backlog ประกอบด้วย:
- การทบทวนรายการใหม่ — รายการที่ถูกเพิ่มเข้ามาตั้งแต่การปรับปรุงครั้งล่าสุด รายการเหล่านั้นเขียนได้ชัดเจนหรือไม่? มีเกณฑ์การยอมรับหรือไม่?
- การประมาณรายการ — ทีมจะประมาณความพยายามสำหรับรายการที่อยู่ใกล้ด้านบนของ Backlog เพื่อให้พร้อมสำหรับการวางแผน Sprint
- การแบ่งรายการขนาดใหญ่ — Epic และ Story ขนาดใหญ่จะถูกแยกย่อยออกเป็นรายการที่เล็กลงและมีขนาดเหมาะสมกับ Sprint
- การตัดทิ้ง — การลบรายการที่ไม่เกี่ยวข้อง ล้าสมัย หรือซ้ำซ้อนอีกต่อไป
- การจัดลำดับความสำคัญใหม่ — การปรับลำดับตามข้อมูลใหม่ ข้อเสนอแนะจากผู้มีส่วนได้ส่วนเสีย หรือการเปลี่ยนแปลงลำดับความสำคัญทางธุรกิจ
จังหวะการปรับปรุง Backlog ที่ดีหมายความว่าส่วนบนสุดของ Backlog ของคุณพร้อมเสมอ — เขียนไว้แล้ว ประมาณการไว้แล้ว และจัดลำดับความสำคัญไว้แล้ว — สำหรับ Sprint ถัดไป
การรักษา Backlog ให้มีสุขภาพดี
Backlog ที่เติบโตอย่างไม่มีที่สิ้นสุดโดยไม่มีการตัดทิ้งจะกลายเป็นภาระ ทีมจะหยุดเชื่อถือมันเพราะพวกเขารู้ว่ามันเต็มไปด้วยรายการที่ไม่มีใครตั้งใจจะสร้าง นี่คือสัญญาณของ Backlog ที่มีสุขภาพดีและวิธีการรักษา Backlog เหล่านั้น
สัญญาณของ Backlog ที่มีสุขภาพดี
- รายการสิบถึงสิบห้ารายการแรกได้รับการปรับปรุงและพร้อมสำหรับ Sprint
- รายการทั้งหมดมีชื่อที่ชัดเจนและเกณฑ์การยอมรับ
- Backlog ไม่มีรายการที่เก่ากว่าหกเดือนที่ไม่เคยถูกจัดลำดับความสำคัญใกล้ด้านบน
- ทุกคนในทีมได้อ่านส่วนบนสุดของ Backlog เมื่อเร็วๆ นี้
- รายการถูกลบออกอย่างสม่ำเสมอ ไม่ใช่แค่เพิ่มเข้ามา
กฎ “ถ้าจะไม่สร้างภายในหกเดือน ให้ลบออก”
หลายทีมมีรายการ Backlog หลายร้อยรายการที่พวกเขาไม่มีความตั้งใจที่จะสร้างภายในหกเดือนข้างหน้า สิ่งนี้สร้างความวุ่นวายที่ทำให้มองเห็นลำดับความสำคัญที่แท้จริงได้ยากขึ้น กฎที่มีประโยชน์: หากรายการอยู่ในส่วนล่างสุดของ Backlog เป็นเวลาหกเดือน ให้เก็บถาวรหรือลบออก หากมันสำคัญ มันจะกลับมาปรากฏอีกครั้ง
แยก Icebox ออกมา
บางทีมรักษา “icebox” — ชุดของแนวคิดและงานในอนาคตที่เป็นไปได้ที่แยกต่างหาก ซึ่งไม่ใช่ Backlog ที่ใช้งานอยู่ รายการใน icebox ไม่ได้ถูกจัดลำดับความสำคัญ ไม่ได้ถูกปรับปรุง และไม่ได้ถูกประมาณการ พวกมันถูกบันทึกไว้เพื่อพิจารณาในอนาคตเท่านั้น
สิ่งนี้จะป้องกันไม่ให้ icebox ปนเปื้อน Backlog ที่ใช้งานอยู่ และทำให้ Backlog ที่ใช้งานอยู่มีขนาดเล็กลง สะอาดขึ้น และน่าเชื่อถือมากขึ้น
Product Backlog vs. Sprint Backlog
Product Backlog และ Sprint Backlog มีความเกี่ยวข้องกันแต่แตกต่างกัน:
| Product Backlog | Sprint Backlog | |
|---|---|---|
| ขอบเขต | ทุกสิ่งที่อาจถูกสร้างขึ้น | สิ่งที่ทีมมุ่งมั่นที่จะทำใน Sprint นี้ |
| เจ้าของ | Product Owner | ทีมพัฒนา |
| ระยะเวลา | ต่อเนื่อง, พัฒนาไปเรื่อยๆ | หนึ่ง Sprint (1–4 สัปดาห์) |
| ระดับรายละเอียด | แตกต่างกันไป (ด้านบน = ละเอียด, ด้านล่าง = คร่าวๆ) | รายการทั้งหมดได้รับการปรับปรุงอย่างสมบูรณ์ |
| ขนาด | อาจมีหลายร้อยรายการ | โดยทั่วไป 10–20 รายการ |
ในการวางแผน Sprint ทีมจะดึงรายการจากส่วนบนสุดของ Product Backlog เข้าสู่ Sprint Backlog นี่คือเหตุผลที่ส่วนบนสุดของ Product Backlog ต้องพร้อมเสมอ: การประชุมวางแผน Sprint ไม่สามารถปรับปรุง Story ได้แบบเรียลไทม์ตลอดทั้ง Sprint
อ่านเพิ่มเติม: Sprint Planning: How to Run an Effective Session และ User Story Mapping Guide
เครื่องมือสำหรับจัดการ Product Backlog
| เครื่องมือ | เหมาะสำหรับ | คุณสมบัติ Backlog | ราคา |
|---|---|---|---|
| Jira | ทีมวิศวกรรมขนาดใหญ่ | Epics, stories, sprints, การรายงาน | $7.75/ผู้ใช้/เดือน |
| Linear | ทีมวิศวกรรมผลิตภัณฑ์ | UI ที่สะอาด, cycles, roadmaps | ฟรี / $8/เดือน |
| TasksBoard | ทีม Google Workspace | Kanban, รายการงานที่แชร์ | ฟรี / Premium |
| Notion | ทีมที่มีความยืดหยุ่น | ฐานข้อมูลที่กำหนดเอง, มุมมอง | ฟรี / $8/เดือน |
| Trello | ทีมขนาดเล็ก | Cards, lists, labels | ฟรี / $5/เดือน |
| Asana | ทีมข้ามสายงาน | Portfolio, timelines, workload | ฟรี / $10.99/เดือน |
สำหรับทีมที่ใช้ Google Workspace, TasksBoard มีวิธีที่ตรงไปตรงมาในการจัดการรายการ backlog เป็นรายการ Google Tasks ที่แชร์พร้อมมุมมอง kanban board โดยไม่ต้องมีค่าใช้จ่ายเพิ่มเติมของแพลตฟอร์มการจัดการโครงการโดยเฉพาะ
คำถามที่พบบ่อย
ใครเป็นเจ้าของ Product Backlog?
Product Owner เป็นเจ้าของ Backlog และรับผิดชอบเนื้อหา ลำดับ และความพร้อมใช้งานของ Backlog ทีมพัฒนาให้ข้อมูลประมาณการและข้อมูลทางเทคนิค แต่ PO เป็นผู้ตัดสินใจจัดลำดับความสำคัญขั้นสุดท้าย
ควรมีการปรับปรุง Backlog บ่อยแค่ไหน?
ทีม Scrum ส่วนใหญ่จะปรับปรุง Backlog สัปดาห์ละครั้ง โดยใช้เวลาประมาณ 10% ของ Sprint Capacity ในการปรับปรุง สำหรับ Sprint สองสัปดาห์ จะใช้เวลาประมาณ 90 นาทีต่อสัปดาห์
Product Backlog ควรมีขนาดใหญ่แค่ไหน?
ไม่มีคำตอบที่เป็นสากล แต่ Backlog ที่มีรายการมากกว่า 100 รายการมักเป็นสัญญาณว่ารายการเก่าไม่ได้ถูกตัดออกไป ให้เน้นที่การรักษารายการ 20-30 รายการแรกให้ได้รับการปรับปรุงและพร้อมใช้งาน ส่วนที่เหลือสามารถมีรายละเอียดน้อยลงได้
Epic ในบริบทของ Product Backlog คืออะไร?
Epic คือ User Story ขนาดใหญ่ที่ใหญ่เกินกว่าจะทำเสร็จได้ใน Sprint เดียว Epic จะถูกแบ่งย่อยเป็น Story ที่เล็กลงในระหว่างการปรับปรุง Backlog Epic ทำหน้าที่เป็นภาชนะจัดระเบียบสำหรับฟีเจอร์ที่เกี่ยวข้อง
คุณจัดการกับข้อบกพร่องใน Product Backlog อย่างไร?
ข้อบกพร่องจะถูกพิจารณาว่าเป็นรายการ Backlog และจัดลำดับความสำคัญเทียบกับฟีเจอร์ ข้อบกพร่องที่สำคัญมักจะถูกจัดให้อยู่ในอันดับต้นๆ ส่วนข้อบกพร่องเล็กน้อยที่เกี่ยวกับความสวยงามอาจอยู่ต่ำกว่าฟีเจอร์หลายอย่าง บางทีมจะเก็บรายการข้อบกพร่องแยกต่างหากและรวมเข้ากับ Backlog เฉพาะเมื่อถึงเวลาจัดลำดับความสำคัญเท่านั้น
Product Backlog และ Roadmap แตกต่างกันอย่างไร?
Roadmap สื่อสารฟีเจอร์และไทม์ไลน์ที่วางแผนไว้ให้กับผู้มีส่วนได้ส่วนเสียในระดับสูง Backlog คือรายการงานภายในที่ดำเนินการได้ซึ่งจัดลำดับความสำคัญสำหรับการพัฒนา Roadmap มาจาก Backlog แต่แสดงมุมมองที่เรียบง่ายและมีกรอบเวลาที่เหมาะสมสำหรับผู้ชมภายนอก
จัดการ Backlog ของคุณด้วย TasksBoard
Product Backlog จะมีประโยชน์ก็ต่อเมื่อทีมสามารถมองเห็น อัปเดต และเชื่อถือได้ TasksBoard เปลี่ยนรายการ Google Task ที่แชร์ให้เป็นกระดาน Kanban แบบภาพ ซึ่งช่วยให้ทีมของคุณมีวิธีที่ง่ายและทำงานร่วมกันได้ในการจัดการรายการ Backlog โดยไม่ต้องตั้งค่าที่ซับซ้อน
สร้างรายการสำหรับขั้นตอน Backlog ของคุณ (Icebox, Backlog, In Progress, Done) เพิ่มงานพร้อมคำอธิบายและวันครบกำหนด และแชร์กระดานกับทุกคนในทีม นี่คือเส้นทางที่สั้นที่สุดจาก “เราจะสร้างอะไรต่อไป?” ไปสู่คำตอบที่ชัดเจนและแชร์กันได้
พร้อมที่จะแชร์ Google Tasks ของคุณหรือยัง?
เริ่มต้นใช้งาน TasksBoard ได้ฟรี ไม่ต้องใช้บัตรเครดิต
เข้าสู่ระบบ
