Mở đầu — vì sao bài này quan trọng
Có một câu hỏi mà gần như mọi Project Manager đều phải đối mặt sớm hay muộn: "Khi nào thì xong?". Sếp hỏi, khách hàng hỏi, đối tác hỏi. Và nếu bạn chỉ trả lời bằng cảm tính — "chắc khoảng hai tháng nữa" — bạn đang đặt uy tín của mình lên một canh bạc.
Agile không xóa bỏ câu hỏi đó. Nhưng Agile cho bạn một cách trả lời tốt hơn cảm tính: dựa trên dữ liệu thực tế mà chính team của bạn tạo ra qua từng Sprint, từng tuần. Đó là lúc ba chỉ số (metrics) trong bài này phát huy sức mạnh — Velocity, Throughput, và Cumulative Flow Diagram (CFD).
Đây là bộ ba công cụ đo lường "nhịp giao hàng" của team. Velocity dành cho thế giới Scrum, đo bằng story points. Throughput dành cho thế giới Kanban, đếm số việc hoàn thành. Còn CFD là một biểu đồ trực quan giúp bạn "nhìn thấy" công việc đang tắc nghẽn ở đâu trong quy trình — thứ mà hai con số kia không nói cho bạn biết.
Lưu ý quan trọng ngay từ đầu: ba chỉ số này dùng để dự báo (forecast) và cải tiến quy trình, KHÔNG phải để đánh giá năng suất cá nhân hay so sánh team này với team kia. Đây là cạm bẫy lớn nhất mà chúng ta sẽ mổ xẻ kỹ ở phần sau. Hiểu sai mục đích của metrics còn nguy hiểm hơn là không có metrics nào cả.
Khái niệm cốt lõi
Velocity — nhịp độ của team Scrum
Velocity là tổng số story points của các Product Backlog Item được hoàn thành (đạt Definition of Done) trong một Sprint. Lưu ý chữ "hoàn thành" — một item làm dở 90% vẫn tính là 0 điểm. Velocity không cho điểm cho nỗ lực, chỉ cho điểm cho kết quả đã "Done".
Ví dụ: Sprint này team commit 8 item với tổng 34 points. Cuối Sprint, có 6 item Done với tổng 28 points, 2 item chưa xong. Velocity của Sprint = 28, không phải 34.
Ba đặc tính cần nhớ về Velocity:
- Nó là số tương đối của riêng một team. Velocity = 40 của team A không "giỏi hơn" Velocity = 20 của team B, vì story point của hai team được định nghĩa khác nhau (xem Bài 21 về Story Points). So sánh velocity giữa các team là sai lầm cơ bản.
- Nó cần thời gian để ổn định. Một team mới thường có velocity dao động mạnh trong 3–5 Sprint đầu, rồi mới hội tụ về một khoảng tương đối ổn định. Đừng vội kết luận gì từ 1–2 Sprint đầu tiên.
- Nó dùng để dự báo, không phải mục tiêu. Khi velocity trung bình của team là 30, bạn có thể ước lượng: backlog còn 180 points → cần khoảng 6 Sprint nữa. Đó là dự báo. Nếu bạn biến "30 points" thành KPI bắt buộc, team sẽ thổi phồng điểm số (point inflation) và con số mất hết ý nghĩa.
Throughput — nhịp độ của team Kanban
Throughput là số lượng work item hoàn thành trong một đơn vị thời gian (thường là mỗi tuần hoặc mỗi ngày). Khác với Velocity, Throughput đếm số đầu việc, không quan tâm kích cỡ — một bug nhỏ và một feature lớn đều tính là "1 item".
Nghe có vẻ thô sơ, nhưng đây lại là điểm mạnh. Trong môi trường Kanban dòng chảy liên tục (continuous flow), không có Sprint, không có buổi estimate, throughput cho bạn dữ liệu dự báo mà không tốn công ước lượng story points. Đây cũng là nền tảng của trào lưu #NoEstimates (sẽ bàn kỹ ở Bài 49).
Điều kiện để throughput đáng tin cậy: các work item phải được chia nhỏ tương đối đồng đều. Nếu team có item to bằng cả tháng nằm chung với item bằng nửa ngày, throughput sẽ nhiễu loạn. Một team Kanban trưởng thành thường nỗ lực "right-sizing" — chẻ mọi việc xuống cỡ làm xong trong 1–3 ngày.
Throughput thường được dùng kèm với Cycle Time (thời gian từ lúc bắt đầu làm một item đến lúc xong) và Lead Time (từ lúc item được tạo đến lúc giao). Bộ ba throughput + cycle time + WIP liên kết với nhau qua Định luật Little: WIP = Throughput × Cycle Time. Định luật này nói rằng nếu bạn ôm quá nhiều việc cùng lúc (WIP cao), cycle time sẽ phình ra — đây là lý do toán học vì sao "làm ít việc một lúc lại giao nhanh hơn".
Cumulative Flow Diagram (CFD) — bức ảnh X-quang của quy trình
CFD là biểu đồ vùng (area chart) thể hiện số lượng công việc nằm ở mỗi trạng thái của quy trình theo thời gian. Trục hoành là thời gian, trục tung là số lượng item. Mỗi "vùng màu" tương ứng một cột trên Kanban board: To Do, In Progress, Review, Done...
Cách đọc CFD nhanh:
- Vùng "Done" (dưới cùng) leo dốc đều → team giao hàng ổn định. Dốc của vùng này chính là throughput.
- Khoảng cách dọc giữa đường trên cùng và đường "Done" = tổng WIP (việc đang dở dang). Vùng này càng phình to, càng nhiều việc đang kẹt.
- Khoảng cách ngang giữa lúc một item vào hệ thống và lúc nó ra ≈ Lead Time trung bình.
- Một vùng màu nào đó phình to bất thường → đó là nút thắt cổ chai (bottleneck). Ví dụ vùng "Review" cứ rộng dần ra nghĩa là việc dồn ở khâu review, có thể do thiếu người review hoặc reviewer quá tải.
- Đường trên cùng (Backlog) dốc đứng còn "Done" gần như nằm ngang → việc đổ vào nhanh hơn việc làm xong rất nhiều, hệ thống đang quá tải, sớm muộn sẽ vỡ kế hoạch.
Tình huống thực tế
Ví dụ 1 — Tiki: forecast bằng dải velocity thay vì một con số
Một team phát triển tính năng ví thanh toán tại một sàn thương mại điện tử lớn (tương tự Tiki) có velocity 6 Sprint gần nhất lần lượt là: 32, 28, 35, 30, 33, 29 points. Backlog còn lại của tính năng là 200 points.
Cách làm sai (mà nhiều PM hay mắc): lấy velocity Sprint cao nhất (35) để hứa với sếp → 200 / 35 ≈ 6 Sprint → "khoảng 3 tháng là xong". Đây là dùng kịch bản lạc quan nhất làm cam kết, gần như chắc chắn trễ hẹn.
Cách làm đúng mà PM của team áp dụng: tính theo dải.
- Bi quan: 200 / 28 ≈ 7,1 → làm tròn 8 Sprint.
- Kỳ vọng (trung bình ~31): 200 / 31 ≈ 6,5 → 7 Sprint.
- Lạc quan: 200 / 35 ≈ 5,7 → 6 Sprint.
Bài học: Velocity là dữ liệu xác suất, không phải lời hứa chắc nịch. Luôn forecast bằng dải, và đặt cam kết gần với kịch bản bi quan-trung bình, không phải lạc quan.
Ví dụ 2 — Đội vận hành của một fintech Singapore: CFD lộ nút thắt ở khâu QA
Một team Kanban xử lý yêu cầu tích hợp đối tác tại một công ty fintech ở Singapore than phiền "làm hoài không xong việc". Velocity-kiểu-đếm (throughput) tụt từ 12 item/tuần xuống còn 6 item/tuần trong một tháng, dù số người không đổi.
Họ vẽ CFD và phát hiện: vùng "In Dev" và "To Do" bình thường, nhưng vùng "QA/Test" phình to liên tục — việc làm xong code thì dồn ứ ở khâu kiểm thử. Nguyên nhân: cả team chỉ có 1 QA, trong khi 5 developer cứ đẩy việc sang. Định luật Little hiện rõ: WIP ở khâu QA tăng vọt → cycle time của mọi item kéo dài → throughput tổng giảm.
Hành động: họ đặt WIP limit = 3 cho cột QA (dev không được đẩy quá 3 việc vào hàng đợi QA), đồng thời cho 2 developer học cross-skill để hỗ trợ test. Sau 3 tuần, vùng QA trên CFD co lại, throughput hồi phục lên 11 item/tuần.
Bài học: Khi throughput giảm mà không rõ lý do, CFD là công cụ chẩn đoán số một. Nút thắt cổ chai gần như luôn lộ ra dưới dạng một vùng phình to bất thường.
Ví dụ 3 — Một team gia công ở Hà Nội: velocity "đẹp" nhưng giả
Một team outsourcing ở Hà Nội báo cáo velocity tăng đều: 25 → 30 → 38 → 45 points qua 4 Sprint. Sếp rất vui, tưởng team ngày càng hiệu quả. Nhưng khách hàng phàn nàn lượng tính năng giao thực tế không hề tăng tương ứng.
Điều tra ra: vì sếp lấy velocity làm KPI thưởng phạt, team đã âm thầm thổi phồng điểm (point inflation) — việc trước kia ước 3 điểm giờ ước 5 điểm. Velocity tăng trên giấy, nhưng lượng giá trị giao cho khách không đổi. Tệ hơn, vì bị ép "Sprint sau phải hơn Sprint trước", team bắt đầu đánh dấu Done cho cả những việc chưa thực sự đạt Definition of Done, để lại đống nợ kỹ thuật.
Khi Scrum Master chuyển từ đo velocity sang đối chiếu throughput thực (số tính năng khách nhận được) và CFD, sự thật lộ ra: vùng Done trên CFD leo gần như nằm ngang dù velocity báo cáo tăng vọt.
Bài học: Bất kỳ metric nào bị biến thành mục tiêu/KPI đều sẽ bị "gaming" (lách). Đây chính là Định luật Goodhart: "Khi một thước đo trở thành mục tiêu, nó không còn là thước đo tốt nữa." Metrics phải phục vụ team để tự cải tiến, không phải để cấp trên kiểm soát.
Hướng dẫn từng bước
Bước 1 — Chọn đúng chỉ số cho khung làm việc của bạn. Dùng Scrum theo Sprint cố định? → Velocity. Dùng Kanban dòng chảy liên tục? → Throughput + Cycle Time. Cả hai? → Vẫn nên vẽ CFD vì nó dùng được cho cả hai.
Bước 2 — Thu thập dữ liệu sạch. Định nghĩa rõ "Done" nghĩa là gì (xem Bài 16 về Definition of Done). Một item chỉ được tính khi đạt DoD. Dữ liệu rác đầu vào → forecast rác đầu ra.
Bước 3 — Tích lũy đủ lịch sử. Cần tối thiểu 3–5 Sprint (với Velocity) hoặc vài tuần (với Throughput) để con số ổn định. Trước mốc đó, hãy coi mọi forecast là tạm thời.
Bước 4 — Tính dải forecast. Lấy giá trị thấp / trung bình / cao của vài kỳ gần nhất. Trình bày kết quả dưới dạng khoảng thời gian ("6–8 Sprint"), không bao giờ là một con số tuyệt đối.
Bước 5 — Vẽ và đọc CFD định kỳ. Hầu hết công cụ (Jira, Azure DevOps, Trello + Power-Up) đều có sẵn báo cáo CFD. Mỗi tuần nhìn một lần: vùng nào đang phình? Vùng Done có leo đều không?
Bước 6 — Mang dữ liệu vào Retrospective. Đây là bước nhiều team bỏ quên. Metrics chỉ có giá trị khi dẫn đến hành động cải tiến. Trong Sprint Retrospective (Bài 14), hỏi: "CFD tuần này cho thấy điều gì? Ta cần đặt WIP limit ở đâu? Velocity dao động mạnh vì lý do gì?"
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng velocity để so sánh giữa các team. Story point là thước đo nội bộ. So sánh velocity giữa team là so sánh hai loại đơn vị khác nhau. Mẹo: nếu lãnh đạo muốn so sánh team, hãy chuyển sang chỉ số kết quả như lead time hoặc giá trị giao cho khách, không phải velocity.
Lỗi 2 — Biến metric thành KPI thưởng/phạt. Như ví dụ 3, điều này luôn dẫn đến point inflation và đánh dấu Done giả. Mẹo: tách bạch rõ — metrics là của team, để team tự soi; không gắn vào lương thưởng cá nhân.
Lỗi 3 — Tính cả việc làm dở vào velocity. "Gần xong" = 0 điểm. Mẹo: giữ kỷ luật DoD tuyệt đối, không cho điểm bán phần.
Lỗi 4 — Ám ảnh velocity cao thay vì velocity ổn định. Một team có velocity 30 đều đặn dễ dự báo hơn nhiều so với team dao động 20–50. Mẹo: ưu tiên giảm độ dao động (variance) hơn là tăng con số trung bình.
Lỗi 5 — Bỏ qua WIP. Nhiều team chỉ nhìn throughput mà quên rằng WIP cao đang bóp nghẹt cycle time. Mẹo: áp dụng Định luật Little — muốn giao nhanh hơn, hãy giới hạn việc đang làm đồng thời, đừng nhồi thêm việc.
Lỗi 6 — Vẽ CFD nhưng không đọc. Có biểu đồ mà không phân tích thì vô nghĩa. Mẹo: mỗi Retrospective dành 5 phút "đọc" CFD như đọc phim X-quang — tìm vùng phình bất thường.
Bài tập thực hành
Bài tập 1 — Forecast bằng dải. Team bạn có velocity 5 Sprint gần nhất: 22, 26, 24, 30, 23. Backlog còn 150 points. Hãy tính dải forecast (bi quan / kỳ vọng / lạc quan) theo số Sprint, rồi viết một câu báo cáo cho sếp giống cách PM ở Ví dụ 1 đã làm.
Bài tập 2 — Chẩn đoán CFD. Tìm trên Google Images một mẫu CFD có vùng "In Review" phình to dần. Viết 3 câu: (a) nút thắt đang ở đâu, (b) giả thuyết nguyên nhân, (c) một hành động cụ thể bạn sẽ đề xuất trong Retrospective.
Bài tập 3 — Áp dụng Định luật Little. Team Kanban của bạn có throughput trung bình 10 item/tuần và đang ôm WIP = 30 item. Hãy tính cycle time trung bình (theo tuần). Nếu giảm WIP xuống 15 mà giữ nguyên throughput, cycle time mới là bao nhiêu? Rút ra kết luận gì?
Bài tập 4 — Tự phản tư. Trong dự án hiện tại của bạn (hoặc dự án gần nhất), có metric nào đang vô tình bị dùng làm KPI thưởng/phạt không? Nó có dấu hiệu bị "gaming" không? Bạn sẽ điều chỉnh thế nào?
Tóm tắt
- Velocity = tổng story points đã Done trong một Sprint; dành cho Scrum; cần 3–5 Sprint để ổn định; dùng để forecast bằng dải, không phải làm KPI.
- Throughput = số work item hoàn thành mỗi đơn vị thời gian; dành cho Kanban; không cần estimate; đáng tin khi item được chia nhỏ đồng đều.
- CFD = biểu đồ vùng cho thấy công việc nằm ở mỗi trạng thái theo thời gian; là công cụ chẩn đoán nút thắt số một; vùng phình to = bottleneck.
- Định luật Little (
WIP = Throughput × Cycle Time) giải thích vì sao giới hạn WIP giúp giao hàng nhanh hơn. - Tất cả metrics này phục vụ dự báo và cải tiến, KHÔNG phải đánh giá cá nhân hay so sánh team. Khoảnh khắc một metric thành mục tiêu, nó sẽ bị bóp méo (Định luật Goodhart).
- Quy tắc vàng: forecast bằng dải, ưu tiên ổn định hơn con số cao, và luôn mang dữ liệu vào Retrospective để biến thành hành động.