Học cách mô tả User Story rõ ràng, tập trung vào người dùng, nhu cầu và giá trị mà chức năng mang lại.
Nội dung chính
1. User Story không chỉ là một câu mô tả chức năng
Một User Story tốt không chỉ nói hệ thống phải làm gì.
Nó cần thể hiện rõ ai là người sử dụng, họ cần điều gì và giá trị nhận được là gì.
Cấu trúc phổ biến:
Là một [đối tượng người dùng],
tôi muốn [nhu cầu],
để [giá trị hoặc lợi ích].
Phiên bản tiếng Anh:
As a [user role],
I want [goal],
so that [business value].
Ba thành phần này giúp Developer, QA, BA và Product Owner cùng hiểu
lý do một chức năng cần được xây dựng.
2. Ba thành phần của User Story
Đối tượng người dùng
Phần đầu xác định ai là người có nhu cầu.
Không phải lúc nào đối tượng cũng là khách hàng cuối.
Đó có thể là:
- Khách hàng.
- Nhân viên vận hành.
- Quản trị viên.
- Nhân viên chăm sóc khách hàng.
- Đối tác tích hợp.
- Hệ thống bên ngoài.
Nhu cầu
Nhu cầu mô tả điều người dùng muốn thực hiện hoặc thông tin họ muốn nhận được.
Nó nên tập trung vào mục tiêu, không nên khóa chặt vào giải pháp kỹ thuật quá sớm.
Giá trị nghiệp vụ
Business Value giải thích vì sao nhu cầu đó quan trọng.
Phần này giúp nhóm hiểu tác động của chức năng đối với người dùng hoặc doanh nghiệp.
3. Ví dụ User Story đầy đủ
Là một chủ thẻ tín dụng,
tôi muốn xem ngày đến hạn thanh toán,
để tôi có thể thanh toán đúng hạn và tránh phí trễ hạn.
Phân tích:
- Người dùng: chủ thẻ tín dụng.
- Nhu cầu: xem ngày đến hạn.
- Giá trị: tránh thanh toán trễ và phát sinh phí.
Nếu chỉ viết “Hiển thị ngày đến hạn”, nhóm vẫn biết phải xây dựng gì,
nhưng chưa hiểu rõ ai cần thông tin và giá trị của chức năng đối với người dùng.
4. Business Value là gì?
Business Value là lợi ích mà một yêu cầu mang lại cho người dùng,
doanh nghiệp hoặc quá trình vận hành.
Giá trị có thể là:
- Tăng doanh thu.
- Giảm chi phí vận hành.
- Giảm rủi ro.
- Tuân thủ quy định.
- Cải thiện trải nghiệm người dùng.
- Giảm thao tác thủ công.
- Tăng độ chính xác dữ liệu.
- Giúp người dùng hoàn thành công việc nhanh hơn.
5. Vì sao QA cần hiểu Business Value?
QA không chỉ xác nhận hệ thống chạy đúng theo câu chữ của yêu cầu.
QA còn cần hiểu chức năng đang bảo vệ giá trị nào.
Hiểu Business Value giúp QA:
- Ưu tiên kiểm thử các luồng quan trọng.
- Xác định rủi ro nếu chức năng thất bại.
- Đặt câu hỏi đúng trọng tâm.
- Thiết kế Test Scenario sát nghiệp vụ.
- Đánh giá mức độ nghiêm trọng của Bug.
- Hiểu vì sao một yêu cầu có Priority cao.
Ví dụ
Nếu chức năng hiển thị ngày đến hạn sai,
đây không chỉ là lỗi giao diện.
Người dùng có thể thanh toán trễ, phát sinh phí và khiếu nại.
Do đó QA cần kiểm tra kỹ dữ liệu, múi giờ, kỳ sao kê và trường hợp ngày nghỉ.
User Story thể hiện nhu cầu và Business Value; QA dựa trên giá trị đó để xác định Acceptance Criteria, câu hỏi kiểm thử, rủi ro và Test Scenario phù hợp.6. Phân biệt nhu cầu với giải pháp kỹ thuật
User Story nên mô tả nhu cầu trước khi mô tả cách triển khai.
Chưa phù hợp
Là Developer, tôi muốn tạo stored procedure để lấy số dư thẻ.
Câu này thiên về giải pháp kỹ thuật.
Nó có thể phù hợp với Technical Task nhưng chưa thể hiện rõ giá trị người dùng.
Phù hợp hơn
Là một chủ thẻ,
tôi muốn xem số dư hiện tại,
để tôi biết khả năng chi tiêu còn lại của mình.
Sau đó nhóm kỹ thuật mới quyết định sử dụng API,
stored procedure hay cách triển khai nào phù hợp.
7. User Story và Technical Task
| Tiêu chí |
User Story |
Technical Task |
| Trọng tâm |
Giá trị cho người dùng hoặc nghiệp vụ |
Công việc kỹ thuật cần thực hiện |
| Ví dụ |
Khách hàng xem lịch sử giao dịch |
Tạo API truy vấn giao dịch |
| Người đọc chính |
Toàn bộ nhóm Agile |
Nhóm kỹ thuật |
| Kiểm thử |
Kiểm thử hành vi và giá trị đầu ra |
Kiểm tra kết quả kỹ thuật hỗ trợ Story |
Một User Story có thể cần nhiều Technical Task để hoàn thành,
nhưng không nên dùng Technical Task thay thế cho nhu cầu nghiệp vụ.
8. Ví dụ trong dự án Credit Card Banking
Xem số tiền thanh toán tối thiểu
Là một chủ thẻ tín dụng,
tôi muốn xem số tiền thanh toán tối thiểu,
để tôi biết số tiền ít nhất phải thanh toán trong kỳ.
Nhận cảnh báo giao dịch
Là một chủ thẻ,
tôi muốn nhận thông báo khi có giao dịch mới,
để tôi có thể nhanh chóng phát hiện giao dịch bất thường.
Khóa thẻ tạm thời
Là một chủ thẻ,
tôi muốn khóa thẻ tạm thời trên ứng dụng,
để ngăn giao dịch khi tôi nghi ngờ thẻ bị thất lạc.
Cập nhật địa chỉ email
Là một khách hàng,
tôi muốn cập nhật địa chỉ email,
để tiếp tục nhận thông báo và sao kê từ ngân hàng.
9. Một User Story tốt phải cụ thể đến mức nào?
User Story không cần chứa toàn bộ chi tiết nghiệp vụ trong một câu.
Các chi tiết có thể được bổ sung trong:
- Description.
- Acceptance Criteria.
- Business Rules.
- Mockup hoặc Prototype.
- Tài liệu API.
- Ví dụ dữ liệu.
- Biên bản thảo luận của nhóm.
Tuy nhiên, User Story phải đủ rõ để nhóm hiểu mục tiêu và tiếp tục thảo luận.
10. Viết Acceptance Criteria hỗ trợ Business Value
User Story
Là một chủ thẻ,
tôi muốn nhận cảnh báo khi có giao dịch mới,
để có thể phát hiện sớm giao dịch bất thường.
Acceptance Criteria minh họa
- Thông báo được gửi sau khi giao dịch được ghi nhận thành công.
- Thông báo hiển thị số tiền, thời gian và đơn vị chấp nhận thẻ.
- Thông tin nhạy cảm của thẻ không được hiển thị đầy đủ.
- Người dùng có thể bật hoặc tắt loại cảnh báo này.
- Nếu gửi thông báo thất bại, hệ thống ghi nhận trạng thái để xử lý.
Những tiêu chí này liên kết trực tiếp với giá trị phát hiện giao dịch bất thường
và bảo vệ thông tin của khách hàng.
11. Những cách viết chưa tốt
Không có đối tượng người dùng
Cho phép xem số dư thẻ.
Không xác định rõ ai sử dụng chức năng.
Không có Business Value
Là khách hàng, tôi muốn xem số dư thẻ.
Câu này có thể hiểu được nhưng chưa giải thích tại sao chức năng quan trọng.
Business Value quá chung chung
Là khách hàng, tôi muốn xem số dư để có trải nghiệm tốt hơn.
“Tốt hơn” khó đo lường và chưa thể hiện lợi ích cụ thể.
User Story chứa nhiều nhu cầu
Là khách hàng, tôi muốn đăng nhập, xem số dư, thanh toán
và cập nhật hồ sơ để quản lý tài khoản.
Story này quá lớn và nên được chia thành nhiều User Story riêng.
Viết theo giao diện thay vì nhu cầu
Là người dùng, tôi muốn có nút màu xanh ở góc phải.
Câu này mô tả giải pháp giao diện nhưng chưa cho biết người dùng muốn đạt mục tiêu gì.
12. QA đánh giá User Story bằng cách nào?
Khi đọc User Story, QA có thể sử dụng checklist:
- Người dùng đã được xác định rõ chưa?
- Nhu cầu có cụ thể không?
- Business Value có hợp lý và rõ ràng không?
- Story có chứa nhiều nhu cầu khác nhau không?
- Story có thể hoàn thành trong một Sprint không?
- Acceptance Criteria có thể kiểm thử không?
- Có Business Rule nào cần bổ sung không?
- Có luồng lỗi hoặc ngoại lệ chưa được đề cập không?
- Có phụ thuộc vào hệ thống khác không?
- Có yêu cầu bảo mật, hiệu năng hoặc tuân thủ không?
13. Từ Business Value đến Test Scenario
User Story
Là một chủ thẻ,
tôi muốn khóa thẻ tạm thời,
để ngăn giao dịch khi thẻ bị thất lạc.
Từ giá trị này, QA có thể nghĩ đến:
- Khóa thẻ thành công.
- Giao dịch mới bị từ chối sau khi khóa.
- Giao dịch đã xử lý trước khi khóa không bị thay đổi.
- Người dùng nhận thông báo xác nhận khóa thẻ.
- Không thể khóa thẻ của tài khoản khác.
- Hệ thống xử lý thế nào nếu dịch vụ khóa thẻ bị lỗi.
- Thẻ có thể được mở khóa lại hay không.
- Nhật ký thao tác phải được lưu để kiểm tra.
Như vậy, Business Value giúp QA mở rộng kiểm thử vượt ra ngoài một thao tác giao diện đơn giản.
14. Bài thực hành
Hãy viết lại các yêu cầu dưới đây thành User Story có đầy đủ
người dùng, nhu cầu và Business Value.
- Hiển thị lịch sử giao dịch.
- Tạo chức năng đổi mật khẩu.
- Thêm chức năng thanh toán thẻ.
- Gửi email khi có giao dịch mới.
- Cho phép người dùng cập nhật số điện thoại.
Với mỗi User Story, hãy bổ sung:
- Ba Acceptance Criteria.
- Một trường hợp lỗi.
- Một rủi ro nghiệp vụ nếu chức năng hoạt động sai.
- Ít nhất ba Test Scenario ban đầu.
15. Ví dụ kết quả bài thực hành
Yêu cầu ban đầu:
Hiển thị lịch sử giao dịch.
User Story được viết lại:
Là một chủ thẻ tín dụng,
tôi muốn xem lịch sử giao dịch,
để có thể kiểm tra các khoản chi tiêu và phát hiện giao dịch bất thường.
Test Scenario ban đầu:
- Hiển thị đúng danh sách giao dịch của chủ thẻ.
- Không hiển thị giao dịch của khách hàng khác.
- Sắp xếp giao dịch theo thời gian.
- Hiển thị đúng số tiền và loại tiền tệ.
- Xử lý khi chưa có giao dịch.
- Xử lý khi dịch vụ truy vấn dữ liệu bị lỗi.