Chỉ số Agile — đo dòng chảy công việc

EVM hợp với dự án có khối lượng định nghĩa trước (xây dựng, hạ tầng). Nhưng dự án chuyển đổi số, phần mềm, cải tiến quy trình — nơi phạm vi tiến hóa theo phản hồi — cần bộ đo khác: đo dòng chảy công việc thay vì % kế hoạch.

Sáu chỉ số cốt lõi

Chỉ số	Định nghĩa	Trả lời
Velocity	Khối lượng hoàn thành mỗi chu kỳ (sprint)	Đội giao được bao nhiêu mỗi 2 tuần?
Burndown	Việc còn lại theo thời gian	Kịp mốc không? Đường thực tế so với đường lý tưởng
Burnup	Việc đã xong + tổng phạm vi theo thời gian	Tiến triển thật + phạm vi có phình không?
Cycle time	Từ lúc bắt đầu làm đến lúc xong	Một việc vào tay đội mất bao lâu?
Lead time	Từ lúc yêu cầu đến lúc giao	Người dùng chờ bao lâu từ khi đề xuất?
Throughput · WIP (Work in Progress)	Số việc xong mỗi kỳ · số việc đang dở	Dòng chảy nhanh chậm · có nghẽn không?

Quan hệ đáng nhớ (Little’s Law): Cycle time ≈ WIP / Throughput — muốn giao nhanh hơn, cách chắc nhất thường là giảm số việc làm dở cùng lúc, không phải làm thêm giờ. Đội 20 việc dở giao chậm hơn đội 6 việc dở, cùng năng lực.

Đọc burndown / burnup thế nào

• Burndown thực tế nằm trên đường lý tưởng kéo dài → sẽ trễ: hoặc bớt phạm vi, hoặc lùi mốc — quyết định sớm khi còn rẻ.
• Burndown đi ngang dù đội vẫn bận → việc “gần xong” chất đống (WIP cao), hoặc phạm vi bị nhét thêm ngầm — nhìn burnup sẽ thấy đường tổng phạm vi dốc lên.
• Lead time tách khỏi cycle time → việc xếp hàng chờ quá lâu trước khi được làm: vấn đề ở ưu tiên hóa, không phải năng suất đội.

Giá trị với người điều hành

• Dự báo bằng dữ liệu đội thật: velocity trung bình 3 sprint gần nhất × số sprint còn lại = phần việc sẽ xong — thay cho cam kết cảm tính.
• Phát hiện nghẽn bằng WIP: WIP tăng mà throughput không tăng là tín hiệu tắc (chờ phê duyệt, chờ dữ liệu, chờ người duy nhất biết việc).
• Đúng kỳ vọng với dự án khám phá: phạm vi tiến hóa là đặc tính, không phải lỗi — burnup cho thấy điều đó minh bạch với chủ đầu tư.

Các sai lầm dễ mắc phải

1. So velocity giữa các đội — điểm ước lượng là thước riêng từng đội; so chéo chỉ tạo ra lạm phát điểm.
2. Biến velocity thành KPI thưởng phạt — đội sẽ tối ưu con số thay vì giá trị; velocity chỉ để dự báo.
3. Nhồi WIP để “ai cũng bận” — bận không đồng nghĩa chảy; WIP cao kéo dài cycle time của mọi việc.
4. Chỉ nhìn burndown, bỏ burnup — burndown đẹp có thể do âm thầm cắt phạm vi; burnup lộ điều đó ngay.

Áp dụng trong thực tế

Trong dự án triển khai của BSD

Đây là bộ chỉ số BSD dùng chính trong các dự án triển khai ERP/CRM/dữ liệu cho khách hàng: backlog yêu cầu theo phân hệ, chu kỳ giao 2 tuần, burnup công khai với chủ đầu tư — phạm vi phát sinh nhìn thấy được và quyết định đánh đổi diễn ra sớm. Với công việc vận hành dạng dòng chảy (ticket hỗ trợ, phản ánh cư dân, yêu cầu sửa chữa trong Parkone bảo trì), cycle time / throughput / WIP áp dụng nguyên vẹn — và là nền của cam kết SLA trên cổng hỗ trợ BSD.

Quay lại bức tranh chung: Tổng quan & bảng công thức →