Velocity
Số điểm mà một team hoàn thành trong một sprint, lấy trung bình vài sprint để dự báo dung lượng sắp tới. Chỉ có nghĩa trong nội bộ một team, không đem so giữa các team.
Định nghĩa
Cuối sprint, cộng story point của những item đã đạt Definition of Done. Được bao nhiêu thì đó là velocity của sprint ấy. Công thức chỉ có vậy, phần rắc rối nằm hết ở cách người ta dùng con số này.
Item làm dở dang tính bao nhiêu điểm? Không điểm nào. Không có chuyện tính nửa điểm cho story hoàn thành 80%. Nghe khắc nghiệt, nhưng đây chính là thứ giúp velocity phản ánh đúng khả năng giao hàng thật.
Velocity không có trong Scrum Guide. Nó là công cụ dự báo do team tự dùng cho chính mình, tương tự cách bạn nhìn quãng đường trung bình để đoán giờ về nhà.
Dùng đúng thì dùng thế nào
Cần ít nhất 3 sprint mới có con số đáng nhìn, và tốt nhất là 5 sprint với đội hình ổn định. Team vừa đổi người, đổi công nghệ, hay đổi thang điểm thì đếm lại từ đầu.
Dùng dải thay vì một số. Lấy 5 sprint gần nhất, bỏ giá trị cao nhất và thấp nhất, còn lại lấy khoảng. Ví dụ team chạy 34, 41, 38, 52, 29 thì nói "khoảng 34 đến 41 điểm mỗi sprint" chính xác hơn nhiều so với "trung bình 38,8".
Dự báo thô cho roadmap. Còn 240 điểm trong backlog, velocity 34 đến 41, vậy cần khoảng 6 đến 8 sprint, tức 3 đến 4 tháng với sprint 2 tuần. Đưa con số dạng khoảng cho stakeholder, kèm điều kiện: backlog không phình thêm.
Nhìn xu hướng, không nhìn từng điểm. Velocity tụt hai sprint liền là tín hiệu đáng hỏi. Tụt một sprint có thể chỉ vì lễ Tết hoặc một người nghỉ ốm.
| Mục đích | Velocity dùng được không |
|---|---|
| Dự báo còn mấy sprint nữa xong backlog | Được, ở dạng khoảng |
| Chọn lấy bao nhiêu item vào sprint | Được, làm mốc tham khảo |
| So sánh hai team với nhau | Không, thang điểm khác nhau |
| Làm KPI hay đánh giá nhân sự | Không, team sẽ tự thổi số |
Chỗ con số này bị bẻ cong
Velocity là chỉ số bị bóp méo nhiều nhất trong Agile, và cơ chế bóp méo rất đơn giản: điểm số do chính team đặt ra. Khi bạn lấy một con số do người bị đo tự tạo ra rồi đem đo chính họ, kết quả gần như chắc chắn.
Vài kiểu thường gặp ở thị trường Việt Nam:
- Đưa velocity vào KPI quý. Team lập tức chấm điểm cao lên. Sprint sau velocity tăng 20%, sếp vui, sản phẩm vẫn giao chừng đó việc. Hiện tượng này có tên là point inflation.
- Lập bảng so sánh velocity giữa các team. Thang điểm mỗi team hình thành từ story mốc riêng, nên so sánh này vô nghĩa về mặt thống kê. Cái nó tạo ra chỉ là sự đối phó.
- Ép cam kết bằng velocity cao nhất từng đạt. Sprint có một lần bùng lên 52 điểm, từ đó 52 thành chuẩn. Team cắt bớt test và review để đạt, nợ kỹ thuật dồn lại, ba tháng sau velocity rơi tự do.
- Dùng velocity để đánh giá cá nhân. Cái này thì hỏng theo kiểu khác: hạ tầng, test tự động, dọn nợ kỹ thuật — toàn việc không sinh điểm — sẽ nằm đó mốc meo. Ai dại gì nhận.
Nếu quản lý cần một chỉ số để theo dõi, hãy đề xuất thứ khác: số item giao được mỗi sprint, cycle time, số bug production, mức độ hoàn thành Sprint Goal. Những chỉ số này khó bóp méo hơn, và khi chúng xấu đi thì bạn biết ngay phải đi hỏi ai.
Ví dụ thực tế
Team 7 người làm hệ thống quản lý hợp đồng cho một công ty bảo hiểm. Velocity 6 sprint đầu: 28, 35, 33, 38, 36, 40. Ổn định dần, dự báo tốt.
Sprint 7, giám đốc công nghệ đưa velocity vào báo cáo tháng và đặt mục tiêu 45. Sprint 7 đạt 46, sprint 8 đạt 49. Cùng lúc đó, số bug tìm thấy ở môi trường staging tăng từ trung bình 6 lên 17 mỗi sprint, và Sprint Goal trượt cả hai sprint.
Nhìn kỹ mới thấy team không làm nhanh hơn. Họ chấm 5 điểm cho những story trước đây chấm 3, và bỏ bớt phần kiểm thử chéo. Khi Scrum Master đưa số bug ra ở retro, mọi người mới nói thật. Chỉ số quay về dùng nội bộ, và mục tiêu theo dõi đổi sang tỉ lệ đạt Sprint Goal.
Câu hay bị hỏi phỏng vấn
"Velocity của team giảm ba sprint liên tiếp, bạn làm gì?" Đừng vội trả lời là sẽ tăng tốc. Hỏi trước đã: đội hình có đổi không, có nợ kỹ thuật đang ăn thời gian không, có bao nhiêu việc chen ngang từ production, thang điểm có bị đổi không. Velocity là triệu chứng, và triệu chứng thì không chữa được bằng cách yêu cầu nó biến mất.
