Ước tính tốt giúp Product Owner tối ưu hóa hiệu quả. Đó là lý do tại sao nó rất quan trọng. 

Ước tính là rất khó. Đối với các Developers, đó là một trong những khía cạnh khó nhất của công việc. Họ phải tính đến một loạt các yếu tố giúp Product Owner đưa ra quyết định ảnh hưởng đến toàn bộ nhóm và doanh nghiệp. Với tất cả những điều đó, không có gì ngạc nhiên khi tất cả mọi người từ Developers đến quản lý cấp trên đều có xu hướng khiến các Developer phải chắn chắn. Nhưng đó là một sai lầm, ước tính nhanh chỉ là ước tính, không phải hứa hẹn.

Không nên có yêu cầu làm việc vào cuối tuần để bù đắp cho việc ước lượng thấp công việc. Chúng ta hãy xem xét một số cách để ước tính nhanh, chính xác nhất có thể.

Story points và ước tính

Ước tính tốt giúp Product Owner tối ưu hóa hiệu quả. Đó là lý do tại sao nó rất quan trọng. 

Ước tính là rất khó. Đối với các Developers, đó là một trong những khía cạnh khó nhất của công việc. Họ phải tính đến một loạt các yếu tố giúp Product Owner đưa ra quyết định ảnh hưởng đến toàn bộ nhóm và doanh nghiệp. Với tất cả những điều đó, không có gì ngạc nhiên khi tất cả mọi người từ Developers đến quản lý cấp trên đều có xu hướng khiến các Developer phải chắn chắn. Nhưng đó là một sai lầm, ước tính nhanh chỉ là ước tính, không phải hứa hẹn.

Không nên có yêu cầu làm việc vào cuối tuần để bù đắp cho việc ước lượng thấp công việc. Chúng ta hãy xem xét một số cách để ước tính nhanh, chính xác nhất có thể.

Cộng tác với Product owner

Trong Agile, PO có nhiệm vụ sắp xếp ưu tiên công việc. PO nắm bắt được các yêu cầu nhưng họ không phải lúc nào cũng hiểu chi tiết về việc triển khai. Vì vậy, ước tính tốt có thể cung cấp cho PO cái nhìn sâu sắc về mức độ nỗ lực cho từng hạng mục công việc, sau đó đưa trở lại đánh giá của họ về mức độ ưu tiên tương đối của từng hạng mục.

Ước lượng theo Agile là một hoạt động nhóm

Sự tham gia của tất cả mọi người (Developers, Designers, Tester, Operator …) trong nhóm là chìa khóa. Mỗi thành viên trong nhóm mang đến một góc nhìn khác nhau về sản phẩm và công việc cần thiết để truyền tải câu chuyện của người dùng. Ví dụ: nếu PO muốn làm điều gì đó có vẻ đơn giản, như hỗ trợ trình duyệt web mới, thì Developers cần phải cân nhắc vì kinh nghiệm của họ đã dạy cho họ biết những nguy cơ tiềm ẩn.

Tương tự như vậy, những thay đổi trong thiết kế không chỉ yêu cầu đầu vào của nhóm thiết kế mà còn cả Developers. Tuy nhiên, nếu để người ngoài nhóm sản phẩm ước tính thì sẽ tạo ra các ước tính chất lượng thấp hơn, làm giảm tinh thần vì những người đóng góp chính không cảm thấy được bao gồm và làm ảnh hưởng đến chất lượng của phần mềm. Đó là một con đường thất bại nhanh chóng!

Story points vs. hours

Các nhóm phần mềm truyền thống đưa ra các ước tính theo định dạng thời gian: ngày, tuần, tháng. Tuy nhiên, nhiều đội Agile đã chuyển sang các Story points. Story points là đơn vị đo lường để thể hiện ước tính về nỗ lực tổng thể cần thiết để thực hiện đầy đủ một Backlog items hoặc bất kỳ phần công việc nào khác. Các nhóm chỉ định các Story points liên quan đến độ phức tạp của công việc, khối lượng công việc và rủi ro hoặc sự không chắc chắn. Theo thời gian, điều này giúp các nhóm hiểu được họ có thể đạt được bao nhiêu points trong một khoảng thời gian. Story points thưởng cho các thành viên trong nhóm giải quyết vấn đề dựa trên độ khó chứ không phải thời gian. Điều này giúp các thành viên trong nhóm tập trung vào giá trị của công việc, không tốn thời gian.

Thật không may, các Story points thường bị sử dụng sai. Story points trở nên sai lầm khi chúng được sử dụng để đánh giá mọi người, chỉ định thời gian và tài nguyên chi tiết và khi chúng bị nhầm lẫn với một thước đo năng suất. Thay vào đó, các nhóm nên sử dụng các Story points để hiểu quy mô của công việc và mức độ ưu tiên của công việc.

Retrospectives là thời gian để nhóm kết hợp những hiểu biết sâu sắc từ các Sprints trước đây – bao gồm cả độ chính xác của các ước tính của họ. Giống như mọi thứ khác trong agile, ước tính là một thực hành. Bạn sẽ ngày càng tốt hơn theo thời gian.