9 giờ sáng thứ Hai, buổi refinement backlog. PO đọc to một user story: "Là khách hàng, tôi muốn chuyển tiền cho người thân để họ nhận được tiền nhanh chóng." Cả phòng gật đầu, dev bắt đầu ước lượng story point, và acceptance criteria (tiêu chí chấp nhận) được viết vội ba dòng: "Nhập số tiền, chọn người nhận, bấm xác nhận." Hai tuần sau, tính năng lên staging, QA phát hiện: chuyển 0 đồng vẫn được chấp nhận, chuyển vượt hạn mức ngày không có cảnh báo, và không ai biết nên làm gì khi ngân hàng người nhận bị lỗi timeout giữa chừng giao dịch. Đây không phải câu chuyện hiếm — đó là hậu quả trực tiếp của acceptance criteria hời hợt, thiếu happy path/error path/edge case rõ ràng, và Definition of Done (DoD — định nghĩa hoàn thành) mơ hồ đến mức mỗi thành viên team hiểu một kiểu. AI không viết thay BA quyết định nghiệp vụ, nhưng nó có thể biến một buổi refinement 45 phút vật lộn với ba dòng criteria mơ hồ thành 15 phút review một bộ Given-When-Then đầy đủ, có cấu trúc, đã tính sẵn edge case mà con người dễ bỏ sót vì mệt hoặc vội. Bài này đi sâu vào cách dùng AI để sinh acceptance criteria có thể test được từ business rule, đảm bảo coverage đủ ba loại luồng, tạo checklist DoD đúng ngữ cảnh team, và validate acceptance criteria trước khi dev bắt tay vào code.
Sinh Acceptance Criteria Chính Xác, Có Thể Test Được Từ Business Rule
Acceptance criteria tốt phải thỏa hai điều kiện cùng lúc: chính xác về mặt nghiệp vụ (đúng cái stakeholder muốn) và có thể test được (QA/dev đọc vào biết ngay pass/fail dựa trên điều kiện gì). Vấn đề kinh điển là BA thường viết acceptance criteria theo lối mô tả chung chung — "hệ thống phải xử lý đúng", "form phải validate hợp lệ" — nghe hợp lý nhưng không ai biết chính xác "đúng" và "hợp lệ" nghĩa là gì về mặt số liệu, điều kiện, hay ngưỡng cụ thể.
Business rule (quy tắc nghiệp vụ) là nguồn gốc thật sự của acceptance criteria. Một business rule như "hạn mức chuyển tiền tối đa 500 triệu đồng/ngày với tài khoản chưa xác thực eKYC nâng cao" chứa đầy đủ nguyên liệu để sinh ra nhiều dòng acceptance criteria cụ thể: điều kiện biên (499,999,999 vs 500,000,000 vs 500,000,001), điều kiện phụ thuộc (trạng thái eKYC), và hành vi kỳ vọng khi vượt ngưỡng (từ chối, cảnh báo, hay yêu cầu xác thực bổ sung). Vấn đề là con người khi viết tay thường chỉ nhớ ra 60-70% số trường hợp cần thiết, đặc biệt khi business rule có nhiều điều kiện lồng nhau.
AI phát huy giá trị rõ nhất khi bạn cho nó business rule ở dạng có cấu trúc — không phải một đoạn văn mơ hồ, mà là các điều kiện, ngưỡng, actor liên quan được liệt kê tường minh — rồi yêu cầu nó chuyển hóa thành acceptance criteria theo format Given-When-Then (Gherkin). Given-When-Then là cú pháp chuẩn hóa acceptance criteria thành ba phần: Given (điều kiện tiền đề), When (hành động xảy ra), Then (kết quả kỳ vọng) — giúp cả BA, dev, và QA đọc cùng một ngôn ngữ, không hiểu lệch nhau.
Điều quan trọng cần nhớ: AI không tự "biết" business rule của công ty bạn. Nó chỉ giỏi ở việc lắp ráp business rule bạn cung cấp thành cấu trúc acceptance criteria đầy đủ và nhất quán. Chất lượng output phụ thuộc hoàn toàn vào việc bạn mô tả business rule rõ ràng đến mức nào — input mơ hồ sẽ cho ra acceptance criteria mơ hồ, chỉ là được trình bày đẹp hơn.
Các Bước Thực Hành
- Thu thập toàn bộ business rule liên quan đến tính năng từ nhiều nguồn: tài liệu nghiệp vụ, câu trả lời của stakeholder trong buổi elicitation, hoặc chính sách compliance (ví dụ quy định của Ngân hàng Nhà nước về hạn mức giao dịch).
- Liệt kê business rule dưới dạng bảng có cấu trúc: điều kiện, ngưỡng số liệu cụ thể, actor liên quan, hành vi kỳ vọng — tránh viết dạng văn xuôi tự do khi đưa cho AI.
- Đưa business rule đã cấu trúc vào AI (ChatGPT, Claude, hoặc Copilot Chat tích hợp trong Jira/Confluence), yêu cầu sinh acceptance criteria theo Given-When-Then.
- Đọc lại từng dòng AI sinh ra, đối chiếu với hiểu biết nghiệp vụ thực tế — sửa số liệu, bổ sung actor còn thiếu, loại bỏ criteria không áp dụng cho phạm vi sprint hiện tại.
- Đưa acceptance criteria đã chốt vào Jira story, gắn kèm business rule gốc trong phần mô tả hoặc link tới trang Confluence để dev/QA truy vết ngược khi cần.
- Đánh dấu rõ những dòng criteria nào là "must-have" theo compliance/pháp lý (không thể thương lượng) và dòng nào là "nice-to-have" để team ưu tiên đúng khi sprint bị dồn thời gian.
Ví Dụ Prompt
Bạn là Business Analyst senior chuyên viết acceptance criteria cho hệ
thống fintech. Dưới đây là các business rule của tính năng "Chuyển
tiền trong app ngân hàng":
- Hạn mức chuyển tối đa 500,000,000 VNĐ/ngày với tài khoản đã xác thực
eKYC nâng cao, 20,000,000 VNĐ/ngày với tài khoản chưa xác thực.
- Số tiền chuyển tối thiểu 10,000 VNĐ.
- Người nhận phải có số tài khoản hợp lệ tại ngân hàng được hỗ trợ
(danh sách 42 ngân hàng qua Napas).
- Giao dịch trên 100,000,000 VNĐ yêu cầu xác thực OTP qua SMS, giao
dịch dưới mức này chỉ cần xác thực sinh trắc học (vân tay/Face ID).
- Nếu ngân hàng người nhận phản hồi timeout quá 30 giây, giao dịch
phải được đánh dấu "đang xử lý" và không trừ tiền cho đến khi có
xác nhận thành công.
Hãy sinh acceptance criteria theo format Given-When-Then (Gherkin),
mỗi rule tương ứng ít nhất 1 kịch bản. Với mỗi kịch bản, chỉ rõ:
1. Given (điều kiện tiền đề, gồm trạng thái tài khoản/eKYC).
2. When (hành động cụ thể, có số liệu chính xác, không dùng từ mơ hồ
như "một số tiền lớn").
3. Then (kết quả kỳ vọng, gồm cả thông báo lỗi/thành công hiển thị
cho người dùng nếu có).
4. Đánh dấu kịch bản nào bắt buộc theo compliance (không thể bỏ qua).
Trả lời bằng tiếng Việt, giữ nguyên thuật ngữ kỹ thuật tiếng Anh
(Given-When-Then, eKYC, OTP, timeout).
Đây là 1 business rule duy nhất, hãy khai triển tối đa các trường hợp
acceptance criteria có thể xảy ra xung quanh nó, kể cả những trường
hợp tôi chưa nghĩ tới:
"Nhân viên chỉ được duyệt đơn nghỉ phép của cấp dưới trực tiếp, không
được duyệt đơn của chính mình hoặc của người không thuộc phòng ban
mình quản lý."
Hãy liệt kê acceptance criteria theo Given-When-Then, bao gồm cả các
trường hợp về phân quyền lồng nhau (ví dụ: trưởng phòng kiêm nhiệm 2
phòng ban, nhân viên chuyển phòng ban giữa chừng khi đơn đang chờ
duyệt).
Mẹo: Đừng bao giờ để AI tự chọn ngưỡng số liệu (ví dụ tự đề xuất "hạn mức 200 triệu") khi bạn chưa cung cấp — hãy luôn cung cấp con số thật từ business rule, và nếu AI thấy thiếu, yêu cầu nó liệt kê rõ "cần BA/PO xác nhận thêm con số nào" thay vì để nó tự phỏng đoán một con số nghe hợp lý. Một con số sai do AI tự bịa mà không ai phát hiện có thể lọt vào production và trở thành lỗ hổng nghiệp vụ nghiêm trọng.
Dùng AI Để Đảm Bảo Coverage Đủ Happy Path, Error Path Và Edge Case
Một acceptance criteria chỉ liệt kê happy path (luồng chính, mọi thứ diễn ra suôn sẻ) giống như một bản đồ chỉ vẽ con đường lúc trời đẹp — không nói gì về việc gặp mưa bão. Trong thực tế vận hành, phần lớn ticket production bug không nằm ở happy path (vì đó là phần được test kỹ nhất, cũng là phần dev code cẩn thận nhất), mà nằm ở error path (luồng lỗi — khi có điều kiện bất thường được xử lý có chủ đích) và edge case (trường hợp biên — tình huống hiếm, ở rìa giới hạn logic, thường bị bỏ sót vì không ai nghĩ tới).
Ba loại luồng này cần được phân biệt rõ ràng khi viết acceptance criteria, vì mỗi loại đòi hỏi tư duy khác nhau:
- Happy path: người dùng làm đúng quy trình, dữ liệu hợp lệ, hệ thống hoạt động bình thường. Ví dụ: khách hàng nhập đúng số tiền, đúng số tài khoản, hệ thống chuyển tiền thành công.
- Error path: hệ thống chủ động phát hiện và xử lý tình huống sai — validate input sai định dạng, hết hạn mức, sai OTP. Đây là những lỗi "đã biết trước", cần thông báo rõ ràng cho người dùng.
- Edge case: tình huống nằm ở rìa logic, không hẳn là lỗi người dùng gây ra nhưng dễ bị bỏ sót trong thiết kế — ví dụ chuyển đúng 10,000 VNĐ (ngưỡng tối thiểu), hai giao dịch cùng lúc làm tổng vượt hạn mức ngày dù mỗi giao dịch riêng lẻ hợp lệ, hoặc mất kết nối mạng đúng lúc bấm xác nhận.
Điểm mạnh nhất của AI trong phần này không phải là sinh happy path — cái đó BA nào cũng viết được — mà là vai trò "critical reviewer" giúp rà soát acceptance criteria đã có và chỉ ra những gap (khoảng trống) ở error path và edge case mà con người, do đã quen thuộc với tính năng, vô tình bỏ qua. Đây gọi là hiện tượng "curse of knowledge" (lời nguyền của kiến thức) — khi bạn hiểu quá rõ một tính năng, bạn khó tưởng tượng ra người dùng có thể làm sai theo cách không lường trước.
Một kỹ thuật hiệu quả là yêu cầu AI phân loại rõ ràng từng acceptance criteria đã có vào một trong ba nhóm (happy/error/edge), từ đó lộ ra ngay nhóm nào đang thiếu — ví dụ nếu 8/10 criteria đều là happy path và chỉ có 2 error path, không có edge case nào, đó là tín hiệu rõ ràng cần bổ sung trước khi chuyển sang sprint dev.
Các Bước Thực Hành
- Sau khi đã có bản nháp acceptance criteria (từ bước trước hoặc do team tự viết), đưa toàn bộ vào AI và yêu cầu phân loại từng dòng vào happy path / error path / edge case.
- Xem tỷ lệ phân bổ giữa ba nhóm — nếu happy path chiếm áp đảo, yêu cầu AI liệt kê thêm error path và edge case còn thiếu dựa trên business rule gốc.
- Với mỗi edge case AI đề xuất, tự hỏi: "trường hợp này có thực sự xảy ra trong hệ thống của mình không, hay AI đang suy diễn từ pattern chung của ngành?" — loại bỏ những gợi ý không phù hợp với ngữ cảnh thực tế.
- Ưu tiên hóa edge case theo tần suất xảy ra thực tế và mức độ ảnh hưởng nếu bị bỏ sót — không phải edge case nào AI liệt kê cũng cần đưa vào acceptance criteria chính thức của sprint hiện tại.
- Review cùng dev và QA trong buổi refinement — dev thường nhìn ra edge case kỹ thuật (race condition, timeout) mà BA không nghĩ tới, còn QA nhìn ra edge case từ góc độ test case thực tế đã từng gặp ở hệ thống tương tự.
- Cập nhật acceptance criteria cuối cùng vào Jira, gắn nhãn (label) rõ ràng "happy-path", "error-path", "edge-case" để sau này team dễ audit lại coverage.
Ví Dụ Prompt
Đây là acceptance criteria hiện tại của tính năng "Giỏ hàng e-commerce
- áp dụng mã giảm giá":
[PASTE DANH SÁCH ACCEPTANCE CRITERIA HIỆN CÓ]
Hãy:
1. Phân loại từng dòng vào một trong ba nhóm: Happy Path, Error Path,
Edge Case.
2. Đếm số lượng criteria ở mỗi nhóm, chỉ ra nhóm nào đang thiếu hụt
rõ rệt so với hai nhóm còn lại.
3. Đề xuất bổ sung tối thiểu 5 error path và 5 edge case còn thiếu,
liên quan cụ thể đến nghiệp vụ mã giảm giá (ví dụ: mã hết hạn giữa
lúc đang thanh toán, mã áp dụng đồng thời với chương trình khuyến
mãi khác, mã chỉ áp dụng cho đơn hàng đầu tiên nhưng khách đã có
đơn hàng bị hủy trước đó).
4. Trình bày theo format Given-When-Then, đánh dấu rõ nhóm phân loại
ở đầu mỗi dòng.
Trả lời bằng tiếng Việt, giữ thuật ngữ tiếng Anh (happy path, error
path, edge case).
Bạn là QA Lead có kinh nghiệm review acceptance criteria trước khi
dev bắt đầu code. Tính năng: "Đăng ký tài khoản mới" cho app ngân
hàng số, có xác thực OTP qua SMS và xác thực eKYC bằng ảnh CMND/CCCD.
Business rule liên quan:
[PASTE BUSINESS RULE]
Acceptance criteria hiện tại chỉ có:
[PASTE ACCEPTANCE CRITERIA HIỆN CÓ - CHỈ CÓ HAPPY PATH]
Hãy đóng vai "kẻ phá hoại" (adversarial reviewer): liệt kê tối đa 15
cách người dùng hoặc hệ thống có thể khiến luồng đăng ký thất bại
hoặc rơi vào trạng thái bất thường mà acceptance criteria hiện tại
CHƯA đề cập. Với mỗi trường hợp, viết thành 1 dòng Given-When-Then
hoàn chỉnh.
Mẹo: Dùng đúng cụm "đóng vai kẻ phá hoại" (adversarial reviewer) trong prompt thay vì chỉ hỏi "còn thiếu gì không" — cách đặt vai trò này khiến AI chủ động tìm cách "phá" luồng nghiệp vụ thay vì chỉ liệt kê thêm vài dòng an toàn, cho ra kết quả edge case sâu và bất ngờ hơn nhiều so với prompt hỏi chung chung.
Sinh Checklist Definition of Done Phù Hợp Với Ngữ Cảnh Team Và Dự Án
Definition of Done (DoD) là bộ tiêu chí chung, áp dụng cho MỌI story trong team — khác với acceptance criteria vốn riêng cho từng story. DoD trả lời câu hỏi "story này được coi là 'xong' khi nào, bất kể nội dung cụ thể là gì" — ví dụ: code đã được review bởi ít nhất 1 người khác, unit test coverage đạt ngưỡng tối thiểu, tài liệu API đã cập nhật, đã deploy thành công lên môi trường staging.
Sai lầm phổ biến nhất là copy-paste một DoD mẫu tìm được trên mạng hoặc từ team khác mà không điều chỉnh theo ngữ cảnh thực tế của team mình. Một DoD chuẩn cho team backend xử lý giao dịch tài chính (cần security review, cần kiểm tra audit log) sẽ khác hoàn toàn một DoD cho team làm landing page marketing (cần kiểm tra SEO, tốc độ load, responsive trên nhiều thiết bị). Áp dụng DoD sai ngữ cảnh khiến team hoặc làm thừa việc không cần thiết (tốn thời gian), hoặc bỏ sót bước quan trọng (rủi ro chất lượng).
AI hữu ích nhất ở đây khi đóng vai trò tổng hợp nhiều yếu tố ngữ cảnh cùng lúc — loại dự án (fintech, e-commerce, nội bộ HRM), tech stack, quy định compliance áp dụng, quy mô team, và mức độ trưởng thành về automation — rồi sinh ra một checklist DoD vừa đủ chi tiết vừa thực tế để team có thể tuân thủ hàng ngày, không phải một danh sách lý tưởng hóa 40 mục mà không ai làm hết.
Một điều cần lưu ý: DoD không nên là danh sách tĩnh viết một lần rồi để mãi mãi. Khi team trưởng thành hơn (có CI/CD tự động, có test automation coverage cao hơn), DoD nên được nâng cấp theo. AI có thể giúp bạn review định kỳ DoD hiện tại có còn phù hợp với năng lực thực tế của team hay không, hay đang quá lỏng lẻo (không đủ đảm bảo chất lượng) hoặc quá cứng nhắc (team không bao giờ đáp ứng nổi, dẫn đến bỏ qua DoD một cách âm thầm).
Các Bước Thực Hành
- Liệt kê ngữ cảnh dự án cụ thể: loại sản phẩm, ngành (fintech/e-commerce/HRM nội bộ), tech stack, quy định compliance bắt buộc (PCI-DSS, GDPR, quy định ngân hàng nhà nước), quy mô team, công cụ CI/CD đang dùng.
- Đưa toàn bộ ngữ cảnh này vào AI, yêu cầu sinh checklist DoD theo từng nhóm: Code, Test, Documentation, Security/Compliance, Deployment.
- Rà soát checklist AI sinh ra cùng Tech Lead và QA Lead — loại bỏ mục không khả thi với năng lực hiện tại của team (ví dụ yêu cầu 100% test coverage khi team chưa có automation framework ổn định).
- Phân loại rõ mục nào là "bắt buộc" (blocking — không đạt thì không được coi là Done) và mục nào là "khuyến nghị" (nên có nhưng không chặn release trong tình huống gấp).
- Đưa DoD đã chốt vào trang Confluence chung của team, gắn link trong Definition of Ready/DoD field của Jira board nếu công cụ hỗ trợ.
- Review lại DoD mỗi quý hoặc mỗi khi có thay đổi lớn về quy trình (ví dụ mới triển khai CI/CD tự động), dùng AI để so sánh DoD cũ và đề xuất nâng cấp.
Ví Dụ Prompt
Bạn là Agile Coach có kinh nghiệm xây dựng Definition of Done cho các
team sản phẩm. Đây là ngữ cảnh team của tôi:
- Dự án: tính năng duyệt đơn nghỉ phép trong hệ thống HRM nội bộ,
dùng cho công ty 500 nhân viên.
- Tech stack: backend Node.js/NestJS, frontend React, database
PostgreSQL, deploy qua CI/CD trên GitLab.
- Team: 4 dev, 1 QA, 1 BA, chưa có automation test coverage cao (mới
đạt khoảng 40% unit test coverage).
- Không có yêu cầu compliance đặc biệt (không xử lý dữ liệu tài
chính/y tế nhạy cảm), nhưng có yêu cầu nội bộ về audit log (ai
duyệt đơn, khi nào, có thể tra cứu lại).
Hãy sinh checklist Definition of Done, chia theo 5 nhóm: Code, Test,
Documentation, Security/Compliance, Deployment. Với mỗi mục, đánh dấu
rõ "Bắt buộc" hoặc "Khuyến nghị", và giải thích ngắn gọn vì sao mục
đó phù hợp với ngữ cảnh team này (không copy DoD generic từ nguồn
khác).
Trả lời bằng tiếng Việt, giữ thuật ngữ kỹ thuật tiếng Anh (DoD, CI/CD,
unit test, coverage).
Đây là Definition of Done hiện tại team tôi đang dùng (áp dụng 8
tháng nay, chưa update):
[PASTE DOD HIỆN TẠI]
Ngữ cảnh đã thay đổi: team vừa triển khai CI/CD tự động chạy full
regression suite trước khi merge, và mới bổ sung 1 Security Engineer
part-time hỗ trợ review.
Hãy đánh giá DoD hiện tại còn phù hợp không, đề xuất:
1. Mục nào nên siết chặt hơn (do năng lực team đã tăng).
2. Mục nào đang thừa/lặp (do CI/CD đã tự động hóa, không cần checklist
thủ công nữa).
3. Mục mới nên thêm liên quan đến vai trò Security Engineer mới có.
Mẹo: Luôn tách DoD thành 2 tầng rõ ràng — "Bắt buộc" (blocking) và "Khuyến nghị" — ngay từ prompt đầu tiên, đừng để AI trả về một danh sách phẳng 20 mục không phân cấp. Một DoD không phân tầng dễ khiến team hoặc làm qua loa hết (vì tưởng mục nào cũng như nhau) hoặc tranh cãi kéo dài mỗi lần release về việc mục nào thực sự "chặn" được release.
Validate Tính Đầy Đủ Của Acceptance Criteria Trước Khi Dev Bắt Đầu
Buổi refinement/backlog grooming kết thúc, story được estimate và đưa vào sprint — nhưng đó không nên là điểm dừng cuối cùng của việc kiểm tra acceptance criteria. Chi phí sửa một acceptance criteria thiếu sót tăng theo cấp số nhân qua từng giai đoạn: sửa lúc refinement tốn 5 phút thảo luận, sửa lúc dev đang code tốn nửa ngày refactor, sửa lúc QA phát hiện ở giai đoạn test tốn cả ngày quay lại giữa BA-dev-QA, còn sửa sau khi đã release tốn uy tín và có thể tốn tiền thật (như case chuyển tiền 0 đồng ở đầu bài).
INVEST là bộ tiêu chí kinh điển để đánh giá chất lượng một user story, viết tắt của Independent (độc lập), Negotiable (có thể thương lượng), Valuable (có giá trị), Estimable (ước lượng được), Small (đủ nhỏ), Testable (có thể test được). Trong bối cảnh validate acceptance criteria, hai tiêu chí quan trọng nhất là Estimable và Testable — vì nếu acceptance criteria mơ hồ, dev không thể estimate chính xác, và QA không thể viết test case rõ ràng.
Việc validate nên diễn ra trước khi sprint bắt đầu, tốt nhất là ngay trong buổi backlog refinement, dưới dạng một bước rà soát có cấu trúc — không phải chỉ "đọc lướt rồi gật đầu". AI có thể đóng vai một "reviewer độc lập", chấm điểm acceptance criteria theo các tiêu chí cụ thể (đầy đủ happy/error/edge, có số liệu rõ ràng, không có thuật ngữ mơ hồ như "nhanh", "hợp lý", "đúng cách") trước khi story được coi là Ready for Development.
Một kỹ thuật thực dụng là dùng AI để mô phỏng góc nhìn của cả ba vai trò cùng lúc — dev sẽ hỏi gì, QA sẽ hỏi gì, và stakeholder nghiệp vụ sẽ hỏi gì — trước khi story thực sự được đưa vào buổi refinement chính thức. Điều này giúp BA tự "đỡ đòn" trước, giảm số lần bị hỏi ngược lại giữa buổi họp khiến session kéo dài không cần thiết.
Các Bước Thực Hành
- Trước buổi refinement, đưa acceptance criteria nháp vào AI cùng bộ tiêu chí INVEST (đặc biệt nhấn Estimable, Testable), yêu cầu chấm điểm và chỉ ra điểm yếu.
- Yêu cầu AI mô phỏng câu hỏi mà dev, QA, và stakeholder nghiệp vụ có thể đặt ra khi đọc acceptance criteria này — chuẩn bị câu trả lời trước.
- Kiểm tra acceptance criteria có chứa từ ngữ mơ hồ không ("nhanh", "hợp lý", "phù hợp", "đúng cách") — yêu cầu AI liệt kê và đề xuất thay bằng số liệu/điều kiện cụ thể.
- Đối chiếu acceptance criteria với DoD chung của team — đảm bảo không có mâu thuẫn (ví dụ acceptance criteria yêu cầu điều mà DoD team không đủ năng lực kiểm chứng).
- Trong buổi refinement, dùng kết quả validate của AI làm điểm khởi đầu thảo luận, không phải kết luận cuối cùng — luôn để dev và QA phản biện trực tiếp.
- Chỉ chuyển story sang trạng thái "Ready for Development" trên Jira sau khi acceptance criteria đã qua bước validate này, không chuyển trạng thái chỉ vì đã hết giờ họp.
Ví Dụ Prompt
Bạn là reviewer độc lập, đánh giá acceptance criteria theo tiêu chí
INVEST (đặc biệt tập trung Estimable và Testable). Đây là user story
và acceptance criteria:
[PASTE USER STORY + ACCEPTANCE CRITERIA]
Hãy:
1. Chấm điểm 1-5 cho từng tiêu chí INVEST, giải thích ngắn gọn lý do.
2. Liệt kê các từ/cụm từ mơ hồ xuất hiện trong acceptance criteria
(ví dụ: "nhanh chóng", "hợp lý", "dễ sử dụng", "đúng cách") và đề
xuất thay bằng tiêu chí đo lường được (số liệu, ngưỡng cụ thể,
điều kiện rõ ràng).
3. Đánh giá xem acceptance criteria đã "Testable" chưa - QA có thể
viết test case pass/fail rõ ràng từ mỗi dòng không? Chỉ ra dòng
nào KHÔNG testable và vì sao.
4. Kết luận: story này đã sẵn sàng chuyển "Ready for Development"
chưa, nếu chưa thì cần bổ sung gì trước.
Trả lời bằng tiếng Việt, giữ thuật ngữ tiếng Anh (INVEST, Estimable,
Testable, Ready for Development).
Đóng vai lần lượt 3 người sau khi đọc acceptance criteria này của
tính năng "Chuyển tiền trong app ngân hàng":
[PASTE ACCEPTANCE CRITERIA]
1. Một Senior Dev - sẽ hỏi gì để làm rõ trước khi bắt tay code (về
logic tính toán, dữ liệu đầu vào, tích hợp hệ thống khác)?
2. Một QA Engineer - sẽ hỏi gì để biết cách viết test case, đặc biệt
những điều kiện chưa rõ ràng để phân biệt pass/fail?
3. Một Product Owner đại diện nghiệp vụ - sẽ hỏi gì để đảm bảo đúng
ý định kinh doanh ban đầu, không bị hiểu sai khi triển khai?
Với mỗi câu hỏi, đề xuất luôn câu trả lời hợp lý dựa trên business
rule đã cho (nếu có đủ thông tin), hoặc đánh dấu "cần BA xác nhận
thêm" nếu thông tin chưa đủ.
Mẹo: Lưu lại kết quả validate của AI (điểm INVEST, danh sách câu hỏi mô phỏng) vào comment của Jira story trước buổi refinement, đừng chỉ dùng nó trong đầu rồi bỏ qua. Khi dev hoặc QA đặt đúng câu hỏi AI đã dự đoán trước, bạn trả lời ngay lập tức thay vì phải "để anh check lại" — điều này rút ngắn đáng kể thời gian buổi refinement và xây dựng uy tín của BA trong mắt cả team.
Những Điểm Chính Cần Nhớ
- Acceptance criteria tốt bắt nguồn từ business rule được cấu trúc rõ ràng (điều kiện, ngưỡng số liệu, actor) — AI chỉ lắp ráp tốt khi input đã rõ ràng, input mơ hồ cho ra output mơ hồ dù trình bày đẹp.
- Given-When-Then (Gherkin) là ngôn ngữ chung giúp BA, dev, QA hiểu acceptance criteria giống nhau — luôn yêu cầu AI trình bày theo format này để tránh hiểu lệch.
- Happy path dễ viết, nhưng phần lớn bug production nằm ở error path và edge case — dùng AI với vai trò "kẻ phá hoại" (adversarial reviewer) để chủ động tìm gap thay vì chỉ hỏi chung chung "còn thiếu gì không".
- Definition of Done phải được thiết kế riêng theo ngữ cảnh team và dự án (ngành, tech stack, compliance, năng lực automation) — không copy DoD generic, và luôn phân tầng rõ "Bắt buộc" và "Khuyến nghị".
- Validate acceptance criteria theo tiêu chí INVEST (đặc biệt Estimable và Testable) trước khi story chuyển "Ready for Development" — chi phí sửa lỗi acceptance criteria tăng theo cấp số nhân nếu phát hiện càng muộn trong vòng đời sprint.
- AI luôn cần con người xác nhận cuối cùng: số liệu nghiệp vụ thật, quyết định phạm vi sprint, và trách nhiệm với chất lượng acceptance criteria vẫn thuộc về BA/PO/PM, không phải AI.