Ước Lượng Story Point: Làm Tròn Tăng & Theo Dải - MTHi The Class

Story Point nên được ước lượng được theo dải

Khi ước lượng kích thước user story đa số các agile team sử dụng một bộ số không liên tiếp. Ví dụ dãy các bội số của 2 (1, 2, 4, 8, 16,…), hoặc dãy số Fibonacci (1, 2, 3, 5, 8, 13, …). Không dùng dãy số liên tiếp sẽ giúp team tránh được việc phải cân nhắc chọn ví dụ 15 hay 16. Ước lượng đến độ chính xác từng đơn vị point kiểu như vậy là tốn thời gian, không có ý nghĩa thực tế và thậm chí là không thể.

Một câu hỏi tôi hay nhận được là “phải làm thế nào để chọn kích thước cho một user story nằm giữa 8 và 13 (hoặc giữa 3 với 5)?”. Một phần câu trả lời có thể có được nếu bạn nghĩ về dung tích các xô nước.

Giả sử bạn có 10 l nước, thì bạn sẽ chon xô dung tích bao nhiêu để chứa? Ở đây bạn có xô 8 l với xô 13 l để lựa chọn.

Tất nhiên phải chọn xô 13 l đúng không nào! Vì xô 8 l sẽ không chứa hết 10 l được và sẽ bị tràn nước ra ngoài.

Mở rộng qui tắc này, bạn sẽ kết luận rằng tất cả lượng nước trong khoảng 9 đến 13 l đều phải chọn xô dung tích 13 l để chứa. Khi lượng nước tăng lên đến 14 l bạn sẽ phải chọn xô lớn hơn nữa.

Đó chính là phương pháp chọn số story point cho các user story. Hãy coi các số trong dãy Fibonacci là các xô nước dung tích cố định. Mỗi giá trị cố định trong dãy sẽ áp cho tất cả các user story có kích thước nằm trong khoảng giá trị đó cho đến giá trị liền dưới nó.

Ví dụ khi áp dụng Planing Poker nhiều team sửa đổi dãy Fibonacci thành dãy 1, 2, 3, 5, 8, 13, 20, 40 and 100 để sử dụng cho sizing. Quân bài 13-point được gán cho các user story mà team cho rằng có size lớn hơn 8 và không vượt quá 13.

Bạn có thể thấy thực chất các quân bài với 1 giá trị point đại diện cho một dải size của các user story. Hệt như là dung tích các xô nước. Và mẹo ở đây là việc team chọn cho đúng xô nước phù hợp!

Chọn đúng xô chứa cho từng item của Product Backlog

Để có thể ước lượng và lập kế hoạch tốt team cần hiểu rằng nhiệm vụ của họ không phải là gán một con số ước lượng cho một item. Nhiệm vụ của họ thực chất là chọn cho mỗi item của Product Backlog một dung tích chứa phù hợp. Mặc dầu trong cả hai trường hợp về hình thức người ta đều lấy bút để viết ra một con số trên story card. Nhưng nhớ rằng mục đích của bạn là chọn đúng dung tích vừa đủ lớn để chứa hết user story đó!

Khi ước lượng, yêu cầu team vẽ ra bức tranh gồm một dãy các xô nước  có nhãn là 1, 2, 3, 5, 8, 13 … (hay là bất kỳ dãy số nào khác mà team đã chọn). Và hãy yêu cầu team tự bỏ các story card vào đúng xô nước phù hợp.

Bằng cách này bạn giúp team tránh được suy nghĩ rằng ước lượng cần phải chính xác. Các item của Product Backlog đơn giản chỉ cần được bỏ vào đúng xô nước mà thôi!

Vì sao bạn nên làm tròn tăng một số ước lượng?

Bạn lo ngại rằng làm tròn tăng ước lượng dễ dẫn đến “lạm phát” hoặc dự phòng thừa thãi cho lịch trình dự án. Tôi sẽ giải thích để bạn hiểu vì sao làm tròn thường không dẫn đến hậu quả này.

Chẳng hạn ví dụ đã nêu trên, một item bạn cho rằng size 10 point và vì bạn dùng dãy Fibonacci làm các xô chứa, bạn sẽ chọn cho item này xô chứa 13-point.

Tiếp theo giả sử với 13 point item này quá to không thể đưa vào trong 1 sprint. Thế là team sẽ chia nhỏ item ra thành các story nhỏ. Có thể là thành 3 story nhỏ hơn và có size lần lượt là 5, 5 và 2 point.

Để ý rằng tổng số point của 3 story con là 12. Mặc dầu nhỏ hơn giá trị 13 nhưng so với giá trị 10 point ban đầu thì tổng này lớn hơn 2.

Bằng cách chọn size xô chứa lớn hơn để dùng làm ước lượng cho size của các story bạn đã cải thiện được khả năng dự báo chính xác hơn về deadline hoàn thành bàn giao của dự án.

Giả sử bạn làm tròn giảm, thay vì làm tròn tăng như đã nêu, tức là chọn 8-point cho story kể trên, thì dự án có thể đã bị trễ tương đương 4 point (12 – 8 = 4). Hoặc bạn dùng size 10-point để ước lượng “chính xác” thay vì dùng xô chứa 13-point, thì dự án có thể đã bị trễ tương đương 2 point (12 – 10 = 2)

Bằng cách ước lượng size các user story theo các giá trị kiểu xô chứa và làm tròn tăng như đã giả thích ở trên bạn đã tăng xác xuất hoàn thành dự án đúng hạn.  

Có thể trên thực tế hóa ra cái story 10 point kể trên chỉ còn đáng 8 point thì sao? Đúng là có thể như vậy, cũng như có thể thực tế nó lên đến 14, 15 point  hay bất cứ giá trị nào khác.

Phương pháp ước lượng làm tròn tăng và theo dải (range estimation) thực ra là sự phản ánh bản chất không chắc chắn của ước lượng và giúp cho bạn tạo ra được kế hoạch dự án có thời hạn bàn giao/release chính xác hơn (cam kết chắc chắn hơn).

Theo Mike Cohn

Story Point Estimates Are Best Thought of as Ranges

• #ProjectManagement
• #PMP
• #PMPExam
• #HoChiMinh
• #QuanLyDuAn
• #TemplatesForProjectManagement
• #QuiTrinhLapKeHoachQuanLyDuAn