Một buổi backlog grooming điển hình: PO mang vào 12 ý tưởng nửa vời từ cuộc họp stakeholder tuần trước, team dev ngồi chờ story được viết ra đủ rõ để estimate, còn BA thì đang cắm đầu gõ user story theo đúng format "As a... I want... So that..." mà trong bụng biết rằng acceptance criteria (tiêu chí chấp nhận) mình viết ra vẫn còn nhiều lỗ hổng. Đây là công việc tốn thời gian nhất nhưng lại dễ bị đánh giá thấp nhất trong vai trò product: viết story không khó, viết story đúng, đủ, và testable (có thể kiểm thử được) mới khó. AI, đặc biệt là các LLM (Large Language Model - mô hình ngôn ngữ lớn) như Claude hay ChatGPT, không viết thay bạn phần tư duy nghiệp vụ, nhưng nó có thể rút ngắn thời gian soạn thảo từ hàng giờ xuống còn vài phút, đồng thời liên tục nhắc bạn những edge case (trường hợp biên) mà con người, khi đang vội, rất dễ bỏ sót.
Bài học này đi từ việc dùng AI để chuyển discovery input (thông tin thô thu thập được từ nghiên cứu người dùng, phỏng vấn stakeholder) thành user story nháp, qua công thức prompt chuẩn để có story đúng cấu trúc Role-Goal-Benefit, đến kỹ thuật khai thác AI sinh edge case và negative path (luồng thất bại), và cuối cùng là quy trình review có hệ thống trước khi story được đưa vào sprint. Đây là kỹ năng nền tảng cho mọi hoạt động requirements engineering (kỹ thuật yêu cầu) phía sau trong module này.
Làm Sao Dùng AI Để Tạo User Story Từ Discovery Input?
Discovery input là tất cả những gì bạn thu thập được trước khi viết story chính thức: ghi chú phỏng vấn khách hàng, bản ghi cuộc gọi sales, feedback từ support ticket, kết quả khảo sát, hay đơn giản là một đoạn brainstorm trên Miro/FigJam sau buổi họp stakeholder. Vấn đề kinh điển là discovery input luôn ở dạng "thô" — lộn xộn, lặp ý, thiếu cấu trúc — trong khi user story cần một hình thức rất chuẩn hóa. AI làm tốt chính xác việc chuyển đổi format này, miễn là bạn cho nó đủ ngữ cảnh nghiệp vụ.
Vì Sao Chất Lượng Input Quyết Định Chất Lượng Story Output
Nguyên tắc "garbage in, garbage out" (đầu vào rác, đầu ra rác) áp dụng chính xác cho AI. Nếu bạn chỉ paste một câu duy nhất "khách hàng muốn xuất báo cáo" vào AI, nó sẽ bịa ra một story có vẻ hợp lý nhưng thiếu domain knowledge (kiến thức nghiệp vụ) thực sự — nó không biết báo cáo đó dùng để làm gì, ai là actor, hệ thống hiện tại có giới hạn gì. Ngược lại, nếu bạn cung cấp đầy đủ: persona của user, bối cảnh sử dụng, các ràng buộc kỹ thuật đã biết, và mục tiêu kinh doanh phía sau yêu cầu, AI sẽ sinh ra story sát với thực tế hơn nhiều.
Một sai lầm phổ biến của PM/BA mới làm quen với AI là kỳ vọng nó "đọc được suy nghĩ" từ một câu ngắn gọn. Thực tế, càng đưa nhiều context thật (không phải giả định), AI càng giảm được tỷ lệ "hallucination nghiệp vụ" — tức là bịa ra chi tiết nghe hợp lý nhưng sai với thực tế sản phẩm của bạn.
Quy Trình 3 Bước Biến Discovery Thành Story Nháp
- Tổng hợp discovery input thô — gom tất cả ghi chú, quote khách hàng, feedback thành một tài liệu duy nhất, không cần format đẹp, chỉ cần đầy đủ.
- Đưa vào AI kèm ngữ cảnh sản phẩm — cung cấp cho AI: persona liên quan, epic mà story này thuộc về, các ràng buộc kỹ thuật đã biết (ví dụ hệ thống hiện chưa hỗ trợ real-time), và mục tiêu kinh doanh (OKR liên quan nếu có).
- Yêu cầu AI xuất ra nhiều candidate story — thay vì một story duy nhất, yêu cầu 2-3 phương án chia nhỏ khác nhau (ví dụ chia theo actor, chia theo luồng chức năng) để bạn chọn cách chia hợp lý nhất, vì AI không biết ưu tiên roadmap của bạn.
Ví Dụ Prompt
Bạn là một Business Analyst giàu kinh nghiệm trong lĩnh vực fintech.
Dưới đây là discovery input thô thu thập từ 5 cuộc phỏng vấn khách hàng
và 12 support ticket liên quan đến tính năng xuất báo cáo giao dịch.
[PASTE GHI CHÚ PHỎNG VẤN + TRÍCH SUPPORT TICKET VÀO ĐÂY]
Bối cảnh sản phẩm:
- Đây là ứng dụng quản lý tài chính cá nhân, user chính là nhân viên
văn phòng 25-40 tuổi, dùng app hàng ngày để theo dõi chi tiêu.
- Epic liên quan: "Báo cáo & Phân tích chi tiêu".
- Ràng buộc kỹ thuật đã biết: hệ thống hiện chưa hỗ trợ export định dạng
Excel, chỉ có PDF và CSV.
Hãy:
1. Xác định tối đa 3 user story riêng biệt có thể rút ra từ discovery
input trên, mỗi story theo đúng format "Là một [role], tôi muốn
[goal], để [benefit]".
2. Với mỗi story, liệt kê 3-5 câu hỏi cần làm rõ thêm với stakeholder
trước khi story đủ điều kiện đưa vào sprint (đánh dấu rõ nếu là câu
hỏi về nghiệp vụ hay câu hỏi về kỹ thuật).
3. Đề xuất thứ tự ưu tiên sơ bộ dựa trên tần suất xuất hiện trong
discovery input.
Trả lời bằng tiếng Việt, giữ nguyên các thuật ngữ kỹ thuật (epic,
story, OKR, v.v.) bằng tiếng Anh.
Mẹo: Đừng dùng AI để "quyết định" story nào quan trọng nhất — nó chỉ nên đề xuất dựa trên tần suất xuất hiện trong data thô. Quyết định ưu tiên cuối cùng luôn cần đối chiếu với roadmap và OKR, những thứ nằm ngoài discovery input mà bạn đưa vào.
Cách Prompt AI Để Có Story Cấu Trúc Chuẩn — Role, Goal, Benefit Và Acceptance Criteria
Một user story tốt không chỉ đúng cú pháp "As a... I want... So that..." mà còn phải truyền tải được giá trị thật sự (benefit) một cách rõ ràng, tránh tình trạng benefit chỉ là diễn giải lại goal bằng từ khác. Đây là lỗi cực kỳ phổ biến mà AI, nếu không được prompt đúng cách, cũng mắc phải y hệt con người.
Công Thức Role-Goal-Benefit Và Bẫy "Benefit Giả"
Cấu trúc chuẩn của một user story gồm ba phần: Role (ai là người thực hiện hành động), Goal (họ muốn làm gì), và Benefit (giá trị họ nhận được nếu goal được đáp ứng). Bẫy phổ biến nhất — kể cả với AI — là viết benefit kiểu vòng tròn: "Là một user, tôi muốn xuất báo cáo, để tôi có thể xuất được báo cáo dưới dạng PDF". Đây không phải benefit thật, chỉ là mô tả lại goal.
Benefit thật phải trả lời được câu hỏi "so what?" — tại sao user cần điều đó? Ví dụ đúng: "Là một kế toán viên doanh nghiệp nhỏ, tôi muốn xuất báo cáo giao dịch theo tháng dưới dạng PDF, để tôi có thể nộp báo cáo thuế đúng hạn mà không cần copy dữ liệu thủ công sang Excel." Benefit ở đây gắn với mục tiêu công việc thật của actor, không phải mô tả lại tính năng.
Given-When-Then Cho Acceptance Criteria
Acceptance criteria nên viết theo cấu trúc Given-When-Then (Bối cảnh - Hành động - Kết quả) để đảm bảo tính testable. Given mô tả trạng thái ban đầu, When mô tả hành động user thực hiện, Then mô tả kết quả mong đợi có thể quan sát và kiểm chứng được. AI rất giỏi sinh ra bộ khung Given-When-Then nếu bạn cung cấp đủ story gốc và một vài ví dụ mẫu.
Các Bước Thực Hành
- Viết goal thô trước — đừng cố hoàn thiện ngay, chỉ ghi lại điều user muốn làm bằng ngôn ngữ tự nhiên.
- Đưa AI phân tích goal thành role-goal-benefit đầy đủ — yêu cầu nó chỉ ra rõ nếu benefit đang bị lặp lại goal.
- Yêu cầu AI sinh acceptance criteria dạng Given-When-Then — tối thiểu 1 happy path (luồng chính) và gợi ý thêm các nhánh phụ.
- Tự tay review lại phần benefit — đây là phần AI dễ sai nhất vì nó không biết mục tiêu kinh doanh thật của bạn, chỉ suy luận từ ngôn ngữ.
Ví Dụ Prompt
Bạn là một Product Owner có kinh nghiệm viết user story cho các đội
Scrum trưởng thành.
Goal thô: "User muốn xuất báo cáo giao dịch theo tháng."
Bối cảnh: actor chính là kế toán viên tại doanh nghiệp nhỏ (SME),
mục tiêu kinh doanh liên quan là giảm thời gian user phải làm báo cáo
thuế thủ công.
Hãy:
1. Viết lại thành user story chuẩn "Là một [role], tôi muốn [goal],
để [benefit]", đảm bảo benefit không lặp lại goal mà phải nêu rõ
giá trị công việc thật của actor.
2. Sinh acceptance criteria theo cấu trúc Given-When-Then, tối thiểu
3 kịch bản: 1 happy path, 1 trường hợp dữ liệu rỗng (không có giao
dịch trong tháng), 1 trường hợp lỗi hệ thống khi tạo file thất bại.
3. Với mỗi acceptance criteria, đánh giá nhanh mức độ testable (Cao/
Trung/Thấp) và giải thích lý do nếu không phải Cao.
Trả lời bằng tiếng Việt, giữ acceptance criteria bằng cấu trúc
Given-When-Then bằng tiếng Anh cho quen thuộc với dev.
Mẹo: Khi AI trả về benefit nghe "đẹp" nhưng mơ hồ kiểu "để cải thiện trải nghiệm người dùng", hãy prompt lại yêu cầu nó cụ thể hóa bằng một hành động hoặc con số đo được (ví dụ "giảm 15 phút làm báo cáo thủ công mỗi tháng"). Benefit mơ hồ là dấu hiệu AI đang "đoán" thay vì dựa trên context bạn cung cấp.
AI Sinh Edge Case, Negative Path Và Boundary Condition Như Thế Nào?
Phần lớn giá trị thực tế của AI trong viết requirements không nằm ở việc viết happy path — cái đó con người vẫn làm tốt. Giá trị nằm ở khả năng liệt kê một cách có hệ thống các edge case (trường hợp biên), negative path (luồng khi hành động thất bại), và boundary condition (điều kiện biên của dữ liệu) mà con người, dưới áp lực deadline, dễ dàng bỏ quên.
Bốn Nhóm Edge Case Kinh Điển Cần AI Quét Qua
- Dữ liệu biên (boundary data): giá trị rỗng, giá trị tối đa/tối thiểu cho phép, ký tự đặc biệt, độ dài chuỗi vượt giới hạn.
- Trạng thái hệ thống bất thường: mất kết nối mạng giữa chừng, timeout khi gọi API bên thứ ba, service phụ thuộc đang downtime.
- Hành vi người dùng không chuẩn: double-click nút submit, back button giữa luồng thanh toán, mở nhiều tab cùng thao tác một giao dịch.
- Xung đột quyền và trạng thái: user bị revoke quyền giữa lúc đang thao tác, dữ liệu bị người khác sửa đồng thời (race condition).
Các Bước Thực Hành
- Đưa story và acceptance criteria happy path đã có vào AI.
- Yêu cầu AI quét theo từng nhóm edge case ở trên, không hỏi chung chung "có edge case nào không" — hỏi chung chung sẽ ra kết quả hời hợt.
- Yêu cầu AI đánh dấu edge case nào cần xác nhận với PO/BA trước khi đưa vào acceptance criteria chính thức (vì không phải edge case nào AI liệt kê cũng đáng để xử lý — một số có thể chấp nhận rủi ro thấp).
- Bổ sung acceptance criteria mới cho các edge case được duyệt.
Ví Dụ Prompt
Đây là user story và acceptance criteria hiện tại (chỉ có happy path):
[PASTE STORY + ACCEPTANCE CRITERIA HIỆN TẠI]
Hãy rà soát và liệt kê các edge case còn thiếu, phân theo 4 nhóm:
1. Dữ liệu biên (rỗng, tối đa, ký tự đặc biệt).
2. Trạng thái hệ thống bất thường (mất mạng, timeout, service phụ
thuộc lỗi).
3. Hành vi người dùng không chuẩn (double-click, back giữa luồng,
thao tác song song trên nhiều tab/thiết bị).
4. Xung đột quyền/trạng thái (mất quyền giữa chừng, dữ liệu bị sửa
đồng thời).
Với mỗi edge case, viết acceptance criteria dạng Given-When-Then, và
đánh giá mức độ cần thiết (Bắt buộc / Nên có / Có thể bỏ qua) kèm lý do
ngắn gọn.
Mẹo: Đừng đưa hết mọi edge case AI liệt kê vào acceptance criteria — điều này khiến story phình to không estimate được. Hãy lọc theo mức độ "Bắt buộc" trước, phần "Nên có" đưa vào backlog kỹ thuật riêng để technical debt (nợ kỹ thuật) được ghi nhận công khai thay vì bị lãng quên.
Review Story Do AI Tạo: Đầy Đủ, Testable, Rõ Ràng Với Kỹ Sư
Bước cuối cùng và quan trọng nhất: không bao giờ đưa story do AI viết thẳng vào sprint mà chưa qua review của con người. AI có thể viết rất "mượt" nhưng lại thiếu độ chính xác nghiệp vụ, hoặc dùng ngôn ngữ mơ hồ mà dev đọc vào sẽ hiểu sai.
Checklist Review 3 Lớp
Một quy trình review hiệu quả nên nhìn qua ba lớp riêng biệt, không gộp chung thành "đọc lại một lượt":
- Lớp đầy đủ (completeness): story có đủ role-goal-benefit, đủ acceptance criteria cho cả happy path lẫn edge case quan trọng chưa?
- Lớp testable (khả năng kiểm thử): mỗi acceptance criteria có kết quả quan sát được, đo được không, hay còn dùng từ mơ hồ như "nhanh", "dễ dùng", "hợp lý"?
- Lớp rõ ràng kỹ thuật (engineering clarity): dev đọc vào có đủ thông tin để estimate không cần hỏi lại nhiều lần không? Có thuật ngữ nghiệp vụ nào dev không hiểu mà chưa được giải thích không?
Các Bước Thực Hành
- Dùng chính AI để tự chấm điểm story theo 3 lớp trên (AI làm "first pass reviewer").
- Đưa story qua một buổi refinement ngắn với dev để xác nhận lớp rõ ràng kỹ thuật — đây là phần AI không thể tự đánh giá vì không biết codebase thực tế của bạn.
- Chốt lại phiên bản cuối và gắn story vào epic tương ứng trong Jira/Linear/Azure DevOps.
Ví Dụ Prompt
Bạn là một reviewer khó tính, chuyên đánh giá chất lượng user story
trước khi đưa vào sprint planning.
[PASTE STORY + ACCEPTANCE CRITERIA HOÀN CHỈNH]
Hãy chấm điểm theo thang 1-5 cho 3 tiêu chí:
1. Đầy đủ (Completeness): đã bao phủ happy path và các edge case quan
trọng chưa?
2. Testable: mỗi acceptance criteria có thể viết thành test case cụ
thể không, hay còn dùng từ mơ hồ (nhanh, dễ dùng, hợp lý, thân
thiện)?
3. Rõ ràng kỹ thuật (Engineering Clarity): dev đọc có đủ thông tin để
estimate mà không cần hỏi lại không?
Với mỗi tiêu chí dưới 4 điểm, chỉ rõ câu/dòng có vấn đề và đề xuất cách
viết lại cụ thể.
Mẹo: Lưu lại prompt review này thành một "AI reviewer chuẩn" dùng chung cho cả team, thay vì mỗi người tự viết prompt riêng. Sự nhất quán trong tiêu chí review qua thời gian quan trọng hơn việc mỗi story được review theo một cách khác nhau.
Những Điểm Chính Cần Nhớ
- Chất lượng discovery input quyết định chất lượng story AI sinh ra — đừng kỳ vọng AI bù đắp cho input thiếu ngữ cảnh.
- Benefit thật phải trả lời "so what?", không được lặp lại goal bằng từ khác — đây là lỗi phổ biến nhất kể cả khi AI viết.
- Given-When-Then là cấu trúc chuẩn giúp acceptance criteria testable ngay từ đầu, không phải chỉnh sửa lại sau.
- AI xuất sắc trong việc quét edge case theo 4 nhóm hệ thống (dữ liệu biên, trạng thái bất thường, hành vi không chuẩn, xung đột quyền), nhưng con người phải quyết định edge case nào thực sự cần xử lý.
- Review 3 lớp (đầy đủ, testable, rõ ràng kỹ thuật) nên là bước bắt buộc trước khi story vào sprint, không phải bước tùy chọn.
Mẹo: Xây một "prompt library" dùng chung cho cả team BA/PO — lưu lại các prompt đã verify hiệu quả cho từng bước (sinh story, sinh acceptance criteria, quét edge case, review) để không ai phải viết lại từ đầu mỗi lần, và chất lượng output giữa các thành viên trong team được đồng đều hơn.