Imported from Kaitock/2026-Raise2-Jirapan (.claude/skills/product-backlog/SKILL.md). Install upstream with npx skills add Kaitock/2026-Raise2-Jirapan --skill product-backlog. Copyright stays with the author.

การสร้าง Product Backlog

ก่อนเริ่ม

1. อ่าน CLAUDE.md ของ workspace — ID convention และกฎเอกสารอยู่ที่นั่น
2. อ่าน spec ต้นทางใน docs/01-requirements/01-spec/ ให้ครบก่อน — backlog ที่ไม่ผูกกับ spec คือการเดาขอบเขต ถ้ายังไม่มี spec ให้ทำ spec ก่อน (skill requirement-spec)
3. ไฟล์ที่จะเขียน:
   • docs/01-requirements/backlog.md — backlog รวมของทั้งโปรเจกต์: epic, story, priority, estimate, MVP, sprint plan เป็นไฟล์เดียว ห้ามแตกเป็นหลายไฟล์ และต้องอัปเดตทุกครั้งที่ spec เปลี่ยน
   • docs/01-requirements/03-task/sprint-01-tasks.md — task breakdown ของ sprint แรกเท่านั้น
   • docs/01-requirements/02-plan/ ใช้เก็บ roadmap ระยะยาวและ RTM ที่ต่อยอดจาก backlog.md — ไม่ใช่ที่เก็บ backlog ตัวที่สอง อย่าสร้าง product-backlog.md ซ้ำที่นั่น
   • เทมเพลตอยู่ที่ templates/backlog-template.md และ templates/task-template.md

ถ้า backlog.md มีอยู่แล้ว ให้แก้ต่อ ไม่เขียนทับทิ้ง — เก็บ US-nnn เดิมไว้ที่รหัสเดิม เพิ่มของใหม่ต่อท้ายเลขล่าสุด ปรับ priority ที่กระทบ และทำเครื่องหมาย (ยกเลิก) พร้อมเหตุผลให้ story ที่ตกไปจากการแก้ spec ห้ามนำรหัสเดิมกลับมาใช้ซ้ำ

1. จัดกลุ่มเป็น Epic (EP-nn)

Epic จัดตาม คุณค่าทางธุรกิจหรือ user journey ไม่ใช่ technical layer

• ✅ EP-02 — ลูกค้าสั่งกาแฟล่วงหน้าและรับที่ร้าน
• ❌ EP-02 — พัฒนา backend API (ไม่ส่งมอบคุณค่าเองได้)

2. เขียน User story (US-nnn)

รูปประโยค: ในฐานะ <actor> ฉันต้องการ <ความสามารถ> เพื่อ <คุณค่าที่ได้รับ>

ท่อน "เพื่อ" ต้องเป็นคุณค่าจริง ไม่ใช่ทวนความสามารถเดิม:

• ❌ ...ฉันต้องการเข้าสู่ระบบ เพื่อจะได้เข้าสู่ระบบได้
• ✅ ...ฉันต้องการเข้าสู่ระบบ เพื่อดูประวัติการสั่งและสั่งซ้ำเมนูเดิมได้เร็วขึ้น

ทุก story ต้องระบุ FR/NFR ต้นทาง ที่มันครอบ ถ้าหา FR ต้นทางไม่ได้ = กำลังเพิ่ม scope ใหม่ → แยกไว้ใต้หัวข้อ "ข้อเสนอนอก spec" ให้ผู้ใช้ตัดสิน ห้ามกลืนเข้า backlog เงียบ ๆ

Acceptance criteria (US-nnn-AC-n)

Given/When/Then ทุกข้อ และต้องครอบ 3 กลุ่ม:

AC-1 (happy path)
  Given ลูกค้าเลือกเมนู 1 รายการในตะกร้า
  When กดยืนยันการสั่ง
  Then ระบบสร้างออเดอร์สถานะ "รอยืนยัน" และแสดงหมายเลขออเดอร์

AC-2 (error path)
  Given การชำระเงินถูกปฏิเสธจากผู้ให้บริการ
  When ระบบได้รับผลการชำระเงิน
  Then ออเดอร์ต้องไม่ถูกสร้าง และแสดงข้อความให้ลูกค้าลองวิธีชำระเงินอื่น

AC-3 (boundary / rule)
  Given ตะกร้าว่าง
  When กดยืนยันการสั่ง
  Then ปุ่มยืนยันต้องใช้งานไม่ได้ (ตาม BR-01 สั่งขั้นต่ำ 1 รายการ)

story ที่มี AC ข้อเดียว = ยังคิดไม่รอบ ให้กลับไปคิดกรณีผิดพลาดและขอบเขตค่า

3. ตรวจ INVEST ทุก story

วิธีแตก story ที่ใหญ่เกิน — เลือกแนวที่เหมาะ: ตามขั้นของ workflow · ตามกรณีข้อมูล/business rule · ตาม CRUD · happy path ก่อนแล้วค่อย error case · ตาม interface (mobile ก่อน desktop) · ตามระดับความซับซ้อน (ทำแบบง่ายก่อน แล้วเพิ่มความฉลาด)

❌ ห้ามแตกตาม technical layer (frontend / backend / database) เพราะได้ story ที่ส่งมอบคุณค่าเองไม่ได้

4. จัดลำดับความสำคัญ (MoSCoW)

ทุกข้อต้องมีเหตุผลกำกับสั้น ๆ ถ้าทุก story เป็น Must แปลว่ายังไม่ได้จัดลำดับ ให้กลับไปคิดใหม่ว่าอะไรตัดได้จริง

5. ประเมินขนาด (Story point)

Fibonacci: 1, 2, 3, 5, 8, 13 — เป็นความ ซับซ้อน + ความไม่แน่นอน + ปริมาณงาน ไม่ใช่จำนวนชั่วโมง

ถ้าประเมินไม่ได้เพราะข้อมูลขาด ให้ใส่เป็นช่วง (เช่น 5-8) พร้อมระบุว่าติด Q-nn ข้อไหน — ห้ามใส่เลขมั่วให้ตารางดูครบ

6. กำหนด MVP

MVP = ชุด story ที่เล็กที่สุดที่ผู้ใช้ทำงานหลักได้จบครบหนึ่งรอบ (end-to-end)

ทดสอบด้วยคำถามนี้: ถ้าปล่อยแค่ชุดนี้ ลูกค้าคนหนึ่งเดินเข้ามาแล้วทำงานที่เขาอยากทำจนจบได้ไหม? ถ้าตอบไม่ได้ นั่นไม่ใช่ MVP แต่คือระบบครึ่งใบ

เขียนให้ชัดว่า อะไรอยู่นอก MVP และทำไม

7. Sprint / Release plan

• ระบุความยาว sprint และ velocity ที่สมมติไว้ (ถ้าเป็นทีมใหม่ ให้ประกาศเป็น ASM-nn)
• เรียง sprint ให้ story ที่มี ความเสี่ยงหรือความไม่แน่นอนสูงอยู่ก่อน เพื่อให้รู้ปัญหาเร็ว
• ระบุ dependency ระหว่าง story และ RISK-nn พร้อมแนวทางลดความเสี่ยง
• แตก task ละเอียดแค่ sprint แรก sprint ถัดไปยังไม่ต้องแตก เพราะ requirement จะเปลี่ยน

8. Definition of Ready / Done

ต้องเขียนสองหัวข้อนี้ไว้ในเอกสาร backlog ทุกครั้ง:

Definition of Ready — story เข้า sprint ได้เมื่อ: มี AC ครบทั้ง happy/error/boundary · ประเมินขนาดแล้วและ <13 point · dependency เคลียร์ · ไม่มี Q-nn ค้างที่กระทบ story นี้ · มี design/prototype ถ้าจำเป็น

Definition of Done — story ปิดได้เมื่อ: AC ผ่านทุกข้อ · มี test case ใน [[../../03-testing/01-test-plan/index|01-test-plan]] และรัน pass · ผ่าน code review · เอกสารที่เกี่ยวข้องอัปเดตแล้ว · ไม่มี bug ระดับ major ค้าง

9. Task breakdown (TSK-nnn)

ใช้ templates/task-template.md — task ต้อง:

• เล็กพอที่คนเดียวทำจบได้ใน ไม่เกิน 1 วันทำงาน
• ขึ้นต้นด้วยคำกริยา ("เขียน API สร้างออเดอร์", "ทำหน้าตะกร้าสินค้า")
• ผูกกับ US-nnn ต้นทางทุกอัน
• รวม task ที่คนมักลืม: เขียน test, อัปเดตเอกสาร, migration ข้อมูล, ตั้งค่า deploy/environment

Checklist ก่อนบอกว่าเสร็จ

• ทุก story ผูกกับ FR/NFR ต้นทาง และทุก FR ที่เป็น Must มี story รองรับ
• ทุก story มี AC ครบทั้ง happy path / error path / boundary
• ไม่มี story ≥13 point ที่ยังไม่ถูกแตก
• ไม่มี epic หรือ story ที่จัดตาม technical layer
• priority ทุกข้อมีเหตุผลกำกับ และไม่ได้เป็น Must ทั้งหมด
• MVP ครบ end-to-end และระบุชัดว่าอะไรอยู่นอก MVP พร้อมเหตุผล
• มี Definition of Ready และ Definition of Done ในเอกสาร
• dependency และ RISK-nn ระบุไว้
• frontmatter ครบ + เพิ่มลิงก์ใน 01-requirements/index.md และ 03-task/index.md แล้ว
• backlog อยู่ที่ docs/01-requirements/backlog.md ไฟล์เดียว ไม่มีสำเนาซ้ำที่อื่น
• ถ้าเจอช่องว่างใน spec ระหว่างทำ backlog → รายงานกลับ ไม่ใช่แต่ง requirement เติมเอง
• สรุปงานลง docs/05-log/{YYYYMMDD}-log.md แล้ว (ต่อท้ายถ้ามีไฟล์ของวันนั้น) — ขั้นนี้บังคับ

หลังเขียนเสร็จ

• ให้ agent requirement-reviewer ตรวจก่อนถือว่าใช้ได้
• ทำ RTM ต่อด้วย skill traceability-matrix เพื่อยืนยันว่าไม่มี FR ตกหล่น
• ขั้นถัดไปคือ test plan ใน [[../../03-testing/01-test-plan/index|01-test-plan]] โดยอ้าง AC เป็นฐานของ test case