Backlog (แบ็คล็อก) คืออะไร?

Backlog (แบ็คล็อก) หรือ รายการงานค้าง ในภาษาไทย คือรายการงานที่ จัดลำดับความสำคัญ แล้ว ซึ่งทีมพัฒนาจะต้องดำเนินการ รายการเหล่านี้มาจากแผนที่ถนน (Roadmap) วิสัยทัศน์ของผลิตภัณฑ์ และข้อกำหนดจากผู้มีส่วนได้ส่วนเสีย (Stakeholders)

ใน Scrum และ Agile คำว่า Backlog เป็นหนึ่งในแนวคิดที่สำคัญที่สุด เพราะเป็น แหล่งข้อมูลหลักเดียว (Single Source of Truth) ที่ระบุว่าทีมจะทำอะไร เมื่อไหร่ และทำไม

คำว่า "Backlog" ในภาษาอังกฤษหมายถึง "งานที่สะสมรอดำเนินการ" ในบริบทของการพัฒนาซอฟต์แวร์ มันคือ รายการงานที่มีชีวิต ที่เปลี่ยนแปลงตลอดเวลาตามข้อมูลใหม่ Feedback จากผู้ใช้ และการเปลี่ยนแปลงของตลาด

Backlog มีความสำคัญด้วยเหตุผลหลายประการ:

1. เป็นเครื่องมือวางแผน

Backlog ทำหน้าที่เป็น รายการงานของโครงการ ที่ช่วยให้ทีมมองเห็นภาพรวมของงานทั้งหมดที่ต้องทำ ตั้งแต่ Feature ใหม่ไปจนถึงการแก้ Bug และ หนี้ทางเทคนิค (Technical Debt)

2. ส่งเสริมการจัดลำดับความสำคัญ

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

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

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

4. รองรับการเปลี่ยนแปลง

Backlog เป็น เอกสารมีชีวิต ที่เปลี่ยนแปลงได้ตลอดเวลาตามข้อมูลใหม่และความต้องการที่เปลี่ยนไป ต่างจากเอกสาร Requirements แบบเดิมที่ "ล็อก" ตั้งแต่ต้น

5. วัดความคืบหน้าได้

ทีมสามารถติดตามว่า Backlog หดเล็กลงหรือเติบโตขึ้น ช่วยในการ Forecast ว่าจะเสร็จเมื่อไหร่

Backlog ประกอบด้วยรายการหลายประเภท:

การจัดลำดับความสำคัญเป็นหัวใจของการจัดการ Backlog มีเทคนิคหลายวิธี:

MoSCoW Method

• Must have: ต้องมี — ขาดไม่ได้ สำคัญต่อ MVP
• Should have: ควรมี — สำคัญแต่ไม่ใช่ขั้นวิกฤต
• Could have: อาจมี — เป็นสิ่งที่ดีแต่ไม่จำเป็น
• Won't have: ไม่ต้องมี — ตัดออกจากรอบนี้

WSJF (Weighted Shortest Job First)

ใช้ใน SAFe โดยคำนวณจากสูตร: WSJF = Cost of Delay / Job Duration

Cost of Delay ประกอบด้วย:

• User-Business Value: คุณค่าต่อผู้ใช้และธุรกิจ
• Time Criticality: ความเร่งด่วน (ยิ่งช้ายิ่งเสียหาย)
• Risk Reduction / Opportunity Enablement: การลดความเสี่ยงหรือเปิดโอกาส

งานที่มีค่า WSJF สูงสุดควรทำก่อน เพราะหมายถึงงานที่ มีคุณค่าสูง และ ใช้เวลาน้อย

Value vs. Effort Matrix

จัดกลุ่มรายการตามสองแกน:

• คุณค่าสูง + ความพยายามต่ำ = ทำก่อน (Quick Wins)
• คุณค่าสูง + ความพยายามสูง = วางแผนอย่างดี (Big Bets)
• คุณค่าต่ำ + ความพยายามต่ำ = ทำเมื่อว่าง (Fill-ins)
• คุณค่าต่ำ + ความพยายามสูง = ไม่ทำ (Money Pit)

RICE Scoring

ใช้กันแพร่หลายในบริษัทเทคโนโลยี:

• Reach: จำนวนผู้ใช้ที่ได้รับผลกระทบ
• Impact: ผลกระทบต่อผู้ใช้แต่ละคน (1-3)
• Confidence: ระดับความมั่นใจ (%)
• Effort: ความพยายามที่ต้องใช้ (person-months)

RICE Score = (Reach x Impact x Confidence) / Effort

Kano Model

จัดหมวดหมู่ Feature ตามความพึงพอใจของลูกค้า:

• Basic (พื้นฐาน): ถ้าไม่มี ลูกค้าไม่พอใจ แต่ถ้ามี ก็ไม่ตื่นเต้น (เช่น ระบบ Login)
• Performance (ประสิทธิภาพ): ยิ่งดียิ่งพอใจ (เช่น ความเร็วในการโหลด)
• Excitement (ความตื่นเต้น): ถ้ามี ลูกค้าตื่นเต้น ถ้าไม่มีก็ไม่เสียหาย (เช่น AI แนะนำอาหาร)

Backlog Refinement (เดิมเรียก Backlog Grooming) เป็นกิจกรรมสำคัญที่ทีมทำเป็นประจำ ใน Scrum Guide กำหนดให้ใช้เวลาไม่เกิน 10% ของเวลาใน Sprint:

กิจกรรมใน Refinement

1. ชี้แจงรายละเอียด: อธิบาย User Stories ให้ชัดเจนขึ้น เขียน Acceptance Criteria ในรูปแบบ Given-When-Then
2. ประมาณขนาด: ใช้ Story Points หรือ T-Shirt Sizing
3. แตกรายการ: แบ่งรายการใหญ่ (Epic/Feature) ออกเป็นรายการเล็ก (User Stories) ที่จัดการได้ใน 1 Sprint
4. จัดลำดับใหม่: ปรับลำดับตามข้อมูลและสถานการณ์ใหม่
5. ลบรายการที่ไม่จำเป็น: กำจัดสิ่งที่ล้าสมัยหรือไม่มีคุณค่าอีกต่อไป
6. เพิ่มเงื่อนไขการยอมรับ: กำหนด Definition of Ready สำหรับแต่ละรายการ

แนวปฏิบัติที่ดี

• จัดทำ Refinement สัปดาห์ละ 1-2 ครั้ง ครั้งละ 30-60 นาที
• ใช้เวลาประมาณ 5-10% ของเวลาทั้ง Sprint
• เชิญ ทั้งทีม เข้าร่วม ไม่ใช่แค่ Product Owner
• รายการที่อยู่ บนสุด ของ Backlog ควรมีรายละเอียดมากที่สุด (รายการล่างๆ อาจเป็นแค่หัวข้อ)
• ใช้หลัก "2 Sprint Rule": รายการที่จะทำใน 2 Sprint ถัดไปต้อง Ready

Iceberg Model ของ Backlog

Backlog ที่ดีมีลักษณะคล้ายภูเขาน้ำแข็ง:

┌──────────────────┐ │ Sprint นี้ │ ← รายละเอียดมาก, Story Points ประมาณแล้ว │ (Ready) │ Acceptance Criteria ครบ ├──────────────────┤ │ Sprint หน้า │ ← มีรายละเอียดปานกลาง │ (In Refinement) │ กำลัง Refine อยู่ ├──────────────────┤ │ 2-3 Sprint ถัดไป │ ← เป็น Feature/Epic ใหญ่ๆ │ (Rough Ideas) │ ยังไม่แตก Story ├──────────────────┤ │ อนาคตไกล │ ← แค่ไอเดีย │ (Vision) │ อาจทำหรือไม่ทำก็ได้ └──────────────────┘

ใน Scrum มี Backlog สองประเภทที่สำคัญ:

Product Backlog

Sprint Backlog

ความสัมพันธ์

Product Backlog Sprint Backlog ┌──────────────────┐ ┌──────────────────┐ │ PBI #1 ★★★★★ │ ──────> │ PBI #1 │ │ PBI #2 ★★★★ │ ──────> │ PBI #2 │ │ PBI #3 ★★★★ │ ──────> │ PBI #3 │ │ PBI #4 ★★★ │ │ │ │ PBI #5 ★★ │ │ + Sprint Goal │ │ PBI #6 ★★ │ │ + แผนการทำงาน │ │ ... │ └──────────────────┘ └──────────────────┘ ↑ Sprint Planning ↑

ตัวอย่างจริง: แอปส่งอาหารในไทย

Product Backlog ของแอปส่งอาหาร:

1. ระบบค้นหาร้านอาหารใกล้เคียงด้วย GPS (Must have) ★★★★★
2. ระบบชำระเงินผ่าน PromptPay (Must have) ★★★★★
3. ระบบติดตามไรเดอร์แบบ Real-time (Must have) ★★★★
4. ระบบรีวิวร้านอาหาร (Should have) ★★★★
5. โปรแกรมสะสมแต้ม (Could have) ★★★
6. ระบบแนะนำอาหารด้วย AI (Won't have — รอบนี้) ★★
7. การจองร้านอาหาร (Won't have) ★

Sprint Backlog (Sprint ที่ 1):

• Sprint Goal: "ผู้ใช้สามารถค้นหาและสั่งอาหารจากร้านใกล้เคียงได้"
• User Story 1: ค้นหาร้านตามตำแหน่ง GPS → Task: สร้าง API ค้นหา, สร้าง UI แผนที่
• User Story 2: ดูเมนูของร้าน → Task: สร้างหน้าเมนู, สร้าง API ดึงข้อมูลเมนู
• User Story 3: เพิ่มอาหารลงตะกร้า → Task: สร้างระบบตะกร้า, สร้าง UI ตะกร้า
• User Story 4: ยืนยันคำสั่งซื้อ → Task: สร้างหน้ายืนยัน, สร้างระบบ Notification

วิธีวัดว่า Backlog "แข็งแรง" หรือไม่

Anti-patterns ของ Backlog

1. Backlog อ้วน: มีรายการ 500+ รายการ ไม่มีใครรู้ว่าอะไรสำคัญ
2. Zombie Backlog Items: รายการที่อยู่มานานหลายเดือน ไม่มีใครทำ ไม่มีใครลบ
3. Backlog เป็นทางการเกินไป: ต้องเขียนรายละเอียดครบถ้วนก่อนใส่ Backlog
4. Product Owner ไม่ดูแล: Backlog ไม่ถูก Refine สม่ำเสมอ
5. ไม่มี Product Goal: Backlog เป็นแค่ "รายการสิ่งที่ต้องทำ" โดยไม่มีทิศทาง

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

1. "ผู้ใหญ่ขอ" (HiPPO): ในวัฒนธรรมไทย การจัดลำดับ Backlog อาจถูกอิทธิพลจาก "ความต้องการของผู้บริหาร" มากกว่าข้อมูล (HiPPO = Highest Paid Person's Opinion)
2. ขาด Product Owner ที่มีอำนาจจริง: PO ไทยหลายคนไม่มีอำนาจตัดสินใจ ต้องขอ Approval จากหลายชั้น
3. Scope Creep: ลูกค้าหรือผู้บริหารเพิ่มงานเข้ามาตลอดโดยไม่ลบอะไรออก
4. ไม่กล้าพูด "ไม่": วัฒนธรรมที่หลีกเลี่ยงความขัดแย้งทำให้ Backlog เต็มไปด้วยรายการที่ไม่มีใครกล้าตัดออก

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

• ใช้ข้อมูล: นำเสนอ Data (User Analytics, A/B Test Results) ประกอบการจัดลำดับ แทนที่จะพึ่ง "ความรู้สึก" หรือ "ผู้ใหญ่สั่ง"
• ทำ Backlog Cleanup ทุกเดือน: ลบรายการที่ไม่ทำมานานกว่า 3 เดือน
• ตั้ง WIP Limit สำหรับ Backlog: จำกัดจำนวนรายการใน Backlog เช่น ไม่เกิน 100 รายการ
• สอน Stakeholders เรื่อง Trade-off: "ถ้าเพิ่ม Feature A เข้ามา ต้องเลื่อน Feature B ออกไป"

Backlog ไม่ใช่เอกสารที่เขียนแล้วจบ มันคือ เอกสารมีชีวิต ที่ควร:

• เติบโต ตามที่ทีมเรียนรู้เพิ่มเติมจาก Sprint Review และ Feedback ของผู้ใช้
• หดตัว เมื่อรายการที่ไม่จำเป็นถูกตัดออกอย่างกล้าหาญ
• ปรับลำดับ ตามข้อมูลใหม่จากตลาดและผู้ใช้
• สะท้อนความจริง ของสิ่งที่ต้องทำเสมอ ไม่ใช่ "Wishlist" ที่ไม่มีวันทำ

Product Owner ที่ดีจะทำให้ Backlog สะอาด ชัดเจน และทันสมัย อยู่เสมอ เปรียบได้กับ "สวนที่ต้องดูแล" — ต้องรดน้ำ (Refine) ตัดแต่ง (Remove) และปลูกใหม่ (Add) อย่างสม่ำเสมอ

Backlog กับ To-Do List ต่างกันอย่างไร?

To-Do List เป็นแค่รายการงาน ส่วน Backlog มีการ จัดลำดับความสำคัญ มี เจ้าของ (Product Owner) มี กระบวนการปรับปรุง (Refinement) และเชื่อมโยงกับ เป้าหมาย (Product Goal) Backlog เป็น เครื่องมือเชิงกลยุทธ์ ไม่ใช่แค่รายการงาน

ใครเป็นคนตัดสินใจว่าอะไรเข้า Backlog?

Product Owner เป็นผู้มีอำนาจสูงสุดในการจัดการ Product Backlog ตาม Scrum Guide แต่ข้อมูลมาจากหลายแหล่ง: Stakeholders, ทีมพัฒนา, ข้อมูลผู้ใช้, และกลยุทธ์ธุรกิจ

Backlog ควรมีกี่รายการ?

ไม่มีตัวเลขตายตัว แต่โดยทั่วไป Product Backlog ที่ดีควรมีงาน 3-6 เดือน ข้างหน้า สำหรับทีม Scrum ที่ทำ 2-week Sprint ประมาณ 50-100 รายการ หากมากกว่า 200 รายการ อาจต้อง Cleanup

ควรใส่ Bug ใน Backlog หรือแก้ทันที?

ขึ้นอยู่กับความรุนแรง:

• Critical Bug (ระบบล่ม, ข้อมูลรั่ว): แก้ทันที ไม่ต้องใส่ Backlog
• Major Bug (ฟังก์ชันหลักใช้ไม่ได้): ใส่ Backlog อันดับสูง
• Minor Bug (ปัญหาเล็กน้อย): ใส่ Backlog จัดลำดับตามปกติ

Backlog Refinement ใช้เวลาเท่าไหร่?

Scrum Guide แนะนำ ไม่เกิน 10% ของเวลา Sprint สำหรับ Sprint 2 สัปดาห์ คือประมาณ 4-8 ชั่วโมง ทั้ง Sprint แบ่งเป็นสัปดาห์ละ 1-2 ชั่วโมง

Product Backlog กับ Sprint Backlog — อันไหนสำคัญกว่า?

ทั้งสองสำคัญแต่ต่างระดับ Product Backlog คือ "อะไร" ที่จะทำในระยะยาว ส่วน Sprint Backlog คือ "อะไร" ที่จะทำในระยะสั้น (Sprint นี้) ไม่มี Sprint Backlog ที่ดีถ้า Product Backlog ไม่ดี

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