Story tốt vô nghĩa nếu AC mơ hồ
Một story đạt INVEST nhưng acceptance criteria (AC) chung chung như "hoạt động đúng" sẽ nổ tung ở sprint review: dev bảo xong, QA bảo thiếu, bạn bảo không phải ý này. AC là hợp đồng nhỏ giữa PO, dev và QA. AI giúp bạn sinh AC đầy đủ, phủ cả happy path lẫn ngoại lệ mà bạn hay quên.
Hai định dạng AC nên dùng
- Given/When/Then (Gherkin): hợp cho hành vi có điều kiện, dễ chuyển thành test tự động.
- Rule-based (danh sách quy tắc): hợp cho ràng buộc dữ liệu, validation.
Prompt sinh AC đầy đủ
Bạn là Product Owner + QA. Viết acceptance criteria cho story dưới đây.Yêu cầu:
- Liệt kê AC cho HAPPY PATH theo Given/When/Then.
- Liệt kê AC cho các NGOẠI LỆ / EDGE CASE (mạng lỗi, dữ liệu rỗng,
trùng lặp, vượt giới hạn, thiếu quyền) — càng đầy đủ càng tốt.
- Nêu các RÀNG BUỘC dữ liệu (định dạng, độ dài, bắt buộc/không).
- Đánh dấu AC nào là "phải có để ship" và AC nào "nên có, có thể để sau".
Story: "Là khách hàng, tôi muốn hủy lịch đã đặt để linh hoạt khi bận đột xuất."
Bối cảnh: Có chính sách hủy trước 24h mới được hoàn tiền.
AI sẽ nhắc bạn tình huống "hủy trong vòng 24h", "hủy lịch đã qua giờ", "hủy khi đang xử lý thanh toán" — những case dễ quên.
Một thủ thuật hữu ích: yêu cầu AI viết AC ở "ngôi kiểm thử" — tức mô tả điều QA sẽ bấm và điều họ mong thấy, không mô tả cách hệ thống làm bên trong. Ví dụ thay vì "hệ thống gọi API hoàn tiền", hãy để AC là "khách thấy thông báo đã hoàn tiền và số dư ví tăng đúng số tiền". AC hướng hành vi quan sát được sẽ đúng tinh thần Testable và không khóa cứng giải pháp kỹ thuật (giữ được chữ Negotiable của INVEST).
Nối AC vào Definition of Done
AC nói story này xong khi nào. Definition of Done (DoD) nói mọi story xong khi nào (đã test, đã review code, đã cập nhật tài liệu...). Đừng nhét DoD vào AC. Bạn có thể nhờ AI rà: "AC này có lẫn hạng mục thuộc DoD chung không?".
Các bước làm
- Có story đạt INVEST (từ Bài 2–3).
- Chạy prompt sinh AC, yêu cầu tách happy path / ngoại lệ / ràng buộc.
- Rà lại: AC nào là chính sách nghiệp vụ cần xác nhận với stakeholder?
- Gắn nhãn "phải có" vs "để sau" để tránh story phình lại.
- Đối chiếu với DoD chung, bỏ trùng lặp.
Template AC tái dùng
Happy path
Given ... / When ... / Then ...
Ngoại lệ
- Khi [dữ liệu rỗng] thì ...
- Khi [mạng lỗi] thì ...
- Khi [vượt giới hạn] thì ...
Ràng buộc dữ liệu
- Trường X: bắt buộc, định dạng ..., độ dài ...
Ưu tiên: [Phải có] ... | [Để sau] ...
Sai lầm thường gặp
- Nhận hết edge case AI liệt kê rồi nhét vào một story. Story phình to trở lại. Nhiều edge case nên tách thành story riêng (mẫu happy-path-vs-exception ở Bài 3).
- AI bịa chính sách nghiệp vụ ("hoàn tiền 100%") mà công ty bạn không có. Ảo giác — mọi AC dính chính sách phải được stakeholder xác nhận, không tin AI.
- Dán dữ liệu khách hàng thật vào ví dụ AC. Rò rỉ dữ liệu. Dùng dữ liệu giả.
- Coi AC do AI viết là bản cuối. Đội QA và dev vẫn phải review; AI không biết ràng buộc hệ thống thật của bạn.