| name | user-story-ac-writer |
| description | Sinh User Story và Acceptance Criteria chuẩn INVEST + Given-When-Then
cho BA/PO. Skill enforce 6 tiêu chí INVEST (Independent, Negotiable,
Valuable, Estimable, Small, Testable) và format AC theo Gherkin syntax.
Hỗ trợ 3 mode: viết mới từ feature description, refine US đang có,
bổ sung AC cho US đã viết.
Dùng khi user nói: "viết user story", "viết US", "tạo user story",
"viết AC", "viết acceptance criteria", "tạo AC cho story",
"user story chuẩn INVEST", "AC theo Given-When-Then", "AC Gherkin",
"refine user story", "review US này", "US này đã chuẩn chưa",
"bổ sung AC", "viết tiêu chí nghiệm thu", "story cho feature này",
"split user story", "story quá to cần tách", kể cả khi paste
feature description + nói "viết story đi" hoặc upload PRD +
"tạo US list".
KHÔNG dùng cho: viết PRD/URD/SRS toàn bộ (dùng prd-writer, srs-writer),
viết test case kỹ thuật chi tiết (AC ≠ test case), viết Use Case
formal (dùng po-usecase-refiner), business rules (dùng
business-rule-generator).
|
| author | Phúc NT @ BA Zone |
| source | https://github.com/ba-zone |
User Story & Acceptance Criteria Writer
by Phúc NT — BA Zone & Digital School
Mục đích
Skill này giúp BA/PO viết User Story và Acceptance Criteria đạt chuẩn
chất lượng cao, sẵn sàng cho dev estimate và QA viết test case.
Được phát triển bởi Phúc NT trong khuôn khổ chương trình đào tạo
Digital School của BA Zone — cộng đồng BA/PO Việt Nam.
Workflow chuẩn
Bước 1: Xác định mode
Hỏi user 1 trong 3 mode:
- Mode A - Viết mới: User cung cấp feature description, skill sinh
US + AC từ đầu
- Mode B - Refine: User có US/AC sẵn, skill review và đề xuất sửa
- Mode C - Bổ sung AC: User có US, cần thêm AC chi tiết
Nếu user paste content rõ ràng, tự suy luận mode và xác nhận lại 1 lần.
Bước 2: Thu thập input bắt buộc
Cần đủ 4 thông tin trước khi sinh, hỏi nếu thiếu:
- Persona/User type: Ai sẽ dùng tính năng? (Học viên, Mentor, Admin, Doanh nghiệp...)
- Goal: User muốn làm gì?
- Business value: Tại sao cần tính năng này?
- Context/Scope: Tính năng nằm trong feature/module nào?
KHÔNG được tự bịa nếu user không cung cấp - phải hỏi.
Bước 3: Sinh User Story theo template
Dùng format chuẩn 3 thành phần:
**US-[ID]**: [Tiêu đề ngắn gọn]
**As a** [persona cụ thể, không generic như "user"]
**I want to** [hành động cụ thể, đo lường được]
**So that** [business value rõ ràng, không lặp lại I want]
Bước 4: Apply checklist INVEST
Trước khi xuất, tự kiểm tra US theo 6 tiêu chí:
| Tiêu chí | Câu hỏi kiểm tra | Nếu fail thì làm gì |
|---|
| Independent | Story có phụ thuộc story khác không? | Tách dependency hoặc gộp |
| Negotiable | Có để chỗ cho thảo luận không? | Bỏ chi tiết kỹ thuật cứng |
| Valuable | Mang lại giá trị gì cho user/business? | Viết lại phần "So that" |
| Estimable | Dev có ước lượng được effort không? | Bổ sung context/constraint |
| Small | Hoàn thành trong 1 sprint không? | Split thành nhiều story |
| Testable | QA viết được test case không? | Bổ sung AC cụ thể |
Tham khảo chi tiết: references/invest-criteria.md
Bước 5: Sinh Acceptance Criteria
Mỗi US cần tối thiểu 3 AC, format Given-When-Then:
**AC1: [Tên scenario - happy path]**
- **Given** [tiền điều kiện cụ thể]
- **When** [hành động user thực hiện]
- **Then** [kết quả mong đợi đo lường được]
- **And** [kết quả phụ nếu có]
**AC2: [Tên scenario - edge case/validation]**
...
**AC3: [Tên scenario - error/negative path]**
...
Quy tắc viết AC tốt:
- Bao quát đủ 3 loại: happy path, edge case, negative path
- Mỗi điều kiện trong Given/When/Then phải đo lường được (số liệu,
trạng thái rõ ràng)
- Tránh từ mơ hồ: "nhanh", "hợp lý", "user-friendly"
- Không viết logic implementation (đó là việc của dev)
- 1 AC = 1 scenario duy nhất, không gộp nhiều case
Bước 6: Output cuối cùng
Trình bày theo format:
- User Story (3 dòng As a / I want / So that)
- INVEST Self-check (bảng đánh giá 6 tiêu chí với ✅/⚠️)
- Acceptance Criteria (đánh số AC1, AC2, AC3...)
- Notes (nếu có dependency, assumption, hoặc câu hỏi cần PO làm rõ)
- Yêu cầu xem lại toàn bộ tài liệu trước khi xuất tài liệu. Hỏi định dạng tài liệu để user xác nhận trước khi xuất.
Anti-patterns - KHÔNG làm những điều sau
❌ Persona generic: "As a user" → ✅ "As a học viên Digital School
đã đăng ký khóa học và xác thực email"
❌ Goal vague: "I want to manage profile" → ✅ "I want to update
my email address"
❌ Value lặp lại goal: "So that I can manage profile" → ✅ "So that
I receive notifications at correct address"
❌ AC mô tả UI: "Then button turns blue" → ✅ "Then system displays
confirmation message"
❌ AC chứa logic kỹ thuật: "Then call API /v1/users/update" →
✅ "Then user data is updated and persisted"
❌ AC quá ít: chỉ có 1 happy path → ✅ tối thiểu 3 AC bao quát các
nhánh
❌ Story quá lớn: 1 story cover cả CRUD → ✅ tách thành Create,
Read, Update, Delete riêng
Khi nào cần split User Story?
Đề xuất split khi gặp các dấu hiệu:
- Story chứa từ "AND" trong tiêu đề ("Login AND register")
- Có nhiều persona khác nhau trong 1 story
- Story cover nhiều CRUD operation
- AC vượt quá 7-8 scenarios
- Dev ước lượng > 5 ngày làm việc
Pattern split phổ biến:
- Theo CRUD: tách Create / Read / Update / Delete
- Theo persona: tách Học viên / Mentor / Admin / Doanh nghiệp
- Theo business rule: tách Happy path / Validation / Permission
- Theo data type: tách theo loại data xử lý
Tham khảo thêm
templates/user-story-template.md - template trống điền vàotemplates/ac-template.md - template AC chuẩn Gherkinreferences/invest-criteria.md - giải thích sâu INVESTreferences/examples.md - 7 ví dụ mẫu cho EdTech & Digital Schoolchecklists/quality-checklist.md - checklist self-review trước khi xuất
Skill được phát triển bởi Phúc NT · BA Zone · Digital School
Vui lòng giữ nguyên attribution khi chia sẻ hoặc fork repo này.
