PBI (Product Backlog Item) คืออะไร?

Product Backlog Item (PBI) หรือ รายการ Product Backlog คือคำที่ใช้ใน Scrum แทนข้อกำหนดหรือชิ้นงานที่ต้องทำ PBI เป็น หน่วยงานพื้นฐาน ที่อยู่ใน Product Backlog ซึ่งจัดการโดย Product Owner

ตาม Scrum Guide (2020) PBI คือรายการที่อธิบาย การเปลี่ยนแปลงที่ต้องทำ กับผลิตภัณฑ์ เพื่อสร้างคุณค่าให้กับผู้ใช้และธุรกิจ PBI ไม่ได้จำกัดแค่ User Stories เท่านั้น แต่ยังรวมถึง Bug งานทางเทคนิค Spikes และรายการปรับปรุงอื่นๆ

ในบริบทของทีมพัฒนาซอฟต์แวร์ในประเทศไทย PBI เป็นแนวคิดที่สำคัญมาก เพราะเป็น ภาษากลาง ที่ทีมใช้ในการสื่อสารว่า "ต้องทำอะไรบ้าง" ตั้งแต่ทีมในธนาคารใหญ่ที่ใช้ Jira ไปจนถึงสตาร์ทอัพที่ใช้ Linear หรือ Trello

PBI เป็นสิ่งสำคัญในการจัดระเบียบและจัดลำดับความสำคัญของงานด้วยเหตุผลหลายประการ:

1. เป็นหน่วยของคุณค่า

แต่ละ PBI ควรส่งมอบ คุณค่า ที่ชัดเจน ไม่ว่าจะเป็นคุณค่าต่อผู้ใช้ (เช่น ฟีเจอร์ใหม่) หรือคุณค่าต่อทีม (เช่น การลด Technical Debt)

2. สร้างความโปร่งใส

PBI ที่ดีช่วยให้ทุกคนในทีมและ Stakeholders เห็น ภาพรวมของงานทั้งหมด ที่ต้องทำ รวมถึงลำดับความสำคัญ

3. รองรับการวางแผน

PBI เป็นพื้นฐานสำหรับ Sprint Planning ที่ทีมเลือก PBI มาทำใน Sprint และสร้าง Sprint Backlog

4. ช่วยในการ Forecast

เมื่อ PBI ถูกประมาณขนาด (Estimation) ทีมสามารถ Forecast ได้ว่าจะส่งมอบงานได้เมื่อไหร่

5. ส่งเสริมการปรับปรุงอย่างต่อเนื่อง

PBI ถูกปรับปรุง (Refine) อย่างสม่ำเสมอ สะท้อนการเรียนรู้ใหม่จาก Sprint Review และ Feedback ของผู้ใช้

PBI มีหลายรูปแบบ ไม่ได้จำกัดแค่ User Stories:

1. User Story (เรื่องราวของผู้ใช้)

รูปแบบที่นิยมที่สุด อธิบายจากมุมมองผู้ใช้:

ในฐานะ [ผู้ใช้ประเภทใด] ฉันต้องการ [ฟังก์ชันอะไร] เพื่อ [คุณค่าอะไร]

ตัวอย่าง: ในฐานะลูกค้าธนาคาร ฉันต้องการโอนเงินผ่าน PromptPay เพื่อชำระค่าสินค้าอย่างสะดวก

2. Bug Fix (การแก้ไขข้อบกพร่อง)

รายงานปัญหาที่ต้องแก้ไข:

ตัวอย่าง: ปุ่ม "ชำระเงิน" ไม่ทำงานบน iOS 17.5 เมื่อใช้ Safari — ต้องแก้ไขให้ใช้งานได้ปกติ

3. Technical Debt (หนี้ทางเทคนิค)

งานปรับปรุงโค้ดหรือโครงสร้างภายใน:

ตัวอย่าง: Refactor ระบบ Authentication เก่าจาก Session-based เป็น JWT Token เพื่อรองรับ Microservices

4. Spike (งานวิจัย/สำรวจ)

งานวิจัยเพื่อลดความไม่แน่นอน:

ตัวอย่าง: สำรวจ Payment Gateway 3 ตัว (Omise, 2C2P, Stripe) เพื่อเปรียบเทียบค่าธรรมเนียมและ API

5. Enabler (งานเตรียมพื้นฐาน)

งานเตรียมโครงสร้างพื้นฐานที่จำเป็น:

ตัวอย่าง: ตั้งค่า CI/CD Pipeline สำหรับ Deploy อัตโนมัติไปยัง AWS ECS

6. Improvement (การปรับปรุง)

ปรับปรุงสิ่งที่มีอยู่ให้ดีขึ้น:

ตัวอย่าง: ปรับปรุงความเร็วหน้าค้นหาร้านอาหารจาก 3 วินาทีเหลือ 1 วินาที

PBI ที่ดีควรมีคุณลักษณะตามหลัก INVEST:

PBI ผ่านหลายขั้นตอนตั้งแต่เกิดจนถึงส่งมอบ:

[สร้าง] [Refine] [Ready] [เลือก] [พัฒนา] [เสร็จ] │ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ ▼ ไอเดีย → เพิ่มรายละเอียด → ผ่าน DoR → Sprint Planning → Sprint → Done (ผ่าน DoD) ↓ Sprint Review ↓ Increment

1. สร้าง (Creation)

PBI ถูกสร้างจากหลายแหล่ง:

• Product Owner: จากวิสัยทัศน์ผลิตภัณฑ์และ Roadmap
• Stakeholders: ความต้องการทางธุรกิจ
• ผู้ใช้: Feedback, Support Tickets
• ทีมพัฒนา: Technical Debt, Improvements
• ข้อมูล: Analytics, A/B Test Results

2. Refinement (ปรับปรุง)

PBI ถูก Refine ให้พร้อม:

• เพิ่มรายละเอียดและ Acceptance Criteria
• ประมาณขนาดด้วย Story Points หรือ T-Shirt Sizing
• แตกย่อยถ้าใหญ่เกินไป
• เพิ่ม Mockup หรือ Wireframe ถ้าจำเป็น

3. Ready (พร้อม)

PBI ผ่าน Definition of Ready (DoR) เช่น:

• มี Acceptance Criteria ครบ
• ประมาณขนาดแล้ว
• ไม่มี Dependencies ที่ยังไม่แก้
• ทีมเข้าใจตรงกัน

4. เลือกเข้า Sprint

ใน Sprint Planning ทีมเลือก PBI จากด้านบนของ Product Backlog มาสร้าง Sprint Backlog

5. พัฒนาใน Sprint

ทีมพัฒนา PBI ใน Sprint โดย:

• แตกเป็น Tasks
• พัฒนาโค้ด
• ทดสอบ
• Code Review

6. Done (เสร็จ)

PBI ผ่าน Definition of Done (DoD) กลายเป็นส่วนหนึ่งของ Increment ที่พร้อมส่งมอบ

โครงสร้าง PBI

หัวข้อ: [ชื่อสั้นๆ ที่สื่อความหมาย] คำอธิบาย: ในฐานะ [ผู้ใช้ประเภทใด] ฉันต้องการ [ฟังก์ชันอะไร] เพื่อ [คุณค่าอะไร] Acceptance Criteria: Scenario 1: [ชื่อสถานการณ์] Given [เงื่อนไขเริ่มต้น] When [การกระทำ] Then [ผลลัพธ์ที่คาดหวัง] Scenario 2: [ชื่อสถานการณ์] Given [เงื่อนไขเริ่มต้น] When [การกระทำ] Then [ผลลัพธ์ที่คาดหวัง] ขนาด: [Story Points] ลำดับ: [สูง/กลาง/ต่ำ] Dependencies: [ถ้ามี]

ตัวอย่าง PBI สำหรับแอปส่งอาหารในไทย

หัวข้อ: ระบบชำระเงินผ่าน PromptPay คำอธิบาย: ในฐานะลูกค้า ฉันต้องการชำระเงินค่าอาหารผ่าน PromptPay เพื่อความสะดวกในการชำระเงินโดยไม่ต้องใช้บัตรเครดิต Acceptance Criteria: Scenario: ชำระเงินผ่าน PromptPay สำเร็จ Given ฉันมีคำสั่งซื้ออาหารมูลค่า 350 บาท And ฉันเลือกวิธีชำระเงิน "PromptPay" When ฉันสแกน QR Code ด้วยแอปธนาคาร And การชำระเงินสำเร็จ Then ฉันเห็นหน้ายืนยันคำสั่งซื้อ And ฉันได้รับ Push Notification "ชำระเงินสำเร็จ 350 บาท" And ระบบเริ่มจับคู่ไรเดอร์ Scenario: QR Code หมดอายุ Given ฉันมี QR Code สำหรับชำระเงิน And QR Code ถูกสร้างมานานกว่า 15 นาที When ฉันสแกน QR Code Then ฉันเห็นข้อความ "QR Code หมดอายุ กรุณาสร้างใหม่" And ระบบสร้าง QR Code ใหม่อัตโนมัติ ขนาด: 8 Story Points ลำดับ: Must Have (MVP) Dependencies: API เชื่อมต่อ PromptPay Gateway 

วิธีการประมาณ

เทคนิค Planning Poker

1. Product Owner อธิบาย PBI
2. ทีมถามคำถามเพื่อทำความเข้าใจ
3. แต่ละคนเลือกไพ่ (Story Points) โดยไม่เห็นของคนอื่น
4. เปิดไพ่พร้อมกัน
5. คนที่ให้คะแนนสูงสุดและต่ำสุดอธิบายเหตุผล
6. อภิปรายและโหวตอีกรอบจนตกลงกันได้

PBI มีบทบาทในทุก Scrum Event:

PBI ใน Product Backlog

Product Backlog (เรียงตามลำดับ) ┌─────────────────────────────────────┐ │ PBI #1: PromptPay Payment ★★★★★ │ ← Ready, 8 pts │ PBI #2: Order Tracking ★★★★ │ ← Ready, 5 pts │ PBI #3: Restaurant Search ★★★★ │ ← Ready, 3 pts │ PBI #4: Rating System ★★★ │ ← In Refinement │ PBI #5: Loyalty Points ★★ │ ← Rough Idea │ PBI #6: AI Recommendation ★ │ ← Future └─────────────────────────────────────┘ ↑ Product Goal: "แพลตฟอร์มสั่งอาหารที่ดีที่สุดในกรุงเทพ"

PBI ใน Sprint Backlog

เมื่อ PBI ถูกเลือกเข้า Sprint จะถูกแตกเป็น Tasks:

Sprint Backlog ┌──────────────────────────────────────────┐ │ Sprint Goal: "ลูกค้าสามารถชำระเงินและ │ │ ติดตามคำสั่งซื้อได้" │ │ │ │ PBI #1: PromptPay Payment │ │ ├── Task: สร้าง API เชื่อมต่อ Gateway │ │ ├── Task: สร้าง QR Code Generator │ │ ├── Task: สร้าง UI หน้าชำระเงิน │ │ ├── Task: เขียน Unit Tests │ │ └── Task: Integration Test │ │ │ │ PBI #2: Order Tracking │ │ ├── Task: สร้าง WebSocket สำหรับ │ │ │ Real-time Tracking │ │ ├── Task: สร้าง Map UI │ │ └── Task: เขียน Tests │ └──────────────────────────────────────────┘

ความท้าทายเฉพาะ

1. PBI ที่เขียนไม่ชัดเจน: หลายทีมในไทยเขียน PBI แบบ "ขออะไร" โดยไม่ระบุ "เพื่ออะไร" ทำให้ทีมพัฒนาไม่เข้าใจคุณค่าที่แท้จริง
2. PBI ที่ใหญ่เกินไป: เป็น Epic ที่ยังไม่แตก เช่น "ทำระบบ CRM ทั้งหมด" แทนที่จะเป็น User Stories ขนาดเล็ก
3. ไม่มี Acceptance Criteria: PBI หลายตัวไม่มี Acceptance Criteria ทำให้ไม่รู้ว่า "เสร็จ" คืออะไร
4. Estimation ไม่สม่ำเสมอ: บางทีมไม่ประมาณขนาด ทำให้ไม่สามารถ Forecast ได้

แนวทางสำหรับทีมไทย

• สอน User Story Format: ฝึกให้ทีมเขียน "ในฐานะ...ฉันต้องการ...เพื่อ..."
• ใช้ Given-When-Then: เขียน Acceptance Criteria ในรูปแบบ Gherkin
• ทำ Three Amigos: ให้ PO, Dev และ Tester ร่วมกัน Refine PBI
• จัด Backlog Refinement สม่ำเสมอ: สัปดาห์ละ 1-2 ครั้ง
• ใช้ Definition of Ready: กำหนดว่า PBI ต้องมีอะไรบ้างก่อนเข้า Sprint

PBI กับ User Story คือสิ่งเดียวกันหรือไม่?

ไม่เหมือนกัน PBI เป็นคำกว้างที่หมายถึง รายการใดๆ ใน Product Backlog ส่วน User Story เป็น รูปแบบหนึ่ง ของ PBI User Story เป็น PBI แต่ PBI ไม่จำเป็นต้องเป็น User Story เสมอไป (อาจเป็น Bug, Spike, Technical Debt)

PBI ควรมีขนาดเท่าไหร่?

PBI ที่ดีควรทำเสร็จได้ภายใน 1 Sprint (1-4 สัปดาห์) ถ้าเป็น Story Points ควรอยู่ที่ 1-8 points ถ้ามากกว่า 13 ควรแตกย่อย PBI ที่ใหญ่เกินไปเรียกว่า "Epic" หรือ "Feature" ต้องแตกก่อนนำเข้า Sprint

ใครเป็นคนสร้าง PBI?

ใครก็ได้ สามารถเสนอ PBI ได้ ทั้ง Product Owner, ทีมพัฒนา, Stakeholders หรือแม้แต่ผู้ใช้ แต่ Product Owner เป็นผู้มีอำนาจสูงสุดในการจัดลำดับและตัดสินใจว่า PBI ใดจะอยู่ใน Backlog

PBI ควรมี Acceptance Criteria กี่ข้อ?

ไม่มีจำนวนตายตัว แต่โดยทั่วไป PBI ขนาดเล็กถึงกลางควรมี 3-7 Acceptance Criteria ถ้าน้อยเกินไปอาจไม่ชัดเจน ถ้ามากเกินไป PBI อาจใหญ่เกินและควรแตก

ถ้า PBI ทำไม่เสร็จใน Sprint ทำอย่างไร?

PBI ที่ทำไม่เสร็จจะ กลับไปที่ Product Backlog ไม่ใช่ย้ายเข้า Sprint ถัดไปอัตโนมัติ Product Owner จะจัดลำดับใหม่ว่าควรทำต่อใน Sprint หน้าหรือไม่ ส่วน Sprint Goal ยังคงเป็นตัววัดว่า Sprint ประสบความสำเร็จหรือไม่

Definition of Ready กับ Definition of Done ต่างกันอย่างไรในบริบท PBI?

• Definition of Ready (DoR): เกณฑ์ที่ PBI ต้องผ่าน ก่อน นำเข้า Sprint (เช่น มี Acceptance Criteria, ประมาณขนาดแล้ว)
• Definition of Done (DoD): เกณฑ์ที่ PBI ต้องผ่าน หลัง พัฒนาเสร็จ เพื่อถือว่า "Done" (เช่น Code Reviewed, Tests ผ่าน, Deploy แล้ว)

Product Backlog Item (PBI) เป็น หน่วยงานพื้นฐาน ของ Scrum ที่ช่วยให้ทีมจัดระเบียบ จัดลำดับ และส่งมอบคุณค่าอย่างต่อเนื่อง PBI ที่ดีควรเป็นไปตามหลัก INVEST — อิสระ เจรจาได้ มีคุณค่า ประมาณได้ เล็กพอ และทดสอบได้ สิ่งสำคัญคือ PBI ไม่ได้มีแค่ User Stories แต่รวมถึง Bug, Spikes, Technical Debt และ Improvements ด้วย การจัดการ PBI อย่างมีระบบผ่าน Backlog Refinement สม่ำเสมอ คือกุญแจสำคัญของทีม Agile ที่ประสบความสำเร็จ