Mục tiêu
Đây là bước "chốt đơn": biến một pain point đã được xác thực thành một backlog item đủ chuẩn để team hiểu và ước lượng — gồm user story, tiêu chí chấp nhận (acceptance criteria), và quan trọng nhất là bằng chứng gắn kèm để không ai chất vấn được "tại sao làm cái này".
Cấu trúc một backlog item tốt
- User story: "Là <vai trò>, tôi muốn <mục tiêu> để <giá trị>."
- Bối cảnh/vấn đề: pain point gốc + số liệu tần suất.
- Bằng chứng: 2–3 trích dẫn nguyên văn kèm ID phản hồi.
- Acceptance criteria: điều kiện để coi là "xong", viết dạng Given/When/Then.
- Epic cha (nếu thuộc nhóm lớn hơn).
Story vs Epic
- Nếu pain point giải được trong một vài sprint bằng một luồng công việc → user story.
- Nếu nó là một mảng lớn (nhiều story con, nhiều màn hình) → epic, rồi tách thành story.
Ví dụ cụ thể
Từ PP1 ("Bị trừ tiền nhưng đơn không tạo", 12 mẩu, Blocker), AI dựng:
> Story: Là khách hàng đã thanh toán, tôi muốn được đảm bảo đơn của mình được tạo hoặc được hoàn tiền tự động, để tôi không mất tiền oan. > > AC: Given tôi thanh toán thành công, When hệ thống tạo đơn thất bại, Then trong 5 phút tôi nhận thông báo và được hoàn tiền tự động. > > Bằng chứng: 12 phản hồi (F042: "trừ tiền mà không thấy đơn"; F057: "mất 200k, gọi tổng đài không ai nghe").
Prompt sinh story từ pain point
Bạn là trợ lý viết backlog cho Product Owner theo chuẩn Agile.
Dưới đây là 1 pain point kèm bằng chứng (ID + trích dẫn).
Hãy tạo backlog item gồm:
1. User story: "Là <vai trò>, tôi muốn <mục tiêu> để <giá trị>."
2. Bối cảnh vấn đề (2-3 câu) kèm số liệu tần suất.
3. 3-5 Acceptance Criteria dạng Given/When/Then.
4. Mục "Bằng chứng": liệt kê ID + trích dẫn nguyên văn (chỉ dùng cái có sẵn).
5. Gợi ý đây nên là STORY hay EPIC, và nếu là epic thì liệt kê 2-4 story con.
RÀNG BUỘC:
- KHÔNG thêm bằng chứng ngoài dữ liệu đưa vào.
- KHÔNG đề xuất giải pháp kỹ thuật chi tiết; tập trung vào NHU CẦU và KẾT QUẢ MONG MUỐN.
Pain point:
<dán pain point + ID + trích dẫn>
Các bước triển khai
- Lấy bảng pain point đã ưu tiên từ Bài 4.
- Chạy prompt sinh story cho từng pain point severity cao trước.
- Rà soát story: đúng vai trò? giá trị rõ? AC kiểm chứng được?
- Đảm bảo mục Bằng chứng khớp đúng ID trong dataset gốc.
- Quyết định story hay epic; nếu epic, giữ danh sách story con.
- Dán vào công cụ backlog (Jira/Trello/Notion), giữ nguyên phần bằng chứng.
Template — Backlog item chuẩn
Tiêu đề: [<Epic>] <Tên story>
User story: Là ..., tôi muốn ... để ...
Vấn đề & số liệu: <mô tả> (<n> phản hồi, severity <mức>)
Acceptance Criteria:
- Given ... When ... Then ...
Bằng chứng: F0xx "...", F0yy "..."
Ưu tiên đề xuất: <cao/trung/thấp>
Sai lầm thường gặp
- Bằng chứng bịa (ảo giác): AI có thể tự thêm một trích dẫn "cho thuyết phục". Chỉ chấp nhận ID có trong dataset; xóa mọi trích dẫn không truy được.
- Story hóa giải pháp thay vì nhu cầu: nếu để AI viết "thêm nút X ở màn hình Y", bạn đã khóa giải pháp quá sớm. Story nên mô tả nhu cầu, để team tự tìm giải pháp tốt nhất.
- AC không kiểm chứng được: "App phải nhanh hơn" là AC tồi. Yêu cầu điều kiện đo được.
- Phụ thuộc quá mức, bỏ khớp bằng chứng: đừng dán thẳng output AI vào Jira mà chưa đối chiếu ID gốc — đó là lúc bằng chứng giả lọt vào backlog và phá vỡ uy tín của bạn.
Kết bài
Bạn đã có backlog item chuẩn, gắn bằng chứng. Nhưng backlog luôn nhiều hơn năng lực làm. Bài 6 sẽ dùng AI hỗ trợ ưu tiên một cách minh bạch, có thể bảo vệ trước stakeholder.