Vấn đề: User story tốn thời gian nhưng lặp đi lặp lại
Mỗi sprint, PO/BA viết hàng chục user story và acceptance criteria. Việc này vừa quan trọng vừa nhàm: cùng một khuôn "As a... I want... so that...", cùng kiểu edge case (empty state, lỗi mạng, phân quyền). Đây là mảnh đất vàng để AI làm hộ phần khung, còn bạn tập trung vào phần cần đầu óc nghiệp vụ.
Chìa khóa: Ép AI theo chuẩn chất lượng của bạn
AI biết công thức user story, nhưng không tự biết chuẩn INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) hay quy ước AC dạng Gherkin (Given/When/Then) của team bạn — trừ khi bạn yêu cầu. Prompt tốt phải nhúng tiêu chuẩn chất lượng vào ràng buộc.
Ví dụ prompt sinh user story chuẩn
[ROLE] Bạn là Product Owner giàu kinh nghiệm viết backlog cho team Agile.
[CONTEXT] Sản phẩm ShopFast — app đi chợ hộ, người dùng là nội trợ 30-50
tuổi ít rành công nghệ. Đang xây tính năng "đặt lại đơn cũ" (reorder).
[TASK] Viết 4 user story cho tính năng reorder, mỗi story kèm 3-5 acceptance
criteria theo Given/When/Then. Bắt buộc phủ các trường hợp: đặt lại thành
công, món trong đơn cũ đã hết hàng, giá đã thay đổi, người dùng chưa đăng nhập.
[FORMAT] Với mỗi story:
Story <n>: <tiêu đề>
Story: As a <role>, I want <goal> so that <benefit>
AC:
- Given ... When ... Then ...
[CONSTRAINTS] Mỗi story phải đạt chuẩn INVEST (đặc biệt: Testable, Small).
Tiếng Việt. Nếu một story quá lớn, hãy TÁCH nhỏ và ghi chú lý do.
Không thêm tính năng ngoài phạm vi reorder.
Ràng buộc "phủ các trường hợp: hết hàng, đổi giá, chưa đăng nhập" là bí quyết — bạn dùng chuyên môn product để chỉ định edge case, AI lo phần diễn đạt.
Quy trình 6 bước
- Chuẩn bị Context Block sản phẩm (từ Bài 2).
- Liệt kê các edge case bạn muốn AI phủ — đây là giá trị nghiệp vụ của bạn.
- Chạy prompt sinh story + AC.
- Rà soát INVEST: story nào quá to? AC nào không test được?
- Yêu cầu AI chỉnh: "Story 2 chưa Testable, viết lại AC đo được cụ thể".
- Copy vào Jira/Azure DevOps, gắn story point (do người quyết định).
Template: Prompt sinh Story + AC
[Context Block sản phẩm]
Viết <N> user story cho tính năng <X>.
Edge case bắt buộc phủ: <liệt kê>.
Mỗi story: định dạng As a/I want/so that + 3-5 AC Given/When/Then.
Chuẩn: INVEST, đặc biệt Testable.
Nếu thiếu thông tin nghiệp vụ, hãy hỏi trước khi viết.
Checklist rà soát story do AI viết
- [ ] Story có mang lại giá trị người dùng rõ ràng không (Valuable)?
- [ ] Có nhỏ đủ để làm trong 1 sprint không (Small)?
- [ ] Mỗi AC có đo/kiểm tra được không (Testable)?
- [ ] Đã phủ hết edge case mình yêu cầu chưa?
- [ ] Có "tính năng lạ" AI tự thêm không (dấu hiệu ảo giác)?
Sai lầm thường gặp
- Nhận nguyên xi, không rà soát. AI hay viết AC nghe hay nhưng không test được ("hệ thống phải nhanh"). Bạn phải ép nó cụ thể ("tải trong < 2 giây").
- AI tự bịa business rule. Nó có thể viết "hoàn tiền trong 24h" trong khi chính sách công ty là 48h — ảo giác kiểu này rất nguy hiểm vì nghe hợp lý. Luôn đối chiếu với tài liệu chính sách.
- Phụ thuộc quá mức khiến kỹ năng mai một. Vẫn phải tự hiểu vì sao một story đạt INVEST, đừng để AI "nghĩ hộ" hoàn toàn — bạn là người chịu trách nhiệm trước dev và stakeholder.
- Không phủ edge case vì lười liệt kê. AI chỉ phủ những gì bạn nhắc; phần bạn quên, nó cũng quên.
Mẹo tăng tốc thực chiến
Sau khi có bộ story đầu tiên, hãy giữ nguyên đoạn hội thoại và tinh chỉnh dần thay vì bắt đầu lại: "Gộp story 1 và 3 vì trùng luồng", "Story 4 tách thành 2 story nhỏ hơn", "Viết thêm AC cho trường hợp mất mạng giữa chừng". Vì AI đã nắm context trong cùng phiên, mỗi lần chỉnh chỉ tốn vài giây. Đây là cách bạn biến AI thành một cộng sự pair-writing thật sự: bạn ra chuyên môn nghiệp vụ, AI lo tốc độ gõ và tính nhất quán định dạng để dán thẳng vào công cụ quản lý backlog.
Ghi nhớ: AI viết khung, bạn giữ chuẩn. Giá trị của PO/BA nằm ở việc BIẾT edge case nào quan trọng và AC nào mới thực sự test được.