Mở đầu — vì sao bài này quan trọng
Nếu bạn đã từng dự một buổi họp dự án mà ở đó đội phát triển và phía nghiệp vụ "nói chuyện với nhau bằng hai ngôn ngữ khác nhau", thì bạn hiểu vì sao User Stories ra đời. Một bên nói về tính năng, nút bấm, API; bên kia nói về việc khách hàng cần gì, vì sao họ cần. User Story là cây cầu nối hai bờ đó lại — nó buộc mọi người phải mô tả công việc dưới góc nhìn của người dùng thật, với một lợi ích cụ thể, thay vì một danh sách chức năng khô khan.
Trong kỳ thi ECBA, User Stories và Acceptance Criteria xuất hiện ở nhiều nơi. Chúng là một kỹ thuật (technique) chính thức trong BABOK Guide v3, gắn chặt với Knowledge Area "Requirements Analysis and Design Definition" và đặc biệt quan trọng trong Agile Perspective. Đề thi ECBA hay hỏi bạn phân biệt User Story với requirement truyền thống, nhận diện cấu trúc 3C, hoặc đánh giá một Acceptance Criteria có "tốt" hay không. Quan trọng hơn, khi bạn ra trường làm BA thật, đây là thứ bạn viết mỗi ngày trong các đội Scrum tại Việt Nam — từ ngân hàng số, ví điện tử cho tới các startup F&B. Nắm vững bài này, bạn vừa lấy điểm trong phòng thi, vừa làm được việc ngay từ tuần đầu đi làm.
Lưu ý: bài này tập trung riêng vào cách viết User Story và Acceptance Criteria. Các kỹ thuật liên quan như Use Cases (Bài 22), ưu tiên backlog bằng MoSCoW/Kano (Bài 28), hay vai trò BA trong các nghi thức Agile (Bài 35) sẽ được bàn ở bài riêng. Ở đây ta đào sâu vào chính câu chuyện và tiêu chí chấp nhận.
Khái niệm cốt lõi
User Story là gì
User Story (câu chuyện người dùng) là một mô tả ngắn gọn về một nhu cầu hoặc mong muốn của người dùng, viết bằng ngôn ngữ đời thường, theo góc nhìn của chính người dùng đó. Điểm mấu chốt: User Story không phải là bản đặc tả đầy đủ — nó là một "lời nhắc để trò chuyện". Ron Jeffries, một trong những người phổ biến khái niệm này, gói gọn nó trong mô hình 3C:
- Card (Thẻ): phần văn bản ngắn viết trên thẻ — chính là câu story theo template.
- Conversation (Cuộc trò chuyện): phần giá trị thật nằm ở các cuộc trao đổi giữa BA, dev, tester và stakeholder để làm rõ chi tiết.
- Confirmation (Xác nhận): chính là Acceptance Criteria — cách ta biết story đã hoàn thành đúng.
Template chuẩn
Cấu trúc kinh điển của một User Story gồm ba phần:
As a [vai trò],
I want [hành động/tính năng],
So that [lợi ích/giá trị].
Dịch sang tiếng Việt:
Là một [vai trò người dùng],
Tôi muốn [làm gì / có tính năng gì],
Để mà [đạt được lợi ích gì].
Ví dụ một story hoàn chỉnh cho website thương mại điện tử:
Là một khách hàng quay lại mua hàng,
Tôi muốn lưu thông tin thẻ thanh toán,
Để mà những lần sau tôi thanh toán nhanh hơn mà không phải nhập lại.
Vế "So that" là vế dễ bị bỏ qua nhất nhưng lại quan trọng nhất. Nó trả lời câu hỏi "tại sao", giúp đội phát triển hiểu giá trị thật. Nếu bạn không viết được vế "So that" một cách thuyết phục, rất có thể tính năng đó không đáng làm.
Acceptance Criteria là gì
Acceptance Criteria (tiêu chí chấp nhận, viết tắt 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" và được stakeholder chấp nhận. AC biến một câu story chung chung thành thứ có thể kiểm thử được, cắt bỏ tranh cãi "thế nào là xong".
Có hai cách viết AC phổ biến:
1. Dạng danh sách (Rule-based / checklist) — phù hợp khi điều kiện đơn giản:
- Khách phải đăng nhập mới lưu được thẻ.
- Chỉ lưu 4 số cuối của thẻ, phần còn lại được mã hóa.
- Tối đa lưu 5 thẻ cho mỗi tài khoản.
2. Dạng Given-When-Then (Gherkin) — phù hợp khi có hành vi theo kịch bản, rất được ưa chuộng trong các đội Agile:
Given (Cho rằng) khách đã đăng nhập và đang ở trang thanh toán,
When (Khi) khách nhập thẻ và tick "Lưu thẻ cho lần sau",
Then (Thì) hệ thống lưu thẻ và hiển thị 4 số cuối ở lần thanh toán tiếp theo.
Thước đo chất lượng INVEST
Để biết một User Story có "tốt" hay không, BABOK và cộng đồng Agile dùng bộ tiêu chí INVEST:
- I — Independent (Độc lập): hạn chế phụ thuộc lẫn nhau giữa các story.
- N — Negotiable (Có thể thương lượng): story không cứng nhắc, chi tiết được làm rõ qua trao đổi.
- V — Valuable (Có giá trị): mang lại giá trị rõ ràng cho người dùng hoặc doanh nghiệp.
- E — Estimable (Ước lượng được): đủ rõ để đội ước lượng công sức.
- S — Small (Nhỏ gọn): làm xong gọn trong một sprint.
- T — Testable (Kiểm thử được): có AC để xác nhận hoàn thành.
Tình huống thực tế
Ví dụ 1 — Ví điện tử MoMo Việt: tính năng "chia hóa đơn"
Giả định một đội sản phẩm của ví điện tử tại TP.HCM muốn thêm tính năng chia tiền sau bữa ăn nhóm. Ban đầu, tài liệu yêu cầu được viết kiểu truyền thống: "Hệ thống phải cho phép người dùng chia một khoản tiền cho nhiều người dùng khác." Câu này nghe có vẻ rõ, nhưng đội dev hỏi ngay: chia đều hay chia theo số tiền riêng? Người được chia có cần dùng ví không? Nếu họ không trả thì sao?
BA viết lại thành User Story:
Là một người vừa trả tiền cho cả nhóm ăn lẩu,
Tôi muốn gửi yêu cầu thu tiền tới từng người trong nhóm,
Để mà tôi không phải tự nhắc và tự theo dõi ai đã trả.
Kèm Acceptance Criteria dạng Given-When-Then:
Given người dùng đã chọn 4 người bạn từ danh bạ,
When người dùng nhập tổng 800.000đ và chọn "chia đều",
Then mỗi người nhận yêu cầu thu 200.000đ và người tạo thấy trạng thái "Chờ thanh toán" cho từng người.
Bài học: Cùng một nhu cầu, nhưng story buộc ta nêu rõ vai trò (người trả trước), giá trị (khỏi tự theo dõi), còn AC với con số 800.000đ chia 4 làm rõ logic "chia đều" mà câu yêu cầu gốc bỏ lửng. Tranh cãi được dập tắt ngay từ khi viết, trước khi tốn một dòng code.
Ví dụ 2 — Tiki/Shopee: tách story quá lớn (Epic) thành story nhỏ
Một đội tại sàn thương mại điện tử nhận yêu cầu: "Là người bán, tôi muốn quản lý kho hàng để không bị bán quá số lượng tồn." Đây thực chất là một Epic — quá lớn, vi phạm chữ S (Small) trong INVEST, không thể làm xong trong một sprint. BA tách nó ra:
Story 1: Là người bán, tôi muốn nhập số lượng tồn cho mỗi sản phẩm, để hệ thống biết tôi còn bao nhiêu hàng.Story 2: Là người bán, tôi muốn hệ thống tự trừ tồn khi có đơn mới, để con số tồn luôn chính xác.
Story 3: Là người bán, tôi muốn nhận cảnh báo khi tồn dưới 5 sản phẩm, để tôi kịp nhập thêm.
Bài học: Mỗi story con vẫn độc lập, có giá trị riêng, ước lượng được và đủ nhỏ. Đây là kỹ thuật "story splitting" mà BA phải làm thường xuyên. Một Epic không sai — nó chỉ chưa sẵn sàng đưa vào sprint cho tới khi được chẻ nhỏ.
Ví dụ 3 — Startup giao đồ ăn ở Hà Nội: AC ngăn lỗi "ngầm hiểu"
Một startup giao đồ ăn viết story: "Là khách, tôi muốn theo dõi đơn hàng để biết khi nào tài xế tới." Đội dev làm xong, hiển thị trạng thái "Đang giao". Nhưng khi demo, Product Owner phản đối: khách muốn thấy vị trí tài xế trên bản đồ theo thời gian thực, không phải một dòng chữ tĩnh. Hai bên đã "ngầm hiểu" khác nhau.
Sau sự cố, BA bổ sung AC rõ ràng cho mọi story tracking:
- Hiển thị vị trí tài xế dạng chấm di chuyển trên bản đồ, cập nhật tối đa mỗi 10 giây.
- Hiển thị thời gian dự kiến giao tới (ETA) tính bằng phút.
- Khi tài xế cách điểm giao dưới 300m, gửi thông báo đẩy cho khách.
Bài học: Story nói "cái gì" và "tại sao", nhưng AC mới khóa chặt "hoàn thành nghĩa là gì". Thiếu AC, đội đã làm lại một sprint — chi phí thật của việc bỏ qua tiêu chí chấp nhận.
Hướng dẫn từng bước
Khi bạn cần viết một User Story kèm Acceptance Criteria, hãy theo trình tự sau:
- Xác định đúng vai trò (role). Đừng viết "Là một người dùng" — quá chung. Hãy cụ thể: "khách hàng mới", "người bán đã xác thực", "quản trị viên kho". Vai trò càng cụ thể, giá trị càng rõ.
- Mô tả hành động ở mức nhu cầu, không phải giải pháp kỹ thuật. Viết "Tôi muốn tìm sản phẩm theo màu", đừng viết "Tôi muốn một dropdown filter có checkbox màu". Giải pháp để dành cho cuộc trò chuyện sau.
- Viết vế "So that" thật thuyết phục. Tự hỏi: nếu bỏ tính năng này, người dùng mất gì? Câu trả lời chính là giá trị cần ghi.
- Kiểm tra story bằng INVEST. Nếu story quá lớn (vi phạm Small), tách nhỏ. Nếu không nêu được giá trị (Valuable), xem lại có đáng làm không.
- Viết Acceptance Criteria. Chọn dạng checklist cho điều kiện đơn giản, dạng Given-When-Then cho hành vi theo kịch bản. Mỗi AC phải kiểm thử được — đọc xong phải biết cách test ra đúng/sai.
- Bao phủ cả luồng chính lẫn ngoại lệ. Đừng chỉ viết AC cho trường hợp thuận lợi. Hãy thêm: lỗi mạng, dữ liệu rỗng, vượt giới hạn, người dùng chưa đăng nhập.
- Rà soát cùng đội. AC tốt nhất được thống nhất giữa BA, dev và tester. Đây chính là chữ "Conversation" trong mô hình 3C.
Lỗi thường gặp & mẹo
Lỗi 1 — Bỏ vế "So that". Rất nhiều story chỉ có "Là... tôi muốn..." rồi dừng. Không có giá trị, đội không biết ưu tiên ra sao. Mẹo: bắt buộc mọi story phải qua được câu hỏi "để làm gì?".
Lỗi 2 — Viết story như đặc tả kỹ thuật. Story là lời nhắc để trò chuyện, không phải tài liệu 5 trang. Nếu bạn thấy mình viết quá dài, có lẽ bạn đang nhầm story với requirement specification.
Lỗi 3 — AC mơ hồ, không kiểm thử được. "Hệ thống phải nhanh", "giao diện phải thân thiện" — không test được. Hãy lượng hóa: "trang load dưới 2 giây", "thao tác xong trong tối đa 3 bước".
Lỗi 4 — Nhầm Epic với Story. Nếu một "story" không thể làm xong trong một sprint, nó là Epic và cần tách. Đề thi ECBA hay đưa một story to đùng và hỏi vấn đề của nó là gì — đáp án thường là vi phạm chữ S (Small).
Lỗi 5 — Quên luồng ngoại lệ trong AC. Chỉ viết AC cho "happy path". Tester sẽ tìm thấy lỗi ở chỗ bạn bỏ qua.
Mẹo thi ECBA: Nhớ kỹ — User Story là một technique, không phải một requirement type. Cấu trúc là Role–Action–Benefit (As a / I want / So that). Mô hình 3C (Card, Conversation, Confirmation) và bộ INVEST là hai thứ ra đề nhiều nhất. Acceptance Criteria thuộc về chữ "C" thứ ba — Confirmation.
Bài tập thực hành
- Viết lại thành User Story: Cho yêu cầu thô "Hệ thống cần có chức năng đặt lại mật khẩu." Hãy viết thành một User Story đầy đủ ba vế (Role–Action–Benefit) và thêm ít nhất 3 Acceptance Criteria, trong đó có 1 luồng ngoại lệ (ví dụ: nhập sai email).
- Tách Epic: Cho Epic "Là khách hàng của một app gọi xe, tôi muốn quản lý các chuyến đi của mình." Hãy tách thành tối thiểu 3 User Story nhỏ thỏa tiêu chí Small, mỗi story có giá trị độc lập.
- Soi lỗi INVEST: Đánh giá story sau theo INVEST và chỉ ra nó vi phạm chữ nào: "Là người dùng, tôi muốn ứng dụng hoạt động tốt." Viết lại cho đúng.
- Chuyển dạng AC: Lấy 3 AC dạng checklist bạn viết ở bài 1 và chuyển sang dạng Given-When-Then cho ít nhất một trong số đó.
Tóm tắt
User Story là kỹ thuật mô tả nhu cầu theo góc nhìn người dùng, dùng template Là [vai trò], tôi muốn [hành động], để mà [lợi ích]. Giá trị thật của story nằm ở mô hình 3C: tấm thẻ (Card) chỉ là điểm khởi đầu, cuộc trò chuyện (Conversation) làm rõ chi tiết, và Acceptance Criteria chính là phần xác nhận (Confirmation). Một story tốt phải đạt bộ INVEST: độc lập, có thể thương lượng, có giá trị, ước lượng được, nhỏ gọn và kiểm thử được.
Acceptance Criteria biến story từ mong muốn chung chung thành thứ kiểm thử được, viết theo dạng checklist hoặc Given-When-Then, phải bao phủ cả luồng chính lẫn ngoại lệ. Qua ba tình huống thực tế — ví điện tử chia hóa đơn, sàn thương mại điện tử tách Epic, và startup giao đồ ăn bị lỗi "ngầm hiểu" — bạn thấy rõ: story nói "cái gì" và "tại sao", còn AC khóa chặt "hoàn thành nghĩa là gì". Nắm vững hai công cụ này, bạn vừa tự tin trong phòng thi ECBA, vừa sẵn sàng làm việc trong bất kỳ đội Agile nào tại Việt Nam.