Bỏ qua tới nội dung
Phạm Thủy
Quay lại

Backlog Refinement cho BA

Note này giúp BA chuẩn bị và dẫn backlog refinement hiệu quả: chọn item nào cần refined, xác định ready/not ready, và ghi lại decision mở để sprint sau không lặp lại câu hỏi cũ. Refinement không phải là “họp đọc story” — nó là buổi làm rõ ambiguity trước khi team cam kết.

Note này dùng để làm gì

Mở note trước mỗi buổi refinement, khi backlog ngày càng dài nhưng story vẫn mơ hồ, hoặc khi dev/test liên tục hỏi lại “cái này nghĩa là gì” trong sprint. Đọc sau User Story & AC.

Backlog Refinement Flow — Từ mường tượng tới sẵn sàng

1. Refinement không phải là sprint planning mini

Không phải là
Làm rõ requirement, AC, dependency, UI/UX trước sprintChốt scope sprint (đó là planning)
Tách story quá lớn, thêm AC thiếuEstimate chính xác đến giờ (đó là planning)
Xác định item “ready” cho sprint tớiDemo hoặc review (đó là sprint review)
Phát hiện gap, assumption, open questionQuyết định priority (đó là PO)

2. Definition of Ready (DoR): story đủ chín để vào sprint

Tiêu chíCâu hỏi kiểmAi chịu trách nhiệm
Story rõ ràngRole, objective, value (để…) có đủ không?BA
Acceptance CriteriaCó ≥ 2 AC verifiable, gồm ít nhất 1 failure path?BA
Dependency resolvedStory có phụ thuộc API, team khác, hoặc story khác? Ai đã confirm?BA + Tech Lead
UI/UX readyCó wireframe/mockup cho màn hình liên quan? Nếu chưa, ai đang làm?BA + Designer
Estimate đượcTeam có đủ context để estimate không?BA cung cấp context
TestableTester có thể viết test case từ AC không?BA + Tester

Item không đạt DoR → không vào sprint. BA ghi rõ gap và owner, chuyển về “Not Ready” trong backlog.

3. Chuẩn bị refinement

Trước buổi refinement, BA chuẩn bị:

  1. Chọn 3–5 item từ top backlog (ưu tiên item cho sprint tới).
  2. Mỗi item có: story + AC hiện tại, wireframe/mockup nếu có, dependency đã biết.
  3. Đánh dấu câu hỏi mở: “cần team input về feasibility”, “cần PO chốt rule”.
  4. Gửi pre-read ít nhất 1 ngày trước.
  5. Timebox: 60–90 phút, không quá 2 giờ.

4. Trong refinement

BướcHoạt độngOutput
1. BA trình bàyđọc story, AC, context (2–3 phút/item)team hiểu need
2. Team hỏidev/test nêu ambiguity, feasibility concernlist question
3. Làm rõBA trả lời hoặc ghi open questionAC cập nhật hoặc gap có owner
4. Split nếu cầnnếu story > 8 điểm, tách ngay trong buổistory mới
5. Estimate sơ bộteam estimate bằng Fibonacci (không cam kết)story point estimate
6. Chốt ready/not readydựa trên DoR checklistitem vào Ready hoặc quay lại Not Ready

5. Decision log: thứ BA phải ghi lại

Mỗi buổi refinement tạo ra decision và open question. Ghi ngay, không để trong đầu:

FieldVí dụ
Decision”Payment mock sẽ trả về success/failure/error 3 trạng thái”
Context”Vì MVP chưa tích hợp payment gateway thật (SF-4 constraint)“
Người quyết định”PO + Tech Lead, ngày 15/07”
Impact”Không cần mock timeout/retry; dev ước lượng giảm từ 5 xuống 3 điểm”
Dissent / Alternative”Tester đề xuất mock cả timeout để test UI — ghi nhận, sẽ làm ở Sprint 2”

Running case: ShopFlow

Refinement cho Sprint 1 ShopFlow, chuẩn bị SF-2, SF-3, SF-6:

Trước refinement (BA chuẩn bị):

Trong refinement:

StoryCâu hỏi từ teamDecision
SF-2 Browse Catalog”Có cần search không?”Không ở Sprint 1 — để Sprint 2
SF-3 Create Order”Stock check ở đâu?”BA làm rõ: check lúc submit, atomic. Nếu cần check real-time khi add-to-cart → AC bổ sung cho Sprint 2
SF-6 Manage Stock”available = on_hand − reserved tính runtime à?”Tech Lead confirm: tính runtime, không lưu DB. AC cập nhật

Decision log:

DecisionContextNgười quyết địnhImpact
Stock check lúc submit, atomic (reject toàn bộ order nếu thiếu 1 item)SF-3 requirementPO (chủ shop)Dev SF-11 dùng transaction; không cần optimistic lock ở MVP
availableStock = on_handreserved, tính runtimeSF-6 technicalTech LeadKhông cần lưu cột availableStock trong DB; SF-14 Inventory Stock Fields bỏ field này

Sau refinement:

Bài học: Refinement không làm cho mọi story “sẵn sàng hoàn hảo”. Nó làm cho gap hiển thị và có owner. SF-7 không ready không phải thất bại — đó là output đúng của refinement.

Anti-patterns

Anti-patternVì sao nguy hiểmCách sửa
Refinement = đọc to storykhông phát hiện ambiguity, lãng phí thời gianteam đọc pre-read, refinement để hỏi và làm rõ
Mọi story đều “ready”gap bị giấu, lộ ra giữa sprintdùng DoR checklist; ready phải có evidence, không phải “tôi nghĩ nó ổn”
Không ghi decision logsprint sau lặp lại cùng câu hỏighi decision + context + owner, dán link Jira
Refinement 3 giờ, 15 storyteam mệt, không focusgiới hạn 3–5 story, 60–90 phút
BA trả lời mọi câu hỏiBA thành bottleneck, dev không sở hữu solutionđể dev đề xuất approach; BA confirm business rule

Checklist nhanh

References


Chia sẻ bài viết:

Bài trước
Agile Concepts cho BA
Bài sau
Từ Case Study ra Backlog Agile cho BA