Mở đầu — vì sao bài này quan trọng
Trong vai trò Product Owner, sớm hay muộn bạn cũng sẽ bị một stakeholder nào đó hỏi câu kinh điển: "Team mình một Sprint làm được bao nhiêu? Khi nào tính năng X xong?" Để trả lời được những câu hỏi đó một cách tự tin và có cơ sở, bạn cần hiểu cách đo lường dòng chảy công việc (flow) của team. Hai chỉ số nền tảng nhất chính là Velocity và Throughput.
Đáng buồn là đây cũng là hai chỉ số bị hiểu sai và lạm dụng nhiều bậc nhất trong thế giới Agile. Tôi đã chứng kiến không ít công ty Việt Nam biến Velocity thành công cụ để... ép team chạy nhanh hơn, để so sánh team này với team kia, hoặc để đưa vào KPI đánh giá lương thưởng. Kết quả gần như luôn giống nhau: team bắt đầu "thổi phồng" điểm số (point inflation), chất lượng đi xuống, và con số mất hết ý nghĩa.
Bài học này giúp bạn hiểu đúng bản chất của Velocity và Throughput: chúng là gì, khác nhau ra sao, dùng để làm gì, và quan trọng nhất — không nên dùng để làm gì. Khi nắm vững, bạn sẽ dùng chúng như một chiếc la bàn dự báo (forecasting) thay vì một cây roi thúc ép. Đây là kỹ năng cốt lõi để bạn trở thành một PO biết "nói chuyện bằng dữ liệu" mà vẫn bảo vệ được sức khỏe của team.
Khái niệm cốt lõi
Velocity là gì?
Velocity là tổng số Story Points (điểm câu chuyện) mà team hoàn thành — tức là đạt Definition of Done — trong một Sprint. Đây là một con số mang tính tương đối (relative) và theo từng team cụ thể.
Hãy hình dung thế này: nếu team A trong 5 Sprint gần nhất hoàn thành lần lượt 32, 28, 35, 30, 33 điểm, thì Velocity trung bình của họ rơi vào khoảng 31–32 điểm/Sprint. Con số này cho bạn biết "năng lực tiêu hóa backlog" của team trong một Sprint là bao nhiêu.
Ba đặc tính bạn phải khắc cốt ghi tâm về Velocity:
- Đơn vị tương đối, không tuyệt đối. Story Point không phải giờ, không phải ngày. Nó phản ánh độ phức tạp, công sức và rủi ro của một item so với các item khác trong cùng team. Vì vậy 1 điểm của team A có thể hoàn toàn khác 1 điểm của team B.
- KHÔNG bao giờ so sánh Velocity giữa các team. Đây là lỗi nghiêm trọng nhất. Nói "team A làm 40 điểm còn team B chỉ 25 điểm nên team A giỏi hơn" là vô nghĩa, vì thang điểm của hai team được hiệu chỉnh độc lập. Cũng giống như so sánh nhiệt độ đo bằng độ C của nhà này với độ F của nhà kia rồi kết luận nhà nào nóng hơn.
- Chỉ tính item ĐÃ Done. Một câu chuyện làm xong 90% nhưng chưa đạt Definition of Done thì tính 0 điểm trong Sprint đó, không có "điểm an ủi". Điều này giữ cho Velocity phản ánh giá trị thực sự được giao.
Throughput là gì?
Throughput là số lượng item (work item) mà team hoàn thành trong một khoảng thời gian — thường là mỗi Sprint, mỗi tuần, hoặc mỗi ngày. Khác với Velocity đếm "điểm", Throughput đơn giản chỉ đếm số đầu việc đã Done.
Ví dụ: trong Sprint vừa rồi team hoàn thành 8 User Story, 3 bug fix và 1 spike — vậy Throughput của Sprint đó là 12 item.
Điểm hấp dẫn của Throughput là nó không cần estimate (ước lượng) bằng Story Point. Bạn chỉ cần đếm. Đây là lý do các team theo trường phái Kanban hoặc "no estimates" rất ưa chuộng Throughput. Nó loại bỏ toàn bộ tranh cãi "item này 3 điểm hay 5 điểm" — vốn ngốn rất nhiều thời gian trong Planning Poker.
Velocity và Throughput khác nhau ở đâu?
| Tiêu chí | Velocity | Throughput |
|---|---|---|
| Đơn vị đo | Story Points (điểm) | Số lượng item |
| Cần estimate? | Có (phải gán điểm) | Không |
| Nhạy với kích cỡ item | Có (item to = nhiều điểm) | Không (item nào cũng tính 1) |
| Phù hợp nhất với | Scrum truyền thống | Kanban, flow-based |
Cả hai đều là chỉ số "flow", không phải chỉ số "value"
Đây là chỗ tôi muốn bạn dừng lại và suy ngẫm. Cả Velocity lẫn Throughput chỉ đo tốc độ team đẩy công việc qua đường ống — tức là output. Chúng không đo được liệu công việc đó có tạo ra giá trị (outcome) cho khách hàng hay không.
Một team có thể có Velocity 50 điểm/Sprint nhưng làm toàn những tính năng không ai dùng. Velocity cao mà giá trị bằng 0. Vì vậy hãy luôn nhớ: Velocity và Throughput là công cụ dự báo lịch trình và lập kế hoạch, không phải thước đo thành công của sản phẩm. Thước đo giá trị thực sự nằm ở những chỉ số khác (mà các bài về Evidence-Based Management và metrics sẽ bàn sâu).
Tình huống thực tế
Tình huống 1 — Tiki và cái bẫy "Velocity làm KPI"
Giả định một team thanh toán (Payment) tại một sàn thương mại điện tử lớn ở Việt Nam — ta gọi là "Tiki" cho dễ hình dung. Ban lãnh đạo kỹ thuật quyết định đưa Velocity vào báo cáo hàng quý và ngầm khen thưởng team nào "tăng Velocity đều đặn".
Trong hai quý đầu, Velocity của team tăng vù vù: từ 30 lên 38 rồi 45 điểm/Sprint. Lãnh đạo rất hài lòng. Nhưng khi PO ngồi lại phân tích, anh phát hiện một sự thật khó chịu: số lượng item hoàn thành (Throughput) gần như không đổi — vẫn quanh quẩn 9–10 item/Sprint. Cái thay đổi duy nhất là team đã âm thầm nâng điểm cho mỗi item: việc trước kia chấm 3 điểm giờ thành 5, việc 5 điểm thành 8.
Bài học rút ra: Khi Velocity bị biến thành mục tiêu (target), nó lập tức ngừng là một thước đo tốt — đúng theo Định luật Goodhart. Việc đối chiếu chéo Velocity với Throughput đã giúp PO phát hiện hiện tượng point inflation. Bài học cho bạn: đừng bao giờ để Velocity rời khỏi tay team và trở thành công cụ đánh giá hiệu suất từ trên xuống.
Tình huống 2 — Một startup fintech ở Singapore và lựa chọn dùng Throughput
Một startup fintech tại Singapore với team 6 người làm theo Kanban. Họ từng dùng Story Point nhưng nhận ra mỗi buổi Refinement tốn cả tiếng chỉ để cãi nhau item này mấy điểm, trong khi sản phẩm ở giai đoạn đầu thay đổi liên tục.
PO quyết định bỏ estimate, chuyển sang đo Throughput kèm một kỷ luật mới: mọi item phải được chẻ nhỏ sao cho không kéo dài quá 3 ngày làm việc. Sau 8 tuần, dữ liệu cho thấy Throughput dao động ổn định 7–9 item/tuần. Khi CEO hỏi "tính năng KYC mới gồm 24 item bao giờ xong?", PO trả lời được ngay: "Với Throughput hiện tại 7–9 item/tuần, nhiều khả năng mất khoảng 3 đến 4 tuần."
Bài học rút ra: Throughput cho phép dự báo lịch trình mà không cần tốn công estimate, đặc biệt hợp với team nhỏ, sản phẩm biến động nhanh, và văn hóa "ship liên tục". Điều kiện tiên quyết là kỷ luật chẻ nhỏ item về kích cỡ đồng đều.
Tình huống 3 — Team mới thành lập và cái bẫy "Velocity ba Sprint đầu"
Một công ty SaaS B2B ở TP.HCM lập một team mới hoàn toàn. Sau 3 Sprint, Velocity lần lượt là 18, 41, 25 điểm. Giám đốc sản phẩm lấy con số Sprint thứ hai (41) làm cơ sở cam kết tiến độ với khách hàng. Kết quả: team liên tục trượt cam kết, áp lực dồn lên, hai kỹ sư xin nghỉ.
Vấn đề nằm ở chỗ Velocity của một team mới luôn nhiễu loạn dữ dội trong giai đoạn đầu, vì team chưa hiệu chỉnh được thang điểm chung, chưa quen quy trình, và Definition of Done còn lỏng lẻo. Lấy đỉnh cao nhất làm chuẩn là một sai lầm thống kê.
Bài học rút ra: Velocity chỉ đáng tin sau khoảng 3–5 Sprint ổn định, và khi dùng để dự báo nên lấy dải dao động (ví dụ 18–41) thay vì một con số đơn lẻ, hoặc dùng trung bình của vài Sprint gần nhất. Cam kết dựa trên một điểm dữ liệu may mắn là tự đào hố cho mình.
Hướng dẫn từng bước
Dưới đây là quy trình thực tế để bạn bắt đầu đo và dùng đúng hai chỉ số này.
Bước 1 — Định nghĩa rõ "Done". Trước khi đếm bất cứ thứ gì, team phải thống nhất Definition of Done. Chỉ item đạt DoD mới được tính vào Velocity hoặc Throughput. Không có DoD rõ ràng thì mọi con số đều rác.
Bước 2 — Chọn đơn vị đo phù hợp với team. Nếu team đang dùng Story Point và estimate đã thành nếp, hãy dùng Velocity. Nếu team muốn giảm thời gian estimate, sản phẩm biến động nhanh, hoặc theo Kanban, hãy cân nhắc Throughput. Hoàn toàn ổn khi theo dõi cả hai song song — thực tế việc này còn giúp phát hiện point inflation như tình huống Tiki ở trên.
Bước 3 — Thu thập dữ liệu liên tục, tối thiểu 5–6 Sprint. Ghi lại số điểm/số item Done sau mỗi Sprint vào một bảng đơn giản (Google Sheet là đủ). Đừng vội kết luận từ 1–2 Sprint.
Bước 4 — Tính dải dự báo, không phải một con số. Thay vì nói "Velocity là 32", hãy nhìn vào khoảng dao động. Một cách thực dụng: lấy giá trị thấp nhất và cao nhất trong các Sprint gần đây để có kịch bản bi quan và lạc quan. Ví dụ Velocity dao động 28–35 thì với backlog 140 điểm, dự báo cần 4 đến 5 Sprint.
Bước 5 — Dùng để forecasting, dùng trong nội bộ team. Mang con số ra Sprint Planning để team tự cân nhắc nên kéo bao nhiêu việc vào Sprint. Tuyệt đối không mang Velocity của team này đi khoe hay so sánh với team khác trước mặt lãnh đạo.
Bước 6 — Theo dõi xu hướng, không soi từng Sprint. Một Sprint tụt điểm vì lễ Tết, vì người ốm, vì sự cố production là chuyện bình thường. Hãy nhìn đường xu hướng qua nhiều Sprint thay vì hốt hoảng vì một điểm lệch.
Lỗi thường gặp & mẹo
Lỗi 1 — So sánh Velocity giữa các team. Đây là lỗi phổ biến và tai hại nhất. Mỗi team có thang điểm riêng nên con số không thể so sánh trực tiếp. Mẹo: nếu lãnh đạo muốn so sánh team, hãy hướng họ sang các chỉ số outcome (mức độ hài lòng khách hàng, lead time, tỷ lệ lỗi) thay vì Velocity.
Lỗi 2 — Biến Velocity thành mục tiêu hoặc KPI. Một khi team biết họ bị chấm điểm theo Velocity, họ sẽ thổi phồng điểm số. Mẹo: giữ Velocity là công cụ dự báo của team, không phải thước đo hiệu suất do quản lý áp xuống.
Lỗi 3 — Tính điểm cho item làm dở. "Item này gần xong rồi, cho 80% điểm nhé" — không. Quy tắc nhị phân: Done thì tính trọn điểm, chưa Done thì 0 điểm. Mẹo: nếu một item thường xuyên kéo dài qua Sprint, đó là tín hiệu cần chẻ nhỏ nó hơn (kỹ thuật Story Splitting sẽ giúp bạn).
Lỗi 4 — Ép tăng Velocity. Velocity tăng không tự nhiên đồng nghĩa với năng suất tăng; nó thường chỉ là lạm phát điểm hoặc cắt giảm chất lượng. Mẹo: nếu muốn cải thiện flow thật, hãy nhìn vào các điểm nghẽn (bottleneck) trong quy trình thay vì hô khẩu hiệu "làm nhanh lên".
Lỗi 5 — Lẫn lộn flow với value. Velocity/Throughput cao không có nghĩa sản phẩm thành công. Mẹo: luôn ghép cặp chỉ số flow (đo output) với một chỉ số outcome (đo giá trị) khi báo cáo, để bức tranh không bị méo.
Mẹo nâng cao: Throughput đặc biệt mạnh khi kết hợp với dự báo xác suất (probabilistic forecasting) — chạy mô phỏng dựa trên lịch sử Throughput để nói "80% khả năng xong trước ngày X". Đây là hướng nâng cao mà một PO giỏi nên hướng tới.
Bài tập thực hành
- Phân biệt khái niệm: Trong Sprint vừa rồi team bạn hoàn thành 6 User Story (tổng 24 điểm), 2 bug (tổng 5 điểm) và 1 spike (3 điểm). Hãy tính Velocity và Throughput của Sprint này. (Gợi ý: Velocity = tổng điểm Done; Throughput = tổng số item Done.)
- Dự báo bằng dải: Velocity 5 Sprint gần nhất của team là 30, 34, 27, 31, 33. Backlog còn 160 điểm. Hãy ước lượng số Sprint cần thiết theo kịch bản bi quan (dùng Velocity thấp nhất) và lạc quan (dùng cao nhất). Bạn sẽ cam kết con số nào với stakeholder và vì sao?
- Phát hiện point inflation: Cho dữ liệu 4 Sprint — Velocity: 28, 35, 42, 50 nhưng Throughput: 10, 10, 9, 10. Bạn nhận xét gì về sức khỏe của team? Bạn sẽ đặt câu hỏi gì trong buổi Retrospective?
- Tình huống ứng xử: Sếp bạn nói: "Team Backend làm 45 điểm/Sprint, team các bạn chỉ 28, sao chậm thế?" Hãy soạn một đoạn trả lời lịch sự nhưng vững vàng để giải thích vì sao không thể so sánh Velocity hai team, và đề xuất chỉ số thay thế phù hợp hơn.
Tóm tắt
- Velocity = tổng Story Points team hoàn thành (Done) mỗi Sprint. Đơn vị tương đối, riêng từng team, không bao giờ so sánh giữa các team.
- Throughput = số lượng item hoàn thành trong một khoảng thời gian. Không cần estimate, rất hợp với Kanban và team muốn giảm chi phí ước lượng; điều kiện là item được chẻ nhỏ tương đối đồng đều.
- Cả hai đều là chỉ số flow (output), dùng để dự báo và lập kế hoạch, không đo giá trị (outcome) của sản phẩm.
- Chỉ tính item đã Done; không có điểm cho việc làm dở.
- Đừng biến chúng thành KPI hay mục tiêu, đừng ép tăng, và hãy dự báo bằng dải dao động thay vì một con số đơn lẻ — chờ ít nhất 3–5 Sprint ổn định mới tin được dữ liệu.
- Đối chiếu chéo Velocity với Throughput là cách hữu hiệu để phát hiện point inflation.