Câu trả lời được chấp nhận
"Agile thì không biết trước" là câu trả lời sai. Agile không hứa một ngày chắc chắn, nhưng có dữ liệu thực tế để đưa ra khoảng dự báo và cập nhật nó sau mỗi sprint — thường đáng tin hơn kế hoạch ước lượng một lần từ đầu.
Cách làm cơ bản
- Lấy velocity của các sprint gần nhất (bỏ sprint bất thường nếu có lý do rõ, như nghỉ lễ dài).
- Xác định velocity thấp, trung bình, cao — ví dụ (giả định) 5 sprint: 24, 30, 28, 35, 31 → thấp 24, cao 35.
- Khối lượng còn lại 300 điểm → 9 sprint (300/35, làm tròn lên) đến 13 sprint (300/24).
- Quy ra ngày lịch, trình bày dạng khoảng: "Với phạm vi hiện tại, khả năng cao hoàn thành trong khoảng tuần X đến tuần Y".
Agile Alliance nhấn mạnh velocity là phép đo sau sự việc, giúp lập kế hoạch nhưng không phải ngân sách hay lời hứa. Vì vậy, không đặt chỉ tiêu velocity để "kéo ngày sớm hơn".
Trình bày với lãnh đạo
- Dùng biểu đồ burnup với đường phạm vi và vùng dự báo (hai đường xu hướng thấp/cao).
- Đưa ra lựa chọn thay vì một con số: "Nếu cần ngày cố định là tuần X, phạm vi khả thi là phần này của backlog; phần còn lại vào bản sau."
- Khi đã có đủ dữ liệu, có thể dùng mô phỏng Monte Carlo trên lịch sử velocity/throughput để nói theo xác suất (ví dụ 85%).
Cập nhật khi phạm vi đổi: sau mỗi Sprint Review, cập nhật khối lượng còn lại và velocity mới; dự báo thu hẹp dần theo thời gian. Mọi thay đổi phạm vi lớn nên đi kèm dự báo mới để bên liên quan thấy đánh đổi.
Lưu ý: chỉ dùng velocity của chính đội đó và cùng hệ điểm; đổi thành viên lớn hoặc đổi cách ước lượng thì cần vài sprint để có dữ liệu mới.
Nguồn: