Business Analyst (BA)Khuôn mẫu quen thuộc:
> Là một [vai trò], tôi muốn [việc cần làm], để [đạt được giá trị gì].
Ví dụ: Là nhân viên chăm sóc khách hàng, tôi muốn tra đơn hàng bằng số điện thoại, để không phải hỏi khách mã đơn khi họ gọi tới.
Ba phần của một user story theo cách hiểu phổ biến:
- Card — câu mô tả ngắn ở trên, đủ để nhắc nhớ, không phải đặc tả đầy đủ.
- Conversation — phần trao đổi giữa BA, dev, tester để làm rõ. Chi tiết nằm ở đây nhiều hơn ở câu chữ trên thẻ.
- Confirmation — acceptance criteria, tức điều kiện để nói là xong.
Lỗi thường gặp khi viết:
- Vai trò ghi chung chung là "người dùng" cho mọi story, làm mất thông tin ai thật sự cần và vì sao.
- Phần "để" chép lại phần "tôi muốn" bằng từ khác, không nêu được giá trị.
- Viết story theo tầng kỹ thuật ("tạo bảng cơ sở dữ liệu cho đơn hàng") thay vì theo giá trị người dùng nhận được.
- Story quá lớn, không xong nổi trong một sprint — trường hợp này phải tách nhỏ theo luồng nghiệp vụ, không tách theo tầng kỹ thuật.
Lưu ý: user story không thay thế được mọi tài liệu. Quy tắc nghiệp vụ phức tạp, mô hình dữ liệu và yêu cầu phi chức năng vẫn cần chỗ ghi riêng.