Login

Viết user story tốt: mẫu câu, nguyên tắc INVEST và tiêu chí chấp nhận

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Yêu cầu mơ hồ kiểu 'làm chức năng giỏ hàng' là nguồn gốc của vô số cuộc tranh cãi: làm xong rồi mới biết hiểu sai. User story giúp mô tả yêu cầu từ góc nhìn của người dùng, ngắn gọn và dễ trao đổi. Viết tốt user story là một kỹ năng đáng đầu tư.

User story là gì?

User story là mô tả ngắn một nhu cầu từ quan điểm người dùng, tập trung vào giá trị mang lại chứ không vào cách cài đặt. Mẫu câu phổ biến:

Là một [loại người dùng], tôi muốn [làm gì] để [đạt được lợi ích gì].

Ví dụ: 'Là một học viên, tôi muốn lưu bài học vào danh sách yêu thích để tìm lại nhanh vào lần sau.' Phần 'để...' cực kỳ quan trọng vì nó nói lý do, giúp nhóm đề xuất giải pháp tốt hơn.

User story không phải bản đặc tả đầy đủ. Nó là 'lời mời trò chuyện': các chi tiết được làm rõ qua trao đổi giữa Product Owner, lập trình viên và kiểm thử.

Ba chữ C: Card, Conversation, Confirmation

  • Card: tấm thẻ chứa câu mô tả ngắn.
  • Conversation: các cuộc trao đổi để hiểu chi tiết.
  • Confirmation: tiêu chí chấp nhận xác nhận khi nào xong.

Nguyên tắc INVEST

INVEST là danh sách kiểm tra cho một user story tốt:

  1. Independent (độc lập): càng ít phụ thuộc story khác càng dễ sắp xếp.
  2. Negotiable (thương lượng được): chi tiết có thể bàn bạc, không phải hợp đồng cứng.
  3. Valuable (có giá trị): mang lại giá trị rõ cho người dùng hoặc doanh nghiệp.
  4. Estimable (ước lượng được): đủ rõ để nhóm ước lượng công sức.
  5. Small (nhỏ): hoàn thành gọn trong một sprint, tốt nhất vài ngày.
  6. Testable (kiểm thử được): có cách xác minh đã xong chưa.

Tiêu chí chấp nhận (acceptance criteria)

Là danh sách điều kiện để story được coi là hoàn thành. Cách viết rõ ràng nhất là theo mẫu Given-When-Then (Cho trước - Khi - Thì):

Tinh huong: Luu bai hoc vao yeu thich
  Cho truoc: toi da dang nhap va dang xem mot bai hoc
  Khi: toi bam nut 'Luu yeu thich'
  Thi: bai hoc xuat hien trong danh sach yeu thich cua toi
  Va: nut doi sang trang thai 'Da luu'

Tinh huong: Chua dang nhap
  Cho truoc: toi chua dang nhap
  Khi: toi bam nut 'Luu yeu thich'
  Thi: he thong yeu cau toi dang nhap truoc

Chú ý cả tình huống ngoại lệ và lỗi, không chỉ đường đi suôn sẻ. Tiêu chí tốt giúp lập trình viên biết cần làm gì và người kiểm thử biết cần kiểm tra gì.

Cắt nhỏ story quá lớn

Story lớn (thường gọi là epic) cần được chia nhỏ. Thay vì cắt theo tầng kỹ thuật (làm giao diện rồi làm API rồi làm database), hãy cắt theo lát dọc: mỗi story nhỏ vẫn đi xuyên qua mọi tầng và mang lại giá trị dùng được. Ví dụ 'quản lý yêu thích' có thể tách thành: lưu một bài học; xem danh sách; bỏ lưu; sắp xếp danh sách.

Một vài cách cắt: theo bước trong quy trình, theo quy tắc nghiệp vụ, theo loại người dùng, theo mức độ hoàn thiện (làm bản đơn giản trước).

Những lỗi thường gặp

  • Viết như nhiệm vụ kỹ thuật: 'Tạo bảng favorites'. Đây không phải giá trị người dùng.
  • Thiếu phần lý do 'để...'.
  • Tiêu chí mơ hồ như 'chạy nhanh', 'dễ dùng' mà không có thước đo.
  • Story quá lớn, kéo dài qua nhiều sprint.
  • Ghi đặc tả quá chi tiết ngay từ đầu rồi không ai đọc.

Kết luận

User story tốt ngắn gọn, tập trung vào giá trị, nhỏ vừa phải và đi kèm tiêu chí chấp nhận kiểm tra được. Thử viết lại ba mục trong backlog của bạn theo mẫu này và xem nhóm có thảo luận hiệu quả hơn không.

Muốn luyện kỹ năng phân tích yêu cầu cho dự án thật, bạn có thể tham khảo các khóa học tại codebem.com.

author_photo
Nguyễn Đình Cường

0 comment