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 ควรมี acceptance criteria คือเงื่อนไขที่เฉพาะเจาะจงและทดสอบได้ ซึ่งต้องเป็นจริงเพื่อให้รายการนั้นถือว่าเสร็จสมบูรณ์
ตัวอย่าง acceptance criteria สำหรับ story การกรองงาน:
- ผู้ใช้สามารถกรองตามผู้รับผิดชอบหนึ่งคนหรือมากกว่าพร้อมกันได้
- มุมมองที่กรองแล้วจะอัปเดตแบบเรียลไทม์โดยไม่ต้องโหลดหน้าใหม่
- สถานะการกรองจะถูกเก็บไว้เมื่อผู้ใช้ออกจากหน้าไปและกลับมาใหม่
- งานที่ไม่มีผู้รับผิดชอบจะปรากฏขึ้นเมื่อเลือก “Unassigned”
หากไม่มี acceptance criteria คำว่า “เสร็จ” ก็จะไม่มีนิยามที่ชัดเจน แต่ถ้ามี ทั้งนักพัฒนาและผู้ทดสอบจะรู้แน่ชัดว่าต้องตรวจสอบอะไรบ้าง
เกณฑ์ INVEST
User story ที่ดีต้องเป็นไปตามเกณฑ์ INVEST:
| ตัวอักษร | ความหมาย |
|---|---|
| I | Independent: สามารถพัฒนาได้โดยไม่ต้องพึ่งพา story อื่น |
| N | Negotiable: รายละเอียดสามารถปรับเปลี่ยนได้ในการพูดคุย |
| V | Valuable: ส่งมอบคุณค่าให้กับผู้ใช้หรือธุรกิจ |
| E | Estimable: ทีมสามารถประเมินความพยายามที่ต้องใช้ได้ |
| S | Small: สามารถทำให้เสร็จภายในหนึ่ง sprint |
| T | Testable: มี acceptance criteria ที่ชัดเจน |
Story ที่ไม่ผ่านเกณฑ์เหล่านี้จำเป็นต้องได้รับการปรับปรุงก่อนที่จะเข้าสู่ sprint โดยปกติจะเกิดขึ้นเมื่อ story นั้นใหญ่เกินไป คลุมเครือเกินไป หรือไม่สามารถส่งมอบแยกต่างหากได้
เทคนิคการจัดลำดับความสำคัญของ Backlog
การจัดลำดับความสำคัญคือจุดที่วิจารณญาณด้านผลิตภัณฑ์และข้อมูลมาบรรจบกัน กรอบแนวคิดหลายอย่างช่วยสร้างโครงสร้างสำหรับการตัดสินใจจัดลำดับความสำคัญ
วิธี MoSCoW
จัดหมวดหมู่แต่ละรายการเป็น Must have, Should have, Could have หรือ Won’t have (สำหรับรุ่นนี้) สิ่งนี้จะสร้างระบบลำดับความสำคัญสี่ระดับที่เรียบง่าย ซึ่งผู้มีส่วนได้ส่วนเสียสามารถเข้าใจและมีส่วนร่วมได้
การให้คะแนน RICE
RICE ย่อมาจาก Reach, Impact, Confidence, Effort แต่ละรายการจะถูกให้คะแนนตามมิติเหล่านี้และจัดอันดับตามคะแนน RICE: (Reach × Impact × Confidence) / Effort
นี่คือการจัดลำดับความสำคัญเชิงปริมาณ ซึ่งได้ผลดีเมื่อคุณมีข้อมูลเกี่ยวกับ Reach และ Impact และต้องการการจัดอันดับที่สามารถอธิบายได้มากกว่าแค่ความรู้สึก
เมทริกซ์ Value vs. Effort
พล็อตรายการ backlog แต่ละรายการบนเมทริกซ์ 2x2: คุณค่าบนแกนหนึ่ง และความพยายามบนอีกแกนหนึ่ง รายการที่อยู่ในช่องคุณค่าสูงและความพยายามต่ำคือชัยชนะที่รวดเร็วและควรได้รับลำดับความสำคัญก่อน ส่วนรายการที่อยู่ในช่องคุณค่าต่ำและความพยายามสูงคือตัวเลือกสำหรับการลบออก
โมเดล Kano
โมเดล Kano จัดหมวดหมู่ฟีเจอร์ตามผลกระทบต่อความพึงพอใจของผู้ใช้:
- Basic needs: ถ้าไม่มีจะทำให้เกิดความไม่พอใจ การมีอยู่ของมันเป็นสิ่งที่คาดหวัง (must-haves)
- Performance needs: ยิ่งมีมากยิ่งดี (ฟีเจอร์หลัก)
- Delighters: ฟีเจอร์ที่ไม่คาดคิดซึ่งช่วยเพิ่มความพึงพอใจอย่างมาก
กรอบแนวคิดนี้ช่วยสร้างสมดุลระหว่างสิ่งที่ต้องมีกับนวัตกรรม
การดูแล Backlog (Refinement)
การดูแล backlog หรือที่เรียกว่า backlog refinement คือกระบวนการที่ทำซ้ำๆ ในการตรวจสอบ อัปเดต และปรับปรุงรายการใน backlog ใน Scrum โดยปกติจะเกิดขึ้นหนึ่งครั้งต่อ sprint ในรูปแบบการประชุมแยกต่างหาก
เซสชันการดูแลประกอบด้วย:
- การตรวจสอบรายการใหม่: รายการที่ถูกเพิ่มเข้ามาตั้งแต่การดูแลครั้งล่าสุด เขียนชัดเจนหรือไม่? มี acceptance criteria หรือไม่?
- การประเมินรายการ: ทีมประเมินความพยายามสำหรับรายการที่อยู่ใกล้ด้านบนของ backlog เพื่อให้พร้อมสำหรับการวางแผน sprint
- การย่อยรายการขนาดใหญ่: epics และ story ขนาดใหญ่จะถูกย่อยเป็นรายการขนาดเล็กที่เหมาะกับ sprint
- การตัดแต่ง: ลบรายการที่ไม่เกี่ยวข้อง ล้าสมัย หรือซ้ำซ้อนออก
- การจัดลำดับใหม่: ปรับลำดับตามข้อมูลใหม่ ผลตอบรับจากผู้มีส่วนได้ส่วนเสีย หรือลำดับความสำคัญทางธุรกิจที่เปลี่ยนไป
จังหวะการดูแลที่ดีหมายความว่าด้านบนของ backlog ของคุณพร้อมสำหรับ sprint ถัดไปเสมอ นั่นคือมีการเขียน ประเมิน และจัดลำดับความสำคัญเรียบร้อยแล้ว
การรักษา Backlog ให้มีสุขภาพดี
Backlog ที่เติบโตอย่างไม่มีที่สิ้นสุดโดยไม่มีการตัดแต่งจะกลายเป็นภาระ ทีมจะหยุดเชื่อมั่นใน backlog เพราะรู้ว่ามันเต็มไปด้วยรายการที่ไม่มีใครตั้งใจจะสร้าง นี่คือสัญญาณของ backlog ที่ดีและวิธีการรักษาไว้
สัญญาณของ Backlog ที่ดี
- รายการสิบถึงสิบห้าอันดับแรกได้รับการปรับปรุงและพร้อมสำหรับ sprint
- ทุกรายการมีชื่อและ acceptance criteria ที่ชัดเจน
- 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: วิธีการจัดเซสชันที่มีประสิทธิภาพ และคู่มือ User Story Mapping
เครื่องมือสำหรับจัดการ Product Backlog
| เครื่องมือ | เหมาะสำหรับ | ฟีเจอร์ Backlog | ราคา |
|---|---|---|---|
| Jira | ทีมวิศวกรรมขนาดใหญ่ | Epics, stories, sprints, การรายงาน | $7.75/ผู้ใช้/เดือน |
| Linear | ทีมวิศวกรรมผลิตภัณฑ์ | UI ที่สะอาด, cycles, roadmaps | ฟรี / $8/เดือน |
| TasksBoard | ทีม Google Workspace | Kanban, รายการงานที่แชร์ร่วมกัน | ฟรี / พรีเมียม |
| Notion | ทีมที่ยืดหยุ่น | ฐานข้อมูลที่ปรับแต่งได้, มุมมองต่างๆ | ฟรี / $8/เดือน |
| Trello | ทีมขนาดเล็ก | การ์ด, รายการ, ป้ายกำกับ | ฟรี / $5/เดือน |
| Asana | ทีมข้ามสายงาน | Portfolio, ไทม์ไลน์, ภาระงาน | ฟรี / $10.99/เดือน |
สำหรับทีมที่ใช้ Google Workspace, TasksBoard มอบวิธีที่ตรงไปตรงมาในการจัดการรายการ backlog ในรูปแบบรายการ Google Tasks ที่แชร์ร่วมกันพร้อมมุมมอง kanban โดยไม่ต้องมีภาระของแพลตฟอร์มการจัดการโครงการเฉพาะทาง
คำถามที่พบบ่อย
ใครเป็นเจ้าของ product backlog?
Product Owner เป็นเจ้าของ backlog และรับผิดชอบต่อเนื้อหา ลำดับ และความพร้อมใช้งาน ทีมพัฒนาจะช่วยประเมินและให้ข้อมูลทางเทคนิค แต่ PO เป็นผู้ตัดสินใจขั้นสุดท้ายเรื่องลำดับความสำคัญ
ควรดูแล backlog บ่อยแค่ไหน?
ทีม Scrum ส่วนใหญ่จะดูแลหนึ่งครั้งต่อ sprint โดยใช้เวลาประมาณ 10% ของความจุ sprint ในการปรับปรุง สำหรับ sprint สองสัปดาห์ นี่คือประมาณ 90 นาทีต่อสัปดาห์
Product backlog ควรมีขนาดใหญ่แค่ไหน?
ไม่มีคำตอบที่เป็นสากล แต่ backlog ที่มีมากกว่า 100 รายการมักเป็นสัญญาณว่ารายการเก่าไม่ได้ถูกตัดแต่งออก ให้เน้นที่การปรับปรุงรายการ 20–30 อันดับแรกให้พร้อม ส่วนที่เหลือสามารถมีรายละเอียดน้อยลงได้
Epic ในบริบทของ product backlog คืออะไร?
Epic คือ user story ขนาดใหญ่ที่ใหญ่เกินกว่าจะทำให้เสร็จใน sprint เดียว Epic จะถูกย่อยเป็น story ที่เล็กลงในระหว่างการดูแล backlog โดยทำหน้าที่เป็นภาชนะจัดกลุ่มสำหรับฟีเจอร์ที่เกี่ยวข้อง
คุณจัดการกับบั๊กใน product backlog อย่างไร?
บั๊กจะถูกปฏิบัติเหมือนรายการ backlog และจัดลำดับความสำคัญเทียบกับฟีเจอร์ บั๊กที่สำคัญมักจะถูกเลื่อนขึ้นไปด้านบน บั๊กเล็กน้อยอาจอยู่ต่ำกว่าฟีเจอร์หลายรายการ บางทีมเก็บรายการบั๊กแยกต่างหากและรวมเข้ากับ backlog เฉพาะตอนจัดลำดับความสำคัญเท่านั้น
ความแตกต่างระหว่าง product backlog และ roadmap คืออะไร?
Roadmap สื่อสารฟีเจอร์ที่วางแผนไว้และไทม์ไลน์ให้กับผู้มีส่วนได้ส่วนเสียในระดับสูง Backlog คือรายการงานภายในเชิงปฏิบัติการที่จัดลำดับความสำคัญสำหรับการพัฒนา Roadmap ถูกดึงมาจาก backlog แต่แสดงมุมมองที่เรียบง่ายและมีกรอบเวลาที่เหมาะสมสำหรับผู้ชมภายนอก
จัดการ Backlog ของคุณด้วย TasksBoard
Product backlog จะมีประโยชน์ก็ต่อเมื่อทีมสามารถมองเห็น อัปเดต และเชื่อมั่นในมันได้ TasksBoard เปลี่ยนรายการ Google Tasks ที่แชร์ร่วมกันให้เป็นกระดาน kanban แบบภาพ ทำให้ทีมของคุณมีวิธีที่เรียบง่ายและทำงานร่วมกันได้ในการจัดการรายการ backlog โดยไม่ต้องตั้งค่าที่ซับซ้อน
สร้างรายการสำหรับขั้นตอน backlog ของคุณ (Icebox, Backlog, In Progress, Done), เพิ่มงานพร้อมคำอธิบายและวันครบกำหนด และแชร์กระดานกับทุกคนในทีม นี่คือเส้นทางที่สั้นที่สุดจาก “เราจะสร้างอะไรต่อไป?” ไปสู่คำตอบที่ชัดเจนและแชร์ร่วมกัน
พร้อมที่จะแชร์ Google Tasks ของคุณหรือยัง?
เริ่มต้นใช้งาน TasksBoard ได้ฟรี ไม่ต้องใช้บัตรเครดิต
เข้าสู่ระบบ
