Từ biên bản họp đến user story chuẩn INVEST: quy trình 6 bước với AI
Biên bản họp dài, yêu cầu rải rác, sắp đến buổi refinement? Quy trình 6 bước kèm prompt copy-ready giúp BA/PO biến biên bản thành user story và acceptance criteria, có bước kiểm tra INVEST.
Bạn vừa họp xong với vận hành, kinh doanh và rủi ro. Kết quả là một biên bản dài, đầy câu kiểu "khách hay phàn nàn chỗ này", "bên rủi ro lo vụ kia", "cái này để tính sau". Sáng mai team dev cần story để refinement.
Đọc lại biên bản, tách ý, gom nhóm, rồi viết từng story cùng acceptance criteria (AC) là phần việc tốn nhiều thời gian của BA/PO. AI có thể hỗ trợ khâu tách ý và viết nháp, còn bạn giữ vai trò quyết định và kiểm tra. Bài này là quy trình 6 bước kèm prompt dùng ngay.
User story thực sự là gì (đừng viết thành đặc tả kỹ thuật)
Theo Atlassian, user story là mô tả ngắn, dùng ngôn ngữ đời thường, về kết quả người dùng mong muốn. Nó thường được diễn đạt theo kiểu "persona + nhu cầu + mục đích". Mẫu phổ biến: "As a [user], I want [goal] so that [reason]", tức "Là <vai trò>, tôi muốn <mục tiêu> để <lý do>".
Vài điểm từ tài liệu nên giữ khi làm việc với AI:
Story là mục tiêu, không phải tính năng. Chi tiết yêu cầu được bổ sung sau, khi team đã bàn và đồng thuận.
3C: Card, Conversation, Confirmation. Card là mô tả story, Conversation là các cuộc trao đổi làm rõ, Confirmation là acceptance criteria xác định khi nào xong. Alistair Cockburn từng nói: story là "lời hứa cho một cuộc trò chuyện".
Story nên làm xong trong một sprint. Nếu vượt, team phải tách nhỏ khi bàn spec.
Mệnh đề "so that" là tuỳ chọn theo Mike Cohn, nhưng thường rất có ích. Với BA, đây là chỗ buộc yêu cầu phải gắn với giá trị.
Story thường do product owner, product manager hoặc program manager viết rồi đưa team review. Bản AI sinh ra chỉ là bản nháp trong quy trình đó.
INVEST: thêm một lớp kiểm tra
Trong phần tài liệu tham khảo của bài này, INVEST không được nhắc đến. Đây là checklist phổ biến mà mình bổ sung (Nhận định):
| Chữ | Ý nghĩa | Câu hỏi tự kiểm |
|---|---|---|
| Independent | Độc lập | Làm story này có bắt buộc chờ story khác không? |
| Negotiable | Thương lượng được | Có lỡ ghi cứng cách làm không? |
| Valuable | Có giá trị | "So that" có nói rõ lợi ích không? |
| Estimable | Ước lượng được | Team có đủ thông tin để cho điểm không? |
| Small | Đủ nhỏ | Xong trong một sprint không? |
| Testable | Kiểm thử được | AC có đo được không? |
Chữ S và T khớp với hai điều tài liệu nhấn mạnh: kích thước vừa một sprint và AC để xác nhận hoàn thành.
Quy trình 6 bước
Làm sạch biên bản. Xoá tên khách hàng, số tài khoản, số liệu nội bộ nhạy cảm, thay bằng placeholder (xem phần bảo mật).
Trích xuất người dùng, nhu cầu, ràng buộc, điều chưa chốt, mỗi mục kèm câu trích gốc.
Gom nhóm thành epic (mục tiêu lớn), rồi tách thành story nhỏ.
Viết story theo mẫu "Là… tôi muốn… để…".
Viết AC dạng gạch đầu dòng hoặc Given/When/Then, tuỳ chuẩn team bạn (hai dạng này là lựa chọn thực hành, không nằm trong tài liệu tham khảo).
Tự kiểm INVEST, sau đó mang vào refinement. Ước lượng (t-shirt size, Fibonacci, planning poker) vẫn là việc của team, đừng để AI cho điểm thay.
Prompt mẫu
Prompt 1 – Trích xuất (bước 2–3):
Bạn là Business Analyst giàu kinh nghiệm trong lĩnh vực <lĩnh vực>.
Dưới đây là biên bản họp đã ẩn dữ liệu nhạy cảm.
Nhiệm vụ:
Liệt kê các nhóm người dùng/vai trò được nhắc đến.
Liệt kê từng nhu cầu, kèm câu trích NGUYÊN VĂN từ biên bản.
Liệt kê ràng buộc (quy định, bảo mật, hệ thống).
Liệt kê điểm CHƯA CHỐT hoặc mâu thuẫn giữa các người nói.
Đề xuất gom nhu cầu thành epic.
Không được thêm yêu cầu không có trong biên bản.
Biên bản:
<dán biên bản>
Prompt 2 – Viết story và AC (bước 4–6):
Từ epic "<tên epic>" và danh sách nhu cầu đã duyệt bên dưới, viết user story
theo mẫu: Là <vai trò>, tôi muốn <mục tiêu> để <lợi ích>.
Với mỗi story:
3–5 acceptance criteria, kiểm thử được, không dùng từ mơ hồ
như "nhanh", "thân thiện", "dễ dùng". Nếu cần ngưỡng, ghi <ngưỡng cần xác nhận>.
Ghi nguồn: câu nào trong biên bản.
Tự đánh giá INVEST (đạt/chưa đạt + lý do một dòng).
Nếu story quá lớn cho một sprint, đề xuất cách tách.
Thêm 1 "abuse story" nếu epic liên quan bảo mật hoặc dữ liệu.
Câu hỏi chưa có lời đáp: liệt kê riêng, KHÔNG tự trả lời.
Nhu cầu đã duyệt:
<dán danh sách>
Ví dụ: app ngân hàng
Đầu vào (đã ẩn danh):
> Vận hành: khách hay gọi tổng đài hỏi vì sao chuyển khoản không thành công. Kinh doanh: muốn khách tự xem lý do trong app. Rủi ro: chỉ hiện lý do ở mức khách hiểu, không lộ quy tắc phát hiện gian lận. Chưa chốt: có gửi thông báo đẩy hay không.
Kết quả tốt trông như sau:
Story: Là khách hàng dùng app ngân hàng, tôi muốn xem lý do một giao dịch chuyển khoản thất bại để tôi tự xử lý mà không cần gọi tổng đài.
AC:
Khi chuyển khoản thất bại, khách hàng xem được lý do ngay trong app.
Lý do được diễn đạt ở mức khách hàng hiểu được, theo <tiêu chí cần xác nhận với bên rủi ro và UX>.
Lý do không chứa thông tin về quy tắc phát hiện gian lận.
Abuse story: Là kẻ gian, tôi muốn dựa vào thông báo lỗi để dò ra quy tắc chặn giao dịch (cùng dạng "evil user story" mà Wikipedia nhắc tới).
Câu hỏi mở: Có gửi thông báo đẩy không? Mục này giữ lại cho buổi Conversation, không biến thành story vội.
Lưu ý: mỗi AC trên đều lần được về một câu trong biên bản, kể cả ràng buộc của bên rủi ro. Chỗ nào chưa có ngưỡng rõ (như "mức khách hiểu"), AC để placeholder thay vì tự đoán. Những AC tự nghĩ thêm, ví dụ về trường hợp giao dịch thành công, chỉ nên đưa vào sau khi đã hỏi lại các bên.
Cách kiểm tra output của AI
Thiếu: đối chiếu từng câu trong biên bản với story hoặc câu hỏi mở. Câu nào không thuộc đâu là bị bỏ sót.
Mơ hồ: tìm từ không đo được. AC mà tester không kiểm được thì chưa đạt chữ T.
Mâu thuẫn: giữa các story, hoặc giữa story với ràng buộc (ví dụ story muốn hiện chi tiết nhưng bên rủi ro không cho).
Bịa thêm: AI hay "tốt bụng" thêm yêu cầu như hạn mức, thời gian lưu, hay cả một AC nghe rất hợp lý. Yêu cầu nào không có câu trích gốc thì xoá hoặc chuyển thành câu hỏi.
Kích thước: story mà bạn không tin xong trong một sprint thì tách.
Nhận định: các tài liệu trên không mô tả quy trình dùng AI, nên đây là cách làm do mình đề xuất, chưa có nguồn kiểm chứng. Hãy thử trên một epic nhỏ trước.
Lưu ý bảo mật
Không dán tên khách hàng, CCCD, số tài khoản, số liệu kinh doanh chưa công bố, quy tắc chống gian lận nội bộ vào công cụ AI công cộng.
Thay bằng placeholder: <khách hàng A>, <số tiền>, <tên hệ thống lõi>.
Ưu tiên công cụ công ty đã phê duyệt và kiểm tra chính sách bảo mật thông tin của tổ chức trước.
Biên bản có người ngoài công ty tham dự thì càng cẩn thận.
Checklist trước khi đưa vào Jira
[ ] Biên bản đã ẩn dữ liệu nhạy cảm
[ ] Mỗi story có vai trò, mục tiêu, lợi ích rõ ràng
[ ] Mỗi AC kiểm thử được, không có từ mơ hồ
[ ] Mọi yêu cầu đều có câu trích gốc
[ ] Điểm chưa chốt nằm ở danh sách câu hỏi mở
[ ] Đã rà INVEST, story lớn đã tách
[ ] Đã mang bản nháp ra Conversation với team trước khi chốt
Chốt lại, AI giúp bạn bớt giờ gõ và gom ý, còn việc hiểu vì sao cần làm và hỏi đúng người vẫn là của BA/PO.