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:

1. Persona/User type: Ai sẽ dùng tính năng? (Học viên, Mentor, Admin, Doanh nghiệp...)
2. Goal: User muốn làm gì?
3. Business value: Tại sao cần tính năng này?
4. 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:

1. User Story (3 dòng As a / I want / So that)
2. INVEST Self-check (bảng đánh giá 6 tiêu chí với ✅/⚠️)
3. Acceptance Criteria (đánh số AC1, AC2, AC3...)
4. Notes (nếu có dependency, assumption, hoặc câu hỏi cần PO làm rõ)
5. 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ào
• templates/ac-template.md - template AC chuẩn Gherkin
• references/invest-criteria.md - giải thích sâu INVEST
• references/examples.md - 7 ví dụ mẫu cho EdTech & Digital School
• checklists/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.