Product Backlog & User Story

Dùng khi: backlog đang là bãi rác ý tưởng; story to như dự án; dev hỏi "làm xong thế nào là đạt?" mà không có câu trả lời.

Backlog chuẩn DEEP

• Detailed appropriately — hạng mục sắp làm thì chi tiết, hạng mục xa thì thô. Đừng viết spec cho thứ 6 tháng nữa mới làm.
• Estimated — mọi hạng mục có ước lượng (trên thô, dưới tinh).
• Emergent — backlog tiến hóa theo cái học được, có vào có ra (dám xóa).
• Prioritized — một thứ tự duy nhất từ trên xuống.

Bảo trì bằng refinement định kỳ: xóa story hết thời, thêm story mới, đánh giá lại ưu tiên, ước lượng, tách nhỏ hạng mục sắp vào sprint.

Tách story — luôn tách DỌC (mỗi mảnh vẫn ra giá trị dùng được)

Chiến lược tách: theo bước quy trình / theo thao tác CRUD / theo màn hình / theo scenario đơn giản–phức tạp / theo tiêu chí nghiệm thu / theo dữ liệu / chức năng vs phi chức năng. VD: "Đăng nhập" → màn hình login cơ bản → báo lỗi sai mật khẩu → quên mật khẩu → xác thực email. Mỗi mảnh ship được, học được.

Acceptance Criteria (AC)

• Viết trước khi dev làm, từ góc nhìn người dùng/nghiệp vụ — định nghĩa rõ kết quả, là hợp đồng "thế nào là đạt".
• Cụ thể, kiểm được, phủ logic nghiệp vụ quan trọng; tự động hóa được càng tốt.
• VD story "hiển thị danh sách sản phẩm": có tên + giá + ảnh; sắp theo giá tăng dần; lọc theo danh mục; thêm được vào giỏ; hoạt động trên mobile.

Bẫy thường gặp

• Story kỹ thuật thuần ("dựng API X") không truy được về giá trị người dùng — hợp lệ khi là enabler, nhưng phải nói được nó phục vụ story giá trị nào.
• Tách ngang theo layer (backend riêng, UI riêng) → không mảnh nào dùng được.
• AC viết sau khi code xong — thành biên bản hợp thức hóa thay vì tiêu chí.
• Backlog 300 items không ai dám xóa — backlog dài không phải tài sản, là nợ chú ý.

Nguồn: Module 10 (DEEP, tách story, AC, refinement). Liên quan: Scrum & vai trò PO · Ước lượng & Planning Poker · RICE - ICE - MoSCoW · MVP