Câu trả lời được chấp nhận
User story là mô tả ngắn một nhu cầu từ góc nhìn người dùng, mục đích chính là khởi đầu cho cuộc trao đổi chứ không phải đặc tả đầy đủ. Mẫu quen thuộc: Là [vai trò], tôi muốn [hành động], để [lợi ích]. Phần "để…" quan trọng nhất — nó cho đội biết vì sao, từ đó có thể đề xuất giải pháp tốt hơn.
INVEST — 6 tiêu chí kiểm tra một story
| Chữ | Ý nghĩa | Câu hỏi tự kiểm tra |
|---|---|---|
| I — Independent | Độc lập | Có làm và phát hành riêng được không? |
| N — Negotiable | Thương lượng được | Có đang áp đặt giải pháp chi tiết không? |
| V — Valuable | Có giá trị | Người dùng/khách hàng có thấy lợi ích không? |
| E — Estimable | Ước lượng được | Đội có đủ hiểu để ước lượng không? |
| S — Small | Nhỏ | Có xong trong một sprint không? |
| T — Testable | Kiểm thử được | Có tiêu chí để biết "đạt" không? |
Sửa ví dụ ở câu hỏi — "màn hình quản lý người dùng" là một epic. Tách thành (giả định):
- Là quản trị viên, tôi muốn khoá tài khoản nhân viên đã nghỉ việc, để dữ liệu khách hàng không bị truy cập trái phép.
- Là quản trị viên, tôi muốn tìm nhân viên theo email, để xử lý yêu cầu hỗ trợ nhanh.
Mỗi story kèm tiêu chí chấp nhận cụ thể (ví dụ: tài khoản bị khoá không đăng nhập được, phiên đang mở bị đăng xuất trong vòng X phút).
User story có thay tài liệu không? Không hoàn toàn. Story là "lời hứa sẽ trao đổi". Quy tắc nghiệp vụ phức tạp, ràng buộc pháp lý, yêu cầu phi chức năng (hiệu năng, bảo mật) vẫn cần ghi lại ở nơi phù hợp — có thể đính kèm story hoặc đưa vào Definition of Done.
Nguồn: