Sprint Planning & Refinement

Delivery

Sprint planning và refinement thực tế: Definition of Ready, story splitting, capacity, sprint goal, risk, dependencies và QA readiness.

Bạn đang ở đâu với kỹ năng này?

Làm bài Đánh giá Kỹ năng Delivery cho PM/PO — Một lần làm chấm điểm cho tất cả kỹ năng trong nhóm Delivery, không chỉ kỹ năng này.

Làm bài đánh giá

Roadmap — Cách học và đạt kỹ năng

Đã đọc 0/13 mục · còn khoảng 5 phút

Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Sprint Planning & Refinement là gì?

Refinement làm rõ work trước sprint: split, AC, risk, dependency, estimate. Sprint planning chọn sprint goal và cam kết thực tế dựa trên capacity. Nếu planning dùng để khám phá requirement từ đầu, sprint sẽ bắt đầu bằng confusion.

Sprint refinement and planning flow — Refinement tạo ready queue; planning chọn goal và scope dựa trên capacity, risk và dependency.

Definition of Ready template

Check	Good standard	Example
Goal	User/business outcome clear.	Reduce failed invite support tickets.
AC	Happy path, edge cases and data rules.	Invalid email, duplicate invite, permission denied.
Design/data	Mockups, API/data sources, analytics noted.	Invite status from events table.
Dependencies	External blockers identified.	Email provider webhook needed.
Estimate confidence	Team understands enough to size.	Spike done; story split under 3 days.

Refinement agenda 60 phút

Time	Activity	Output
0-10	Review goal and evidence	Shared context.
10-25	Walk through user flow and AC	Behavior clarified.
25-40	Identify risks, dependencies, unknowns	Open questions with owners.
40-50	Split stories	Small deliverable slices.
50-60	Estimate and DoR check	Ready/Not Ready decision.

Case study: checkout payment sprint

Bad planning: “Implement payment gateway” in one sprint. Better refinement: split into create payment request, handle success callback, pending state polling, failure handling, duplicate callback audit.

Sprint goal: allow customers to complete payment safely without double charge.
Tradeoff: release MoMo first, defer saved cards.
Risk: callback timeout; spike before commitment.

Pitfalls

Planning by filling capacity instead of choosing a sprint goal.
Accepting stories without AC or owner for open questions.
Overcommitting because holidays, support work and incidents are ignored.
Splitting by frontend/backend only, leaving no user-visible value.

Definition of done

Sprint has one clear goal.
Committed items meet Definition of Ready.
Risks and dependencies are explicit.
Tradeoffs are understood by PM, Engineering and QA.

Hai buổi khác nhau, hay bị gộp làm một

	Làm rõ việc (refinement)	Lập kế hoạch sprint (planning)
Câu hỏi	Việc này nghĩa là gì, cần gì để làm được?	Sprint tới chúng ta nhận việc nào?
Khi nào	Giữa sprint	Đầu sprint
Đầu ra	Việc đủ rõ để ước lượng	Cam kết cho sprint tới
Gộp lại thì	—	Buổi lập kế hoạch kéo dài 3 tiếng và đội vẫn không hiểu việc

Dấu hiệu rõ nhất của việc gộp sai: buổi lập kế hoạch có nhiều câu "cái này nghĩa là gì?" Nếu câu hỏi đó xuất hiện, việc chưa qua khâu làm rõ — và không nên nhận nó vào sprint.

Việc "đã sẵn sàng" nghĩa là gì — danh sách kiểm

Có mô tả vấn đề, không chỉ mô tả giải pháp. Đội cần biết vì sao, để họ đề xuất được cách rẻ hơn.
Có điều kiện xác nhận cụ thể, viết dạng ví dụ, kèm ít nhất một ca ngoại lệ.
Phụ thuộc đã được xác định và xác nhận. Cần dữ liệu từ đội khác thì đội đó đã đồng ý, bằng chữ.
Đủ nhỏ để xong trong một sprint. Nếu không, cắt trước khi nhận.
Đội ước lượng được. Không ước lượng được là tín hiệu thiếu hiểu biết, không phải lý do ép cho một con số.
Có người trả lời được câu hỏi trong sprint. Nếu PO đi vắng cả sprint thì việc này chưa sẵn sàng.

Quy tắc bảo vệ đội: việc không đạt danh sách này thì không vào sprint. Đây là quy tắc khó giữ nhất và có tác dụng lớn nhất — phần lớn sprint trượt bắt đầu từ việc nhận vào thứ chưa rõ.

Chạy buổi lập kế hoạch — 60 phút

Phút	Làm gì	Lưu ý
0–10	PO nhắc mục tiêu sprint — một câu, không phải danh sách việc	Không có mục tiêu thì sprint chỉ là một đống việc ngẫu nhiên
10–20	Đội xem năng lực thật: nghỉ phép, trực sự cố, việc còn dở	Bước hay bị bỏ và là nguyên nhân số một của việc nhận quá tay
20–45	Chọn việc theo thứ tự ưu tiên, dừng khi đầy	PO quyết thứ tự, đội quyết bao nhiêu — ranh giới này phải rõ
45–55	Với mỗi việc: ai làm, cần gì để bắt đầu	Việc không có người bắt đầu là việc sẽ nằm im
55–60	Đọc lại cam kết và xác nhận	Nói thành lời khác với ngầm hiểu

Ranh giới quan trọng nhất: PO quyết thứ tự, đội quyết bao nhiêu. Khi ranh giới này bị phá — PO ép nhận thêm — đội sẽ ngừng cam kết thật, và mọi ước lượng sau đó đều là phòng thủ.

Hiccups thường gặp và cách xử lý

Hiccup	Vì sao xảy ra	Xử lý
Buổi lập kế hoạch kéo 3 tiếng	Việc chưa qua khâu làm rõ	Tách hai buổi; việc chưa rõ thì trả lại, không bàn tại chỗ
Sprint nào cũng nhận quá tay	Không trừ năng lực thật	Trừ nghỉ phép, trực sự cố, việc dở trước khi chọn việc mới
Việc dở kéo dài qua nhiều sprint	Chưa cắt đủ nhỏ	Cắt theo bước luồng hoặc quy tắc nghiệp vụ trước khi nhận
PO ép nhận thêm vào giữa sprint	Áp lực từ bên ngoài	Thêm việc thì bỏ việc khác — trao đổi ngang giá, không phải thêm vào
Đội không hỏi gì trong buổi lập kế hoạch	Chưa đủ an toàn, hoặc chưa đọc trước	Gửi danh sách việc trước 24 giờ; im lặng không có nghĩa là đã hiểu
Không có mục tiêu sprint	Chỉ có danh sách việc	Một câu mục tiêu; nếu không viết được thì sprint này chưa có hướng

Vì sao vai trò của bạn cần cái này

Vai trò	Bạn dùng nó để
Product Owner	Bạn quyết thứ tự và bảo vệ việc chỉ nhận thứ đã sẵn sàng
Scrum Master	Bạn giữ hai buổi tách nhau và giữ ranh giới PO/đội
Business Analyst	Danh sách "đã sẵn sàng" phần lớn là sản phẩm của bạn
Engineer	Bạn quyết bao nhiêu việc vào sprint — đừng nhường quyền đó
Team Lead	Bạn cung cấp năng lực thật, gồm cả phần không nằm trên bảng

Ví dụ — tính năng lực thật cho một sprint hai tuần

Đội 6 người, sprint 2 tuần. Phép tính "6 người × 10 ngày = 60 ngày công" sai ngay từ dòng đầu. Đây là phép tính đúng:

Khoản	Ngày công	Ghi chú
Lý thuyết: 6 người × 10 ngày	60	Điểm xuất phát
Trừ nghỉ phép (1 người nghỉ 3 ngày)	−3	Đã biết trước
Trừ trực sự cố (1 người trực cả sprint, mất ~50%)	−5	Luân phiên, luôn có
Trừ họp cố định (~1h/ngày/người)	−7,5	Đồng bộ, làm rõ việc, nhìn lại
Trừ việc dở từ sprint trước	−6	Phải hoàn thành trước khi nhận việc mới
Trừ hỗ trợ đội khác (ước lượng từ 3 sprint gần nhất)	−4	Luôn xảy ra, hiếm khi được tính
Năng lực thật	34,5	Khoảng 57% con số lý thuyết

Đội nhận việc theo con số 60 sẽ trượt mọi sprint — không phải vì làm chậm, mà vì phép tính sai từ đầu. Và điều tệ hơn: sau vài lần trượt, cả đội lẫn stakeholder bắt đầu tin rằng đội làm việc kém.

Ba dòng hay bị bỏ nhất là trực sự cố, họp cố định và hỗ trợ đội khác. Chúng chiếm khoảng một phần tư năng lực và không nằm trên bảng công việc, nên chúng vô hình với mọi người trừ người đang làm chúng.

Definition of done

Buổi làm rõ việc và buổi lập kế hoạch tách riêng.
Mọi việc vào sprint đều qua danh sách kiểm "đã sẵn sàng".
Năng lực thật được trừ nghỉ phép, trực sự cố và việc dở trước khi chọn việc mới.
Có mục tiêu sprint viết thành một câu.
PO quyết thứ tự, đội quyết bao nhiêu — ranh giới được tôn trọng.
Thêm việc giữa sprint luôn đi kèm bỏ việc khác.