Mở đầu — vì sao bài này quan trọng
Nếu bạn đã đọc qua các bài trước về Product Backlog (Bài 11) và Product Backlog Refinement (Bài 12), bạn sẽ nhận ra một điều: bản thân Scrum Guide 2020 không hề bắt buộc Product Owner phải viết Product Backlog Item dưới dạng User Story. Scrum Guide chỉ nói rằng các Product Backlog Item nên có mô tả, thứ tự, kích thước (size) và Definition of Done. Vậy tại sao chúng ta lại dành nguyên một bài cho User Story?
Lý do rất thực tế. User Story là kỹ thuật mô tả backlog item phổ biến nhất mà bạn sẽ gặp ngoài thực tế ngành — từ một startup gọi xe ở TP.HCM cho đến một ngân hàng số ở Singapore. Trong kỳ thi PSPO I, bạn sẽ không bị hỏi "cú pháp User Story là gì", nhưng bạn sẽ gặp những câu đánh vào tư duy đằng sau nó: ai chịu trách nhiệm về nội dung backlog item, Acceptance Criteria khác Definition of Done ra sao, và làm thế nào để một item đủ rõ ràng để Developers bắt tay vào làm mà không hiểu sai.
Đây chính là điểm mấu chốt. User Story không phải là một biểu mẫu để điền cho đẹp. Nó là lời nhắc cho một cuộc trò chuyện giữa Product Owner và Developers. Khi bạn hiểu sai bản chất này, bạn sẽ biến nó thành một bản đặc tả yêu cầu cứng nhắc (requirement document) — đúng thứ mà Scrum cố gắng tránh. Bài này sẽ giúp bạn nắm chắc cú pháp, hiểu INVEST, viết được Acceptance Criteria chuẩn, và quan trọng nhất là phân biệt rõ Acceptance Criteria với Definition of Done — một câu hỏi kinh điển trong đề thi.
Khái niệm cốt lõi
User Story là gì — và không phải là gì
User Story là một cách diễn đạt ngắn gọn một nhu cầu của người dùng, viết từ góc nhìn của người sử dụng sản phẩm. Ron Jeffries đã tóm tắt bản chất của nó bằng mô hình 3C:
- Card (Tấm thẻ): phần mô tả ngắn — chính là câu User Story viết trên thẻ. Nó cố tình ngắn để không chứa hết mọi chi tiết.
- Conversation (Cuộc trò chuyện): phần quan trọng nhất. Tấm thẻ chỉ là lời hứa về một cuộc đối thoại sẽ diễn ra giữa PO và Developers để làm rõ chi tiết.
- Confirmation (Xác nhận): chính là Acceptance Criteria — điều kiện để biết khi nào story được coi là làm đúng.
Cú pháp chuẩn
Mẫu phổ biến nhất (do Mike Cohn phổ biến hóa) như sau:
Là một [persona — vai trò/loại người dùng],
Tôi muốn [năng lực/hành động],
Để [lợi ích/giá trị nhận được].
Tiếng Anh:
As a [persona],
I want [capability],
So that [benefit].
Ví dụ cụ thể cho một ứng dụng học trực tuyến:
> *Là một học viên đang đi làm, > Tôi muốn tải bài giảng về xem offline, > Để tôi có thể học trên xe bus mà không tốn data và không lo mất sóng.*
Lưu ý ba thành phần và vai trò của chúng:
- Persona: không viết "Là một người dùng" chung chung. Hãy cụ thể — "học viên đi làm", "quản trị viên khóa học", "khách vãng lai chưa đăng ký". Persona khác nhau dẫn đến nhu cầu khác nhau.
- Capability: mô tả cái họ muốn làm, không phải cách bạn sẽ code. Đây là "what", không phải "how".
- Benefit (mệnh đề "Để…"): phần bị bỏ quên nhiều nhất nhưng lại có giá trị nhất. Nó nói lên lý do — và chính lý do này giúp PO ra quyết định ordering, giúp Developers đề xuất giải pháp tốt hơn, và đôi khi giúp cả team nhận ra story này… không đáng làm.
INVEST — sáu tiêu chí của một story tốt
Bill Wake đề xuất bộ tiêu chí INVEST để đánh giá chất lượng một User Story:
- I — Independent (Độc lập): story nên độc lập với nhau nhất có thể, để PO tự do sắp xếp thứ tự và team không bị kẹt vì phụ thuộc chéo. Trong thực tế không phải lúc nào cũng tách được hoàn toàn, nhưng đây là mục tiêu hướng tới.
- N — Negotiable (Có thể thương lượng): story không phải hợp đồng. Chi tiết được làm rõ qua Conversation, và phạm vi có thể điều chỉnh giữa PO và Developers.
- V — Valuable (Có giá trị): mỗi story phải mang lại giá trị cho người dùng hoặc khách hàng. Nếu bạn không viết nổi mệnh đề "Để…", hãy nghi ngờ story đó.
- E — Estimable (Ước lượng được): Developers phải đủ hiểu để ước lượng. Nếu không ước lượng được, thường là do thiếu thông tin hoặc story quá lớn/mơ hồ.
- S — Small (Đủ nhỏ): story nên đủ nhỏ để hoàn thành trong một Sprint — lý tưởng là vài ngày. Story quá lớn (epic) cần được chia nhỏ qua Refinement.
- T — Testable (Kiểm thử được): phải có cách xác nhận story đã xong. Đây chính là cầu nối tới Acceptance Criteria.
Acceptance Criteria — điều kiện nghiệm thu
Acceptance Criteria (AC) là tập hợp các điều kiện mà một User Story phải thỏa mãn để được coi là hoàn thành đúng ý người dùng. Đây là phần "Confirmation" trong mô hình 3C. AC trả lời câu hỏi: "Làm sao biết story này đã làm đúng?"
Có hai phong cách viết AC phổ biến:
1. Dạng danh sách (Rule-oriented / checklist):
> Story: Học viên đặt lại mật khẩu. > - Học viên nhập email đã đăng ký thì nhận được link đặt lại trong vòng 2 phút. > - Link hết hạn sau 30 phút. > - Mật khẩu mới tối thiểu 8 ký tự, có ít nhất 1 số. > - Email không tồn tại trong hệ thống vẫn hiển thị thông báo trung lập (không tiết lộ email có tồn tại hay không).
2. Dạng Gherkin (Given–When–Then) — kịch bản hành vi:
> Given học viên đang ở trang đăng nhập > When học viên nhấn "Quên mật khẩu" và nhập email đã đăng ký > Then hệ thống gửi email chứa link đặt lại trong vòng 2 phút.
Dạng Gherkin đặc biệt hữu ích vì nó mô tả hành vi theo ngữ cảnh, dễ chuyển thành test tự động, và buộc bạn nghĩ tới cả các trường hợp ngoại lệ (email sai, link hết hạn…).
Phân biệt Acceptance Criteria với Definition of Done — câu hỏi kinh điển PSPO I
Đây là chỗ rất nhiều người nhầm, và đề thi PSPO I rất thích đánh vào. Hãy nắm thật chắc:
| Acceptance Criteria | Definition of Done | |
|---|---|---|
| Phạm vi | Riêng cho một Product Backlog Item | Áp dụng cho mọi Increment / mọi item |
| Nội dung | Hành vi cụ thể mà người dùng kỳ vọng | Tiêu chuẩn chất lượng chung (đã test, đã review code, đã đạt chuẩn bảo mật, đã deploy…) |
| Ai định nghĩa | Thường do PO làm rõ cùng Developers | Do Scrum Team (chủ yếu Developers) cam kết |
| Thay đổi | Khác nhau theo từng story | Ổn định, dùng chung cho tất cả |
Tình huống thực tế
Tình huống 1 — Tiki và cái bẫy "story là bản đặc tả"
Hãy hình dung một team tại một sàn thương mại điện tử lớn như Tiki. PO mới vào nghề, vốn xuất thân từ vai trò Business Analyst, viết backlog item như sau:
> "Xây dựng tính năng tìm kiếm: có thanh search ở header, gọi API Elasticsearch, hỗ trợ gợi ý auto-complete, filter theo 7 tiêu chí, sắp xếp theo 4 cách, phân trang 24 item/trang, cache kết quả 5 phút…"
Item này dài hai trang, mô tả cả giải pháp kỹ thuật (Elasticsearch, cache) lẫn UI. Khi mang vào Sprint Planning, Developers ước lượng không nổi — quá lớn — và cảm thấy mình chỉ là người "code theo bản vẽ", không được đóng góp ý kiến.
PO được Scrum Master kèm cặp, viết lại thành nhiều story nhỏ theo góc nhìn người dùng:
> Là một khách mua hàng, tôi muốn gõ tên sản phẩm và thấy gợi ý ngay khi đang gõ, để tôi tìm nhanh mà không cần nhớ chính xác tên.
Phần "gọi Elasticsearch", "cache 5 phút" được chuyển vào cuộc trò chuyện và để Developers quyết định cách triển khai — vì đó là "how", thuộc thẩm quyền của họ. AC thì tập trung vào hành vi: "Khi gõ tối thiểu 2 ký tự, gợi ý hiển thị trong vòng 300ms; chọn một gợi ý thì nhảy thẳng tới trang sản phẩm."
Bài học: User Story mô tả cái người dùng cần (what & why), không phải cách team xây dựng (how). Khi PO ôm luôn cả phần "how", bạn vừa lấn sân Developers vừa làm story phình to, mất tính Estimable và Small của INVEST.
Tình huống 2 — Startup giao đồ ăn ở Jakarta và sức mạnh của mệnh đề "Để…"
Một startup giao đồ ăn ở Jakarta (gọi là FoodGo cho dễ hình dung) có story trong backlog:
> Là một tài xế, tôi muốn có nút "Đã giao hàng" lớn trên màn hình.
Story này thiếu mệnh đề "Để…". Trong buổi Refinement, Scrum Master hỏi: "Để làm gì?" Tài xế — qua phản hồi thực địa — cho biết: "Để tôi bấm xác nhận nhanh ngay cả khi đang đội mưa, đeo găng tay, một tay cầm túi đồ ăn."
Khoảnh khắc đó thay đổi mọi thứ. Vấn đề thật không phải là "nút to hơn", mà là thao tác một tay trong điều kiện khắc nghiệt. Developers đề xuất giải pháp tốt hơn: cho phép vuốt (swipe) để xác nhận, kèm phản hồi rung, hoạt động được cả khi màn hình ướt. Họ đo lường: thời gian xác nhận giao hàng giảm từ trung bình 8 giây xuống 3 giây, và số ca bấm nhầm "hủy đơn" giảm 40%.
Bài học: Mệnh đề "Để…" tiết lộ vấn đề thật đằng sau yêu cầu bề mặt. Nếu PO chỉ viết "cái họ muốn" mà bỏ "tại sao", team dễ giải quyết sai vấn đề. Đây cũng là nền tảng của tư duy Outcome over Output mà bạn sẽ học sâu ở Bài 31.
Tình huống 3 — Ngân hàng số và Acceptance Criteria cứu một bàn thua
Một team tại một ngân hàng số ở Việt Nam làm tính năng chuyển khoản. PO viết story rõ ràng:
> Là một khách hàng, tôi muốn chuyển tiền tới số tài khoản của người khác, để thanh toán cho bạn bè.
Developers làm xong "happy path": nhập số tài khoản, nhập số tiền, bấm chuyển, thành công. Demo ở Sprint Review trông ổn. Nhưng vì AC chỉ có một dòng — "chuyển tiền thành công" — nên không ai nghĩ tới các trường hợp biên.
Sprint sau, một stakeholder từ bộ phận rủi ro chỉ ra: chuyện gì xảy ra nếu số dư không đủ? Nếu nhập số tiền vượt hạn mức ngày? Nếu mạng rớt giữa chừng — tiền có bị trừ hai lần không? Team phải làm lại, tốn thêm gần một Sprint.
Lần sau, PO viết AC theo Gherkin, bao phủ cả ngoại lệ:
> - Given số dư 500.000đ When chuyển 600.000đ Then hiển thị "Số dư không đủ" và không trừ tiền. > - Given đã chuyển 95 triệu trong ngày (hạn mức 100 triệu) When chuyển 10 triệu Then chặn và báo vượt hạn mức. > - Given giao dịch đang xử lý When mất kết nối Then đảm bảo idempotency — tiền không bị trừ hai lần.
Bài học: Acceptance Criteria không chỉ mô tả happy path. AC tốt buộc cả team nghĩ tới ngoại lệ trước khi code, rẻ hơn rất nhiều so với phát hiện sau khi giao. AC chính là chữ "T — Testable" của INVEST được cụ thể hóa.
Hướng dẫn từng bước
Đây là quy trình thực dụng để viết một User Story kèm Acceptance Criteria chất lượng:
- Xác định persona thật. Đừng viết "người dùng". Hỏi: ai cụ thể cần điều này? "Học viên đi làm", "tài xế giao hàng", "khách hàng VIP". Persona càng rõ, story càng đúng nhu cầu.
- Viết câu story theo cú pháp Là/Tôi muốn/Để. Bắt buộc có đủ ba phần. Nếu bí ở mệnh đề "Để…", đó là dấu hiệu bạn chưa hiểu rõ giá trị — quay lại trao đổi với stakeholder hoặc user.
- Kiểm tra qua bộ lọc INVEST. Đọc lại story và tự hỏi sáu câu: Có độc lập không? Có thương lượng được không? Có giá trị không? Ước lượng được không? Đủ nhỏ không? Kiểm thử được không? Nếu vướng ở "Small" hay "Estimable", hãy chia nhỏ story.
- Viết Acceptance Criteria cùng Developers, không viết một mình. AC là sản phẩm của cuộc trò chuyện. Bắt đầu từ happy path, rồi lần lượt hỏi "còn trường hợp nào khác?" để phủ ngoại lệ. Dùng checklist hay Gherkin tùy ngữ cảnh.
- Tách bạch AC khỏi DoD. Khi viết AC, đừng nhồi các tiêu chuẩn chất lượng chung (đã test, đã review, đã deploy) vào — những thứ đó thuộc Definition of Done của team rồi. AC chỉ tập trung vào hành vi đặc thù của story này.
- Để story "đủ tốt", không "hoàn hảo". Mục tiêu của Refinement là làm story đủ rõ để Developers tự tin đưa vào Sprint, không phải đặc tả tới từng pixel. Phần còn lại sẽ được làm rõ trong Sprint qua trao đổi tiếp tục.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến story thành bản đặc tả kỹ thuật. PO viết luôn cách triển khai ("dùng Redis", "gọi API X"). Điều này lấn sân Developers và làm mất tính Negotiable. Mẹo: giữ story ở mức "what & why", để "how" cho Developers.
Lỗi 2 — Bỏ mệnh đề "Để…". Mất luôn lý do, dẫn tới giải quyết sai vấn đề. Mẹo: coi mệnh đề "Để…" là bắt buộc; nếu không viết được, đừng đưa story vào Sprint.
Lỗi 3 — Nhầm Acceptance Criteria với Definition of Done. Đây là bẫy thi PSPO I. Mẹo: AC = riêng từng item, mô tả hành vi; DoD = chung mọi item, mô tả chuẩn chất lượng. Story "Done" khi thỏa cả hai.
Lỗi 4 — AC chỉ có happy path. Bỏ sót ngoại lệ, gây làm lại tốn kém. Mẹo: với mỗi story, hỏi tối thiểu ba câu "chuyện gì xảy ra nếu… (sai, rỗng, vượt hạn mức, mất mạng)".
Lỗi 5 — Tưởng Scrum bắt buộc dùng User Story. Mẹo nhớ cho kỳ thi: Scrum Guide không quy định format backlog item. User Story chỉ là một kỹ thuật phổ biến, không phải luật Scrum. Đề thi có thể hỏi xoáy điều này.
Lỗi 6 — Story quá lớn (epic) bị nhồi vào một Sprint. Mẹo: khi không ước lượng được hoặc thấy "to quá", hãy chia nhỏ theo bước hành trình người dùng, theo loại dữ liệu, hoặc theo từng quy tắc nghiệp vụ.
Mẹo vàng: Hãy nhớ "Card chỉ là lời nhắc cho một cuộc trò chuyện". Đo lường chất lượng PO không phải bằng độ dài story, mà bằng việc story đó có giúp team xây đúng thứ người dùng cần hay không.
Bài tập thực hành
Bài 1 — Viết story đủ ba phần. Chọn một tính năng bạn thật sự dùng hằng ngày (ví dụ: lọc tin nhắn chưa đọc trong Zalo). Viết một User Story đầy đủ theo cú pháp Là/Tôi muốn/Để, với persona cụ thể.
Bài 2 — Soi qua INVEST. Lấy story bạn vừa viết, chấm điểm từng tiêu chí INVEST từ 1–5. Tiêu chí nào yếu nhất? Viết lại để cải thiện nó.
Bài 3 — Viết Acceptance Criteria có ngoại lệ. Cho story: "Là một học viên, tôi muốn nộp bài tập có đính kèm file, để giảng viên chấm điểm." Viết tối thiểu 5 dòng AC theo dạng Given–When–Then, trong đó ít nhất 2 dòng xử lý ngoại lệ (file quá lớn, sai định dạng, nộp sau hạn).
Bài 4 — Phân biệt AC và DoD. Cho danh sách sau, hãy xếp mỗi mục vào AC hay DoD: (a) "Hiển thị thông báo lỗi khi email sai định dạng"; (b) "Code đã được review bởi ít nhất 1 người"; (c) "Đã viết unit test với coverage ≥ 80%"; (d) "Người dùng nhận được email xác nhận sau khi đăng ký". (Gợi ý: a và d là AC; b và c là DoD.)
Bài 5 — Câu hỏi tư duy kiểu PSPO I. Đúng hay Sai: "Scrum Guide yêu cầu mọi Product Backlog Item phải được viết dưới dạng User Story." Giải thích câu trả lời của bạn bằng một câu.
Tóm tắt
User Story là kỹ thuật mô tả backlog item phổ biến nhất, nhưng không bắt buộc trong Scrum — hãy ghi nhớ điều này cho kỳ thi. Bản chất của nó nằm ở mô hình 3C: Card (tấm thẻ ngắn), Conversation (cuộc trò chuyện làm rõ chi tiết), và Confirmation (Acceptance Criteria). Cú pháp "Là một [persona], tôi muốn [năng lực], để [lợi ích]" giúp tập trung vào what và why, để dành how cho Developers.
Bộ tiêu chí INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) là thước đo chất lượng story. Mệnh đề "Để…" tiết lộ vấn đề thật và là chìa khóa cho ordering lẫn tư duy outcome. Acceptance Criteria mô tả hành vi kỳ vọng riêng cho từng story, phải phủ cả happy path lẫn ngoại lệ — và phải được phân biệt rõ với Definition of Done, vốn là chuẩn chất lượng chung cho mọi Increment. Một story chỉ thực sự "Done" khi thỏa mãn cả AC của riêng nó lẫn DoD của team.
Cuối cùng, đừng quên: PO giỏi không viết story dài nhất, mà viết story khơi mào được cuộc trò chuyện đúng để team xây đúng thứ người dùng cần.