Files
sys-analysis-design/.claude/skills/ba-2-analysis/templates/user-story-backlog.md
2026-09-22 13:46:36 +07:00

5.3 KiB
Raw Blame History

BACKLOG — <Tên module>

Version 1.0
Date YYYY-MM-DD
Author (skill ba-2-analysis)
Status 🟡 Draft
Approved by —
Source BRIEF_… v1.0 · PROCESS_… v1.0
Scope

Change Log

Version Date Người sửa Thay đổi CR

0. Sơ đồ Use Case — toàn cảnh cho PO

Một hình cho PO thấy ai làm được gì trong phạm vi này. Đây là thứ mang vào buổi duyệt G2, không phải bảng US 40 dòng.

flowchart LR
    NV(["👤 Nhân viên đối soát"])
    TN(["👤 Trưởng nhóm"])
    KT(["👤 Kế toán"])

    subgraph HT["Phạm vi US-011 … US-014"]
        UC11(["US-011 Tải file POS"])
        UC12(["US-012 Xem kết quả nhập"])
        UC13(["US-013 Xem chênh lệch"])
        UC14(["US-014 Đóng chênh lệch"])
    end

    NGOAI[["Hệ thống POS — ngoài phạm vi"]]

    NV --- UC11
    NV --- UC12
    NV --- UC13
    TN --- UC13
    TN --- UC14
    KT --- UC13
    UC11 --- NGOAI

Quy ước: dùng --- không mũi tên (quan hệ actor–use case là liên kết, không phải luồng) · ID node là UC<số US> để khớp bảng §5 · khung đôi [[ ]] = ngoài phạm vi.

Sơ đồ quá 12 use case ⇒ tách theo Epic, mỗi Epic một sơ đồ. Nhồi hết vào một hình thì không ai đọc được, và mục đích của nó là để đọc được.

🔴 Bảng đi kèm bắt buộc là bảng §5 (quy tắc W13) — sơ đồ không nói được MoSCoW, ước lượng, phụ thuộc, hay RQ nào sinh ra US đó.

Actor trong sơ đồ Vai trò trong RBAC Số US
Nhân viên đối soát ROLE-01 3
Trưởng nhóm ROLE-02 2
Kế toán ROLE-03 1

Actor ở đây phải khớp vai trò trong RBAC_….md. Lệch nhau ⇒ một trong hai tài liệu sai.

1. Cây phân rã

flowchart LR
    RQ007["RQ-007 &lt;phát biểu ngắn&gt;"]
    E02["EPIC-02 &lt;tên&gt;"]
    F05["FEAT-05 &lt;tên&gt;"]
    F06["FEAT-06 &lt;tên&gt;"]
    U11(["US-011 &lt;tên ngắn&gt;"])
    U12(["US-012 &lt;tên ngắn&gt;"])
    U13(["US-013 &lt;tên ngắn&gt;"])

    RQ007 --> E02
    E02 --> F05
    E02 --> F06
    F05 --> U11
    F05 --> U12
    F06 --> U13

Ba tầng, không nhảy cóc. Một RQ ra nhiều EPIC thì vẽ nhiều nhánh; nhiều RQ cùng ra một EPIC cũng hợp lệ — vẽ nhiều mũi tên vào.

2. Epic

ID Tên Giá trị nghiệp vụ RQ phủ Feature Ưu tiên
EPIC-01 RQ-001, RQ-003 FEAT-01…03

3. Feature

ID Tên Epic Mô tả một câu US MoSCoW
FEAT-01 EPIC-01 US-001…004 Must

4. User Story

Mẫu — cả ba vế bắt buộc: Là <vai trò cụ thể>, tôi muốn <hành động>, để <giá trị nghiệp vụ>.

Vai trò phải cụ thể ("nhân viên đối soát"), không được là "người dùng". Vế để trống hoặc lặp lại vế muốn ⇒ US này chưa chứng minh được giá trị.

US-011 — <tên ngắn>

Feature FEAT-05
RQ RQ-007
MoSCoW Must
Vai trò
Phụ thuộc (US phải xong trước, nếu có)
BR áp dụng BR-021, BR-022
Ước lượng sơ bộ S / M / L / XL

Story:

Là …, tôi muốn …, để ….

Phạm vi:

  • Trong: …
  • Ngoài: …

Điều kiện nghiệm thu mức thô (chi tiết Given/When/Then viết ở GĐ3)

  • …

INVEST:

I N V E S T Ghi chú nếu không đạt
✅ ✅ ✅ ⚠️ ✅ ✅ E: chưa rõ nguồn dữ liệu POS → OQ-014

5. Bảng tổng hợp US

ID Tên Feature RQ MoSCoW Ước lượng Phụ thuộc INVEST Trạng thái
US-011 FEAT-05 RQ-007 Must M — ✅ Draft

6. Đối chiếu ngược RQ → US (bảng bắt buộc)

RQ Phát biểu ngắn MoSCoW US phủ Trạng thái
RQ-001 Must US-001, US-002 ✅ Đã phủ
RQ-005 Should — 🔴 CHƯA PHỦ

RQ chưa phủ ⇒ giải thích từng cái: bị hoãn sang phase sau (ghi DEC-nn), hay bỏ sót?

7. US không truy về RQ nào (nghi ngờ scope creep)

US Từ đâu ra Đề xuất PO quyết
US-0nn (ai đề xuất, buổi nào) Giữ / Bỏ / Hoãn ☐

Không im lặng giữ. Mỗi dòng phải có PO quyết.

8. Đề xuất thứ tự thực hiện

BA đề xuất, PO chốt. Sắp theo: phụ thuộc kỹ thuật → giá trị → rủi ro.

Đợt US Lý do xếp trước Kết quả demo được
1 US-001, US-011 Nền tảng dữ liệu, US khác phụ thuộc Nhập được file POS
2

9. Open Questions

ID Câu hỏi Hỏi ai Từ ngày Chặn US nào

10. Ngoài phạm vi

  • Ước lượng story point chính thức → team dev ở buổi grooming
  • Thiết kế màn hình, field spec → GĐ3 SRS