Mở đầu — vì sao bài này quan trọng
Có một câu nói rất quen trong giới quản lý: "Cái gì không đo được thì không cải thiện được." Nhưng với Scrum Team, vấn đề thường ngược lại — đội đo quá nhiều thứ sai, hoặc đo đúng nhưng dùng số liệu sai mục đích. Tôi từng gặp một Scrum Master ở một startup fintech tại TP.HCM dán một bảng dashboard 14 chỉ số lên tường phòng họp. Khi tôi hỏi "Anh dùng con số nào để ra quyết định tuần này?", anh ấy im lặng. 14 chỉ số mà không chỉ số nào thực sự thay đổi hành vi của đội — đó là dấu hiệu của việc đo lường theo cảm tính.
Bài này tập trung vào metrics và KPIs ở cấp độ Scrum Team — tức là những con số phản ánh cách đội vận hành và giao hàng. Đây là góc nhìn khác với Bài 6 và Bài 33 (vốn nói về KPI dưới góc nhìn Product Owner và biểu đồ burndown/burnup), và khác với Bài 26 (chỉ đào sâu velocity & forecasting). Ở đây, chúng ta nhìn toàn cảnh: làm sao chọn đúng vài chỉ số, hiểu chúng thật sự nói lên điều gì, và quan trọng nhất — dùng chúng để đội tự cải thiện chứ không phải để sếp "soi" và phạt người.
Nếu bạn nắm vững bài này, bạn sẽ trả lời được ba câu hỏi mà mọi lãnh đạo đều hỏi: "Đội đang chạy nhanh hay chậm?", "Chất lượng có ổn không?", và "Bao giờ thì xong?" — một cách có dữ liệu thay vì cảm tính.
Khái niệm cốt lõi
Metrics của Scrum Team có thể chia thành bốn nhóm. Đừng cố đo hết cả bốn ngay từ đầu; hãy hiểu bản chất từng nhóm rồi chọn lọc.
Nhóm 1 — Process metrics (chỉ số quá trình)
Đây là nhóm cốt lõi, đo dòng chảy công việc qua đội.
Velocity (vận tốc): số Story Point hoàn thành trung bình mỗi Sprint. Ví dụ đội làm xong 20, 24, 22 SP trong ba Sprint gần nhất thì velocity ≈ 22. Velocity dùng để dự báo, không phải để so sánh giữa các đội. Velocity của đội A là 30 và đội B là 15 không có nghĩa đội A giỏi gấp đôi — vì cách hai đội ước lượng SP hoàn toàn khác nhau.
Throughput (thông lượng): số lượng hạng mục (stories/items) hoàn thành mỗi Sprint, đếm theo đầu việc chứ không theo điểm. Nếu đội đóng được 8 story mỗi Sprint thì throughput = 8. Throughput đặc biệt hữu ích khi đội bắt đầu chia nhỏ story đều tay — lúc đó đếm số lượng còn ổn định và dễ hiểu hơn cả velocity.
Cycle time (thời gian chu kỳ): thời gian từ lúc một hạng mục bắt đầu được làm (kéo vào cột "In Progress") đến lúc xong (Done). Ví dụ một story được kéo vào làm thứ Hai và đóng vào thứ Năm thì cycle time = 4 ngày. Đây là một trong những chỉ số quý nhất vì nó phản ánh độ "mượt" của dòng chảy.
Lead time (thời gian dẫn): thời gian từ lúc một yêu cầu được tạo ra / được đưa vào backlog đến lúc nó được giao tới tay người dùng (lên production). Lead time luôn ≥ cycle time, vì nó bao gồm cả thời gian story nằm chờ trong backlog. Nếu lead time trung bình là 45 ngày nhưng cycle time chỉ 4 ngày, bạn biết ngay vấn đề không nằm ở tốc độ code mà ở chỗ việc xếp hàng chờ quá lâu.
Một cách hình dung đơn giản: lead time = "khách đợi bao lâu từ lúc đặt món", cycle time = "bếp nấu mất bao lâu kể từ khi bắt đầu xào". Hai con số chênh nhau cho bạn biết bếp đang chờ nguyên liệu hay chờ đơn.
Nhóm 2 — Quality metrics (chỉ số chất lượng)
Tốc độ mà không có chất lượng là tự lừa dối. Các chỉ số quan trọng:
- Escaped defects: số lỗi lọt ra production và bị người dùng phát hiện, thay vì bị bắt trong Sprint. Đây là thước đo trung thực nhất về chất lượng.
- Defect density: số lỗi trên mỗi đơn vị công việc (ví dụ lỗi/story hoặc lỗi/100 SP).
- % công việc rework: tỷ lệ effort dành cho sửa lại việc đã "Done". Rework cao = Definition of Done lỏng lẻo.
Nhóm 3 — Predictability metrics (chỉ số khả năng dự báo)
Lãnh đạo thường quan tâm "có giữ đúng cam kết không" hơn là "chạy nhanh không".
- Say/Do ratio (Sprint commitment reliability): tỷ lệ giữa việc thực sự hoàn thành so với việc đã cam kết đầu Sprint. Cam kết 22 SP, làm xong 20 thì tỷ lệ ≈ 91%. Một đội ổn định thường dao động 80–110%.
- Velocity variance: độ dao động của velocity giữa các Sprint. Velocity 22, 23, 21 (ổn định) dễ dự báo hơn nhiều so với 10, 35, 18 (dù trung bình bằng nhau).
Nhóm 4 — People & health metrics (chỉ số sức khỏe đội)
Nhóm này dễ bị bỏ quên nhưng quyết định tính bền vững.
- Sprint Goal success rate: tỷ lệ Sprint đạt được Sprint Goal đã đề ra.
- Team happiness / morale: đo qua khảo sát nhanh cuối Retrospective (thang 1–5).
- Retrospective action completion: tỷ lệ hành động cải tiến từ Retro thực sự được làm xong.
Tình huống thực tế
Tình huống 1 — Velocity tăng vọt mà sếp lại lo lắng (startup giao đồ ăn, Hà Nội)
Một đội phát triển tại một startup giao đồ ăn ở Hà Nội báo cáo velocity tăng từ 25 SP lên 40 SP chỉ trong hai Sprint. Giám đốc sản phẩm vui mừng — cho đến khi anh nhìn vào escaped defects: số lỗi production tăng từ 3 lên 11 trong cùng kỳ. Cycle time thì giảm (tốt), nhưng % rework lại nhảy từ 8% lên 22%.
Diễn giải: đội đã "chạy nhanh" bằng cách cắt xén kiểm thử và bỏ qua Definition of Done. Velocity tăng là velocity ảo — họ giao nhiều story hơn nhưng một phần lớn quay lại dưới dạng lỗi và rework. Khi gộp throughput thật (đã trừ rework) thì giá trị giao thực tế gần như đứng yên.
Bài học: không bao giờ đọc một chỉ số đơn lẻ. Velocity phải luôn đi cặp với escaped defects và % rework. Một chỉ số tốc độ tăng mà chỉ số chất lượng xấu đi thường là tín hiệu nguy hiểm, không phải thành tích.
Tình huống 2 — Lead time 60 ngày trong khi cycle time chỉ 5 ngày (công ty SaaS B2B, Singapore/Việt Nam)
Một đội Scrum làm sản phẩm SaaS quản lý kho cho doanh nghiệp vừa, có văn phòng kỹ thuật ở TP.HCM. Khách hàng phàn nàn "tính năng nào cũng mất hàng tháng mới có". Đội rất ức chế vì họ tự thấy mình code nhanh.
Họ đo và phát hiện: cycle time trung bình chỉ 5 ngày — code rất nhanh thật. Nhưng lead time trung bình lên tới 60 ngày. Phần lớn thời gian (~55 ngày) là story nằm chờ trong backlog vì Product Owner ôm quá nhiều yêu cầu và không ưu tiên dứt khoát.
Diễn giải: nút thắt cổ chai (bottleneck) không nằm ở khâu phát triển mà ở khâu ra quyết định ưu tiên. Toàn bộ nỗ lực tối ưu tốc độ coding sẽ vô nghĩa vì nó chỉ chiếm 5/60 ngày.
Hành động: đội đặt giới hạn WIP (Work In Progress) cho backlog "Ready", buộc PO refinement đều đặn và chỉ giữ tối đa hai Sprint công việc sẵn sàng. Sau ba tháng, lead time giảm còn 22 ngày — dù cycle time không hề thay đổi.
Bài học: lead time và cycle time tách rời nhau sẽ chỉ thẳng vào nơi cần sửa. Nếu chỉ nhìn velocity, đội này sẽ mãi đổ lỗi cho nhau mà không thấy vấn đề thật nằm ở hàng đợi đầu vào.
Tình huống 3 — Dashboard 14 chỉ số và sự tê liệt (đội nội bộ ngân hàng, Việt Nam)
Quay lại anh Scrum Master với 14 chỉ số ở đầu bài. Đội thuộc khối công nghệ một ngân hàng. Mỗi Sprint Review, họ trình bày một dashboard kín màn hình: velocity, throughput, cycle time, lead time, code coverage, số commit, số dòng code, story age, bug count, burndown, burnup, capacity utilization, blocked time, và "team velocity vs department average".
Vấn đề: không ai biết hành động gì với 14 con số. Chỉ số "số dòng code" thậm chí phản tác dụng — vài lập trình viên bắt đầu viết code dài dòng hơn. "Velocity vs department average" tạo cuộc đua thổi phồng SP giữa các đội.
Hành động: chúng tôi cắt xuống còn 4 chỉ số: throughput, cycle time, escaped defects, và Sprint Goal success rate. Mỗi Retro, đội chỉ hỏi "Chỉ số nào xấu đi và tại sao?". Trong hai tháng, các cuộc Retro trở nên cụ thể, và việc cải tiến thực sự xảy ra.
Bài học: ít mà sâu thắng nhiều mà nông. Một bộ 3–5 chỉ số mà đội thực sự dùng để ra quyết định có giá trị gấp nhiều lần một dashboard hoành tráng không ai đọc. Và tuyệt đối tránh các chỉ số dễ bị thao túng như số dòng code hay số commit.
Hướng dẫn từng bước
Đây là quy trình thiết lập hệ thống metrics cho Scrum Team từ con số không:
- Xác định câu hỏi trước, chỉ số sau. Đừng bắt đầu bằng "đo gì". Bắt đầu bằng "đội/lãnh đạo cần trả lời câu hỏi gì?". Ví dụ: "Bao giờ tính năng X xong?" → chọn velocity + throughput. "Chất lượng có đang xuống không?" → chọn escaped defects + % rework.
- Chọn 3–5 chỉ số tối đa cho lần khởi đầu. Gợi ý bộ cân bằng: một chỉ số tốc độ (throughput hoặc velocity), một chỉ số dòng chảy (cycle time), một chỉ số chất lượng (escaped defects), một chỉ số dự báo (say/do ratio hoặc Sprint Goal success rate).
- Định nghĩa rõ ràng từng chỉ số. Cycle time tính từ trạng thái nào sang trạng thái nào? "Done" nghĩa là merge code hay là lên production? Cả đội phải thống nhất, viết vào Working Agreement, nếu không số liệu mỗi người hiểu một kiểu.
- Tự động hóa việc thu thập. Tận dụng công cụ backlog (Jira, Linear...) để xuất cycle time, throughput tự động. Thu thập thủ công sẽ chết yểu sau vài Sprint. Khảo sát happiness thì làm nhanh bằng một poll cuối Retro.
- Đặt baseline, đừng đặt target ngay. Thu thập 3–4 Sprint để biết "bình thường" của đội là bao nhiêu. Đặt mục tiêu cứng quá sớm sẽ khiến đội gaming số liệu.
- Đưa metrics vào Retrospective, không phải vào báo cáo cho sếp. Mỗi Retro, đội nhìn xu hướng (trend) và hỏi "Điều gì khiến chỉ số này thay đổi?". Đây là nơi metrics tạo ra giá trị thật.
- Rà soát lại bộ chỉ số mỗi quý. Khi đội trưởng thành, chỉ số phù hợp sẽ thay đổi. Bỏ chỉ số không còn tạo quyết định, thêm chỉ số mới khi có câu hỏi mới.
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng velocity để so sánh các đội. Velocity là đơn vị nội bộ của từng đội. So sánh velocity giữa các đội cũng vô nghĩa như so sánh "20 nghìn đồng" với "20 đô la" mà bỏ qua tỷ giá. Mẹo: muốn so sánh giữa các đội, dùng throughput, cycle time hoặc escaped defects — những chỉ số không phụ thuộc cách ước lượng SP.
Lỗi 2 — Biến metrics thành công cụ đánh giá cá nhân. Khoảnh khắc velocity gắn với KPI lương của developer, SP sẽ bị thổi phồng. Mẹo: tuyên bố rõ ràng metrics là của đội và phục vụ cải tiến, không bao giờ dùng để xếp hạng cá nhân.
Lỗi 3 — Đo quá nhiều. Dashboard 14 chỉ số = tê liệt quyết định. Mẹo: áp dụng quy tắc "nếu không hành động được dựa trên một chỉ số trong 3 Sprint liên tiếp, hãy bỏ nó đi".
Lỗi 4 — Đọc một con số đơn lẻ. Velocity tăng có thể là tin xấu nếu chất lượng giảm. Mẹo: luôn ghép cặp một chỉ số tốc độ với một chỉ số chất lượng để nhìn bức tranh thật.
Lỗi 5 — Nhìn một Sprint thay vì xu hướng. Một Sprint velocity thấp có thể chỉ vì nghỉ lễ hoặc một thành viên ốm. Mẹo: luôn đọc theo trend 3–6 Sprint, đừng phản ứng với một điểm dữ liệu lẻ.
Lỗi 6 — Chọn chỉ số dễ bị thao túng (vanity metrics). Số dòng code, số commit, số giờ làm... đều dễ gaming và không phản ánh giá trị. Mẹo: ưu tiên chỉ số gắn với kết quả giao hàng (throughput, escaped defects) thay vì hoạt động (số commit).
Một mẹo bao trùm: hãy nhớ định luật Goodhart — "khi một thước đo trở thành mục tiêu, nó không còn là một thước đo tốt". Dùng metrics như chiếc đèn pin soi đường để đội tự đi, không phải như chiếc roi.
Bài tập thực hành
- Tính các chỉ số cơ bản. Đội của bạn có dữ liệu 4 Sprint gần nhất: SP hoàn thành lần lượt 18, 24, 21, 27; số story đóng lần lượt 7, 9, 8, 10. Hãy tính velocity trung bình, throughput trung bình và độ dao động velocity (chênh lệch cao nhất – thấp nhất). Nhận xét đội này dễ hay khó dự báo.
- Phân biệt lead time và cycle time. Một story được tạo trong backlog ngày 1/6, được kéo vào "In Progress" ngày 20/6, và lên production ngày 25/6. Hãy tính lead time và cycle time. Nếu sếp muốn rút ngắn thời gian giao hàng, bạn sẽ khuyên tập trung tối ưu khâu nào? Vì sao?
- Thiết kế dashboard tối giản. Giả sử bạn là Scrum Master của một đội mới thành lập 6 tuần. Hãy chọn đúng 4 chỉ số (mỗi nhóm một chỉ số: tốc độ, dòng chảy, chất lượng, dự báo) và viết một câu cho mỗi chỉ số giải thích "chỉ số này giúp đội trả lời câu hỏi gì".
- Phát hiện vanity metric. Nhìn lại đội/dự án hiện tại của bạn (hoặc một dự án bạn từng tham gia). Liệt kê mọi con số đang được theo dõi, và đánh dấu chỉ số nào dễ bị thao túng hoặc không dẫn tới hành động nào. Đề xuất bỏ ít nhất một chỉ số.
Tóm tắt
Metrics & KPIs của Scrum Team xoay quanh bốn nhóm: process (velocity, throughput, cycle time, lead time), quality (escaped defects, rework), predictability (say/do ratio, velocity variance), và health (Sprint Goal success rate, morale). Quan trọng nhất:
- Velocity để dự báo nội bộ, không để so sánh giữa các đội.
- Cycle time đo độ mượt của khâu phát triển; lead time đo toàn bộ hành trình kể cả thời gian chờ trong backlog. Hai con số chênh nhau chỉ thẳng vào nút thắt cổ chai.
- Luôn đọc theo cặp (tốc độ + chất lượng) và theo xu hướng (3–6 Sprint), không đọc một con số lẻ.
- Chọn 3–5 chỉ số, định nghĩa rõ, tự động hóa thu thập, và đưa vào Retrospective để cải tiến — không dùng để kết tội cá nhân.
- Cảnh giác với định luật Goodhart và các vanity metrics dễ bị thao túng như số dòng code hay số commit.