Velocity & Forecasting

Delivery

Đo velocity sạch và dự báo timeline có confidence interval, không phải con số đẹp cho boss.

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á

Kỹ năng này cho bạn điều gì

Bắt đầu từ đây

Velocity là tổng story point đội hoàn thành trong một sprint, và nó có ĐÚNG MỘT mục đích: dự báo. Dùng nó làm KPI đánh giá là cách nhanh nhất để phá nó — đội sẽ thổi phồng ước lượng, và bạn mất luôn công cụ dự báo.

Khi đã làm được

Dự báo được timeline kèm mức tin cậy thay vì một con số: lấy trung bình 5–6 sprint đã loại nhiễu, nói “85% khả năng xong trong 7 sprint” thay vì “xong trong 5”, và dùng cycle time khi cần một con số dễ giải thích hơn cho người ngoài đội.

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

Đã đọc 0/15 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.

Velocity & Forecasting là gì?

Velocity là lượng công việc một đội hoàn thành mỗi sprint, đo bằng đơn vị của chính đội đó.

Vì đơn vị là tương đối, velocity không so sánh được giữa hai đội — và mọi rắc rối với chỉ số này đều bắt đầu từ lúc có người quên điều đó.

Velocity hay cycle time — nói với ai thì dùng cái nào

	Velocity	Cycle time
Đo gì	Bao nhiêu việc mỗi sprint	Một việc mất bao lâu từ đầu đến cuối
Nói với đội	Tốt — họ hiểu đơn vị	Tốt
Nói với người ngoài	Tệ — “25 điểm” không có nghĩa gì	Tốt — “một tính năng mất 3–7 ngày”
Ổn định	Dao động theo nghỉ lễ, người vắng	Ổn định hơn

Khi nào bạn gặp chuyện này

Tình huống	Bạn làm gì	Nếu không
Sếp hỏi “bao giờ xong?” và muốn một ngày cụ thể.	Trả lời kèm mức tin cậy: “85% khả năng trong 7 sprint; nếu cần chắc hơn thì 9.” Cho họ chọn mức rủi ro.	Bạn đưa một ngày, trượt, và lần sau mọi ước lượng của bạn đều bị cộng thêm hệ số.
Quản lý đặt mục tiêu “velocity tăng 10% quý này”.	Giải thích rằng đơn vị do đội tự định nghĩa, nên mục tiêu đó tự thoả mãn được trong một sprint. Đề xuất đo cycle time hoặc kết quả kinh doanh thay thế.	Đội thổi phồng ước lượng, số đẹp lên, và bạn mất luôn khả năng dự báo.
Velocity sprint này rơi 40%.	Kiểm nghỉ lễ, người vắng, sự cố trước khi kết luận gì. Loại sprint nhiễu khỏi trung bình.	Bạn kết luận đội chậm đi, và đội học được rằng báo cáo trung thực thì bị phạt.

Velocity dùng đúng

Lấy trung bình 5–6 sprint gần nhất (loại outlier).
Forecast: "Còn 120 SP backlog, velocity 25 SP/sprint → ~5 sprint."
Thêm buffer 20–30% cho uncertainty.

Velocity dùng sai (anti-patterns)

Manager đặt KPI "velocity tăng 10%" → team game bằng inflated estimate.
So sánh velocity giữa team — story point relative, không cross-team.
Forecast bằng exact number không có confidence range.

Forecast nâng cao — Monte Carlo

Thay vì dùng average, sample randomly từ history → distribution outcome. Tool: Throughput Forecaster (Daniel Vacanti), Actionable Agile.

50% confidence: 5 sprint.
85% confidence: 7 sprint.
95% confidence: 9 sprint.

Cycle time — companion metric

Thời gian từ "start" tới "done" của 1 story. Track distribution (median, p85, p95) trên scatter plot. Cycle time stable hơn velocity và dễ communicate "1 feature mất 3–7 ngày".

Trả lời “bao giờ xong?” trong 5 phút

Bước	Làm gì	Bẫy
1	Lấy 5–6 sprint gần nhất, loại sprint có nghỉ lễ hoặc sự cố lớn	Lấy cả sprint nhiễu
2	Tính trung bình và khoảng dao động	Chỉ lấy trung bình
3	Chia khối lượng còn lại	Quên việc phát sinh trong lúc làm
4	Cộng đệm 20–30%	Bỏ đệm để con số đẹp hơn
5	Nói kèm mức tin cậy	Đưa một ngày duy nhất

Sai lầm thường gặp

Sai lầm	Vì sao hỏng	Làm thay bằng
Dùng velocity làm KPI	Đội thổi phồng ước lượng và chỉ số mất ý nghĩa.	Chỉ dùng để dự báo; đo kết quả bằng thứ khác.
So velocity giữa các đội	Đơn vị là tương đối, không quy đổi được.	So cycle time nếu thật sự cần so.
Đưa một con số duy nhất	Dự báo không có khoảng là một lời hứa.	Luôn kèm mức tin cậy.
Đếm cả bug và nợ kỹ thuật	Nhiễu làm dự báo sai.	Nhất quán về việc đếm gì, ghi rõ.

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

Vai trò	Bạn dùng nó để
Product Owner	Đây là cách bạn trả lời “bao giờ xong” mà không phải hứa liều.
Engineering Manager	Bạn bảo vệ đội khỏi việc chỉ số này bị biến thành thước đo hiệu suất.
Product Manager	Cycle time là con số bạn nên mang ra ngoài đội, không phải velocity.
Scrum Master	Bạn giữ cho cách đếm nhất quán qua các sprint.

Definition of done — dấu hiệu bạn đã đạt

Bạn luôn trả lời timeline kèm mức tin cậy, không bao giờ một ngày duy nhất.
Velocity không xuất hiện trong bất kỳ báo cáo hiệu suất nào.
Sprint nhiễu được loại khỏi trung bình một cách có quy tắc.
Bạn dùng cycle time khi nói chuyện với người ngoài đội.

Vì sao dự báo hay sai — bốn nguyên nhân theo thứ tự phổ biến

Nguyên nhân	Biểu hiện	Cách xử lý
Chỉ đếm việc trên bảng	Đội luôn "chậm hơn kế hoạch" dù làm hết sức	Nguyên nhân số một. Trực sự cố, hỗ trợ, họp, bảo trì thường chiếm 25–40% và không nằm trên bảng. Đo nó rồi trừ ra trước khi dự báo.
Dùng trung bình thay vì khoảng	Dự báo trông chính xác rồi trượt	Dùng khoảng từ 3–6 sprint gần nhất: nhanh nhất, chậm nhất, thường gặp
Bỏ qua phụ thuộc bên ngoài	Chậm vì chờ đội khác, nhưng biên bản ghi đội mình chậm	Dự báo riêng phần phụ thuộc, và ghi ngày bắt đầu chờ
Đội đổi người giữa chu kỳ	Tốc độ tụt mà không ai giải thích được	Người mới làm đội CHẬM lại trong 4–6 tuần đầu; tính vào dự báo thay vì giả vờ không có

Cách nói dự báo cho đúng: không nói "xong ngày 15/6". Nói "khả năng cao xong trong khoảng 10–24/6; nếu phần tích hợp với đối tác trễ thì lùi thêm 2 tuần". Một khoảng trung thực xây được niềm tin; một ngày chính xác giả tạo thì phá nó.

Cách dự báo trong thực tế — từng bước

Bước 1 — Lấy tốc độ 6 sprint gần nhất, bỏ sprint bất thường. Sprint có nghỉ lễ dài hay có sự cố lớn thì ghi chú riêng, đừng trộn vào.
Bước 2 — Tính ba con số, không tính một. Thấp nhất, cao nhất, và giá trị hay gặp. Ba con số này thành ba kịch bản dự báo.
Bước 3 — Đo phần thời gian không nằm trên bảng. Một tuần, ghi lại thời gian thật dành cho trực sự cố, hỗ trợ, họp ngoài kế hoạch. Con số này gần như luôn cao hơn cả đội tưởng, và nó là lý do số một khiến dự báo sai.
Bước 4 — Đếm khối lượng còn lại theo cùng đơn vị đã dùng để đo tốc độ. Trộn đơn vị là lỗi âm thầm và rất phổ biến.
Bước 5 — Chia ra, rồi cộng thêm phần phụ thuộc bên ngoài như một khoản riêng có rủi ro riêng.
Bước 6 — Trình bày bằng khoảng kèm điều kiện. "10–24/6, với giả định đối tác giao tài liệu trước 01/6."

Về việc dự báo cho việc chưa từng làm: tốc độ lịch sử không áp dụng được. Đừng giả vờ là có. Cách trung thực hơn là chia nhỏ tới mức có phần tương tự việc đã làm, và đánh dấu rõ phần còn lại là chưa biết — kèm một khoảng rất rộng.

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

Vai trò	Bạn dùng nó để
Delivery Manager	Dự báo là sản phẩm chính của bạn; khoảng trung thực giữ được niềm tin lâu hơn một ngày chính xác giả tạo
Product Owner	Biết khi nào cam kết được với khách và khi nào phải nói là chưa biết
Team Lead	Bạn đo và nêu phần thời gian không nằm trên bảng — không ai khác nhìn thấy nó
Scrum Master	Bạn giữ cho đơn vị đo nhất quán qua các sprint
Lãnh đạo	Hiểu vì sao một khoảng đáng tin hơn một ngày cụ thể