Nhưng đừng lo ngại!Có những tài nguyên sẽ trợ giúp bạn trong việc ước tính các story.
Trong một bài viết hay của Nicole Rauch, chúng tôi mới tìm ra gần đây, cô ấy cho rằng khi ước tính một story bạn cần đưa thêm vào bản miêu tả một vài vấn đề sau:
- Độ phức tạp:Xem xét kích cỡ của story.
- Rủi ro:Xem xét những hạn chế về kinh nghiệm của nhóm với việc phát triển story này.
- Thực hiện:Xem xét những yếu tố liên quan tới việc thực thi.
- Triển khai:Xem xét các yêu cầu của việc triển khai.
- Các phụ thuộc:Xem xét các vấn đề ngoài nề khác.
Chúng tôi bổ sung thêm rằng các nhà phát triển nên bắt đầu (ngoài giờ) xây dựng một đường cơ sở (baseline) cho kích cỡ ước tính của các story.Sử dụng một số ví dụ về các story trước đây để giúp các nhà phát triển hiểu rõ hơn về kích cỡ tương đối.Hãy đặt các câu hỏi như:“Story này như thế nào so với story X mà chúng ta đã ước tính trước đây?Lớn hơn hay nhỏ hơn?”
Bây giờ, câu hỏi thực sự là bạn sẽ sử dụng điểm (point) hay giờ (hour) cho việc ước tính.Mike Cohn khuyên sử dụng điểm cho Product Backlog, và giờ cho hạng mục công việc (task).
Tóm lại là gì?Ước tính linh hoạt là một nghệ thuật, nó sẽ tốt dần lên qua thời gian.Khi nhóm và các nhà phát triển của bạn trưởng thành, một đường cơ sở vững chắc cho việc ước tính công việc có thể tạo ra một nhịp làm việc nhất quán hoặc vận tốc để dự toán trong khoảng thời gian dài, nhưng lại không tốt cho việc ước tính ngắn hạn.
Tìm đọc thêm:
- Trò chơi Ước tính Linh hoạt 2.0
- Manoj Vadakkan nói chuyện về các bước nhỏ trong việc mang lại ước tính Linh hoạt tốt hơn qua thời gian.
- Scott Ambler giới thiệu về User Story.Một trong những bài viết hay nhất.
- Dưới đây là bài thuyết trình trong hội thảo về Ước tính Linh hoạt và Lập kế hoạch với User Story của Peter Saddington.
{Flash=http://d1.scribdassets.com/ScribdViewer.swf?document_id=50824197&access_key=key-yonpp5ke718fr6fl92&page=1&viewMode=list|width=550|height=455}
Nguồn: agilescout.com