Lập kế hoạch Sprint định hướng theo tốc độ (velocity-driven)

Có hai phương pháp phổ biến để lập kế hoạch cho sprints : Velocity-driven và commitment-driven. Hãy bắt đầu bằng lập kế hoạch sprint theo velocity-driven vì nó rất dễ để mô tả. Lập kế hoạch theo velocity-driven dựa trên một tiền đề rằng khối lượng công việc mà nhóm có thể làm trong sprint sắp tới sẽ tương đương với những gì nhóm làm được trong các sprint trước. Đây là một tiền đề có giá trị.

Đương nhiên, nó giả định rằng mọi thứ như kích thước nhóm, nhóm làm việc tương tự từ sprint này sang sprint khác, độ dài sprint...cố định không đổi. Mỗi giả định này nói chung là hợp lệ và những vi phạm có thể dễ dàng được xác định, ví dụ : độ dài sprint chuyển từ 10 xuống 9 ngày làm việc do ngày nghỉ lễ đã được nhóm biết từ trước.

Các bước lập kế hoạch theo velocity-driven:

1. Xác định velocity trung bình của nhóm trong lịch sử
2. Chọn số lượng product backlog item tương đương với velocity đã được xác định. CÓ một vài team sẽ dùng lại ở step này.
3. Xác định các tasks cần làm để hoàn thành các userstories đã chọn và đánh giá xem khối lượng công việc như vậy có phù hợp không
4. Estimate các tasks và xem khối lượng công việc có tương đương với các sprint trước đó không

1. Xác định Velocity trung bình của nhóm

Bước đầu tiên trong việc lập kế hoạch theo velocity-driven là xác định velocity trung bình của nhóm. Một số nhóm agile thích lấy theo velocity gần nhất với logic suy luận rằng chỉ số của sprint gần nhất là tốt nhất để đánh giá khối lượng công việc có thể hoàn thành trong sprint sắp tới. Mặc dù điều đó là đúng nhưng nên lấy theo trung bình của quãng thời gian dài hơn nếu như có dữ liệu lịch sử. Một số chuyên gia thích lấy mức trung bình của 8 sprints gần nhất. Để dự đoán về khả năng của sprint tương lai, không cần phải lấy trung bình của 10 năm trước khi mà velocity của nhóm thời điểm đó không liên quan tới velocity của nhóm trong hiện tại. Tuy nhiên, nếu có dữ liệu thì lấy trung bình của một số sprints gần nhất sẽ chính xác hơn so với chỉ một sprint gần nhất.

2. Lựa chọn sprint backlog items

Sau khi đã xác định velocity trung bình cho sprint sắp tới, nhóm agile sẽ lựa chọn các sprint backlogs items từ trên xuống theo thứ tự ưu tiên được xác định bởi product owner, nhóm sẽ lựa chọn các items có tổng tối đa bằng với velocity trung bình.

3. Xác định các task (tùy chọn)

Phần lớn các nhóm agile yêu thích phương pháp lập kế hoạch sprint theo velocity-driven nhận thấy rằng việc lập kế hoạch cho 1 sprint trong vài giây là không đủ hiệu quả. Và phần lớn trong số đó sẽ thực hiện bước thứ 3 là xác định các task cần được thực hiện để có thể đạt được mục đích của sprint Để làm điều đó, các thành viên trong nhóm sẽ thảo luận về mỗi product backlog item đã được lựa chọn cho sprint và cố gắng xác định các bước chính để có thể hoàn thành product backlog item.Nhóm không thể nghĩ về mọi thứ, thay vào đó nhóm cố gắng để nghĩ về mọi thứ họ có thể. Sau khi đã xác định được các task tối cần thiết, các thành viên trong nhóm đánh giá lại các product backlog items đã được lựa chọn cùng những task để hoàn thành chúng và xác định xem liệu kế hoạch sprint đã đầy đủ. Họ có thể xác định rằng kế hoạch này là quá nhiều hoặc quá ít việc và có thể quyết định thêm hay bỏ bớt các product backlog items. Hầu hết các nhóm agile sẽ dừng lại ở đây, nhưng có một số nhóm sẽ thực hiện bước cuối cùng :

4. Estimate các task

Sau khi đã có danh sách chi tiết các task, một số team tiến hành estimate các task theo số giờ cần để hoàn thành task nhắm giúp team xác định rõ hơn khối lượng công việc cho sprint sắp tới đã phù hợp chưa. Tới đây thì team đã có danh sách các task và thời gian cần thiết để hoàn thành các task đó, do đó kế hoạch sprint đã đủ chi tiết để có thể bắt đầu sprint mới.