Chúng ta đã nghe nhiều lời giải thích khác nhau về ý nghĩa của Story Point và cách sử dụng. Hầu hết mọi nhóm Scrum đều sử dụng phương pháp này, nhưng không phải cũng sử dụng hiệu quả trong mọi ngữ cảnh. Bài viết này nhằm mục đích loại bỏ một số bí ẩn xung quanh Story Point.
- Chuyển đổi story point sang giờ: Bằng cách chuyển đổi story point sang giờ/ngày/tuần, nhóm sẽ bắt đầu làm việc và phải mạo hiểm đưa ra cam kết thời gian hoàn thành chính xác. Giả sử story point được ước lượng có phạm vi thời gian từ 10 – 20 giờ, nhưng khi ước lượng theo giờ, nhóm phải đưa ra một con số chính xác như 15 giờ, từ đó sẽ dẫn đến sự sai lệch, dẫn đến khó đạt được cam kết hơn khi bạn làm việc theo giờ chính xác. Hoặc khi bạn báo cáo với lãnh đạo rằng User Story này đã hoàn thành 95% số points gán cho story trong 2 ngày, như vậy chỉ cón 5% là nghiệm thu deverable cho story này. Tuy nhiên 5% này lại là phần phức tạp và khó nhất, bạn mất tới 4 ngày để hoàn thành.
- Đưa ra story point trung bình: Trong Planning Poker, một nửa thành viên trong nhóm ước lượng một product backlog item là 3 story point và nửa còn lại ước tính 5 story point. Nhóm giải quyết bằng cách đặt 4 story point làm con số ước lượng. Nhóm không nên làm điều này vì nhóm đang thỏa hiệp với sự cung cấp sai về độ chính xác. Tốt nhất là nhóm nên có một cuộc thảo luận để hiểu rõ hơn thay vì lấy giá trị trung bình.
- Điều chỉnh ước lượng Story Point của các user story trong Sprint: Khi nhóm bắt đầu giải quyết một vấn đề, nhóm không nên điều chỉnh ước lượng story point ngay cả khi ước lượng của họ không chính xác. Việc ước lượng đôi khi bị sai lệch là điều bình thường, nên nhóm không nên điều chỉnh mà hãy lưu lại thông tin này, để làm cơ sở cho việc xác định story point ở những lần sau chính xác hơn.
- Ước lượng Story point cho những vấn đề chưa hoàn thành một lần nữa: Khi chuyển một product backlog item chưa hoàn thành sang Sprint tiếp theo, không cần thiết phải ước lượng lại. Ước lượng có thể không chính xác, nhưng đó không phải là vấn đề. Nhờ Sprint Planning, nhóm sẽ biết tất cả các nhiệm vụ (task) cần thiết để hoàn thành user story. Ước lượng của các nhiệm vụ này là theo giờ. Vì vậy, Sprint tiếp theo, nhóm sẽ biết cần bao nhiêu thời gian để hoàn thành product backlog item này.
- Điều chỉnh ước lượng Story Point dựa vào người làm: User story có thể là 3 story point đối với thành viên nhiều kinh nghiệm, nhưng 8 story point đối với thành viên mới. Đây là cách làm không đúng. Chúng ta không nên điều chỉnh story point vì một người cụ thể sẽ thực hiện công việc. Vì story point chỉ dựa vào độ lớn, độ phức tạp, độ khó của user story.
- Tuân theo ý kiến của các chuyên gia trong nhóm: Khi thực hiện Planning Poker, có rủi ro là nhóm sẽ tuân theo ý kiến của các chuyên gia mà không phải là sự kết hợp từ phía mỗi thành viên. Nhóm thường giải quyết công việc bằng cách để chuyên gia trình bày chi tiết về công việc. Sau đó, để phần còn lại của nhóm ước lượng mà không cần các chuyên gia. Chúng ta cần nhớ rằng ước lượng story point là sự nỗ lực của cả nhóm không phải của riêng bất kỳ thành viên nào.
- Không thảo luận lại các vấn đề không chính xác về việc ước lượng story point trong Sprint Retrospective: Thỉnh thoảng, nhóm xác định được những vấn đề rõ ràng là ước lượng story points đã hoàn toàn sai lệch. Điều quan trọng là phải thảo luận về những vấn đề này và cố gắng học hỏi, cải thiện, để những ước lượng trong tương lai chính xác hơn.
