Ban biên tập tóm tắt hai phía để mọi người cùng phản biện.
Lập luận cho việc ước lượng (point hoặc tương đối)
- Cuộc thảo luận khi ước lượng (ví dụ Planning Poker) làm lộ hiểu khác nhau về yêu cầu và rủi ro — giá trị nằm ở cuộc trao đổi nhiều hơn con số.
- Giúp Product Owner cân nhắc chi phí – giá trị khi xếp thứ tự backlog.
- Phù hợp khi kích thước hạng mục chênh lệch lớn.
Lập luận cho việc đếm hạng mục (thường gắn với phong trào #NoEstimates)
- Nếu các hạng mục được tách nhỏ tương đối đồng đều, số lượng hạng mục hoàn thành (throughput) dự báo khá tốt mà không tốn thời gian ước lượng.
- Tránh các tác dụng phụ của point: lạm phát điểm, so sánh đội, biến point thành chỉ tiêu.
- Kanban Guide dùng thông lượng và cycle time làm thước đo chính, không yêu cầu ước lượng.
Điều kiện để "không ước lượng" hoạt động (theo kinh nghiệm được nhiều người chia sẻ)
- Đội có kỹ năng tách story tốt, phần lớn hạng mục nhỏ (vài ngày).
- Có dữ liệu lịch sử đủ dài về throughput.
- Tổ chức chấp nhận dự báo theo xác suất (ví dụ mô phỏng Monte Carlo) thay vì một ngày cố định.
- Vẫn giữ cuộc trao đổi làm rõ yêu cầu — chỉ bỏ con số, không bỏ hội thoại.
Agile Alliance cũng lưu ý ước lượng tương đối chủ yếu là công cụ cho đội lập kế hoạch, không phải thước đo hiệu suất.
Mời các bạn chia sẻ số liệu thực tế nếu có: độ chính xác dự báo trước và sau khi đổi cách làm.
Nguồn: