Điểm câu chuyện hay ngày, hay cả hai?
Mọi người thường tranh luận về việc có nên sử dụng điểm câu chuyện hay giờ (hoặc ngày) trong việc ước lượng câu chuyện hay không. Một số người tin rằng chúng ta không cần tính toán điểm câu chuyện và tốc độ của đội nói chung. Dù các đội có thể có quan điểm khác nhau, nhưng phần lớn các dự án Agile vẫn thực hiện ước lượng câu chuyện và coi đó là một trong những công cụ rất hữu ích để hoàn thành dự án đúng tiến độ và trong ngân sách.
Bảng liên kết cho ước lượng câu chuyện
Trong Visual Paradigm, chúng tôi không coi ước lượng câu chuyện là một quá trình xung đột hay đàm phán, mà là một quá trình xây dựng đội nhóm giúp làm rõ và minh bạch công việc và khối lượng công việc cho mọi người trong đội. Công cụ câu chuyện người dùng trang bị cho đội bảng liên kết để tự động hóa quá trình ước lượng câu chuyện cùng với việc loại bỏ các spike. Hơn nữa, bảng liên kết trực quan hỗ trợ ước lượng theo thời gian thực với cả điểm câu chuyện và giờ câu chuyện cùng lúc. Khi bạn kéo một câu chuyện dọc theo bảng, cả điểm câu chuyện và giờ sẽ được hiển thị đồng thời trong khi câu chuyện vẫn đang di chuyển. Chỉ cần thả câu chuyện vào ô mà đội của bạn cảm thấy ước lượng là phù hợp.

Bảng liên kết tính toán như thế nào?
Để hiểu cách điểm câu chuyện và ngày được ước lượng tự động trong Bảng liên kết, chúng ta cần hiểu rằng các ô ngang đại diện cho nỗ lực công việc, tăng dần từ trái sang phải, và độ phức tạp trong phát triển câu chuyện (như công nghệ mới, lĩnh vực mới, v.v.) tăng dần từ trên xuống dưới.
Vì số ngày tối đa để phát triển một câu chuyện người dùng nên không vượt quá độ dài của sprint (nếu không thì câu chuyện người dùng quá lớn cần phải chia nhỏ, hoặc sprint được đặt quá ngắn cần kéo dài), do đó số ngày ở ô góc phải dưới cùng cũng phải bằng độ dài của sprint. Dựa trên giả định này, việc ước lượng câu chuyện có thể được tính toán tự động.

Mối liên kết giữa các câu chuyện người dùng cho mục đích ước lượng
Việc ước lượng một câu chuyện người dùng không bao giờ có thể chính xác 100% và thực tế không có phương pháp nào đạt được điều đó. Để cải thiện độ chính xác của ước lượng, chúng ta bắt đầu bằng việc xác định độ dài sprint (ví dụ, hai tuần hoặc 10 ngày làm việc) và tiến hành ước lượng một vài câu chuyện người dùng mà chúng ta cảm thấy thoải mái nhất về việc ước lượng (ví dụ, 5 ngày và mức độ chắc chắn ở mức trung bình). Trong trường hợp này, bạn sẽ đặt câu chuyện ở vị trí trung tâm theo chiều dọc (mức độ chắc chắn hoặc mức độ rủi ro) và theo chiều ngang (nỗ lực công việc bằng 5 ngày, hoặc bằng một nửa độ dài sprint, tức là 10 ngày). Sau đó, bạn có thể dùng nó làm điểm tham chiếu để ước lượng các câu chuyện người dùng khác. Hãy tự hỏi xem câu chuyện người dùng này có yêu cầu nhiều nỗ lực hơn hay ít hơn so với câu chuyện tham chiếu, và có mức độ không chắc chắn cao hơn hay thấp hơn không. Khi bạn đặt thêm một số câu chuyện người dùng lên Bảng liên kết, bạn có thể so sánh giữa nhiều câu chuyện để xác định xem việc điều chỉnh là hợp lý hay không, rồi điều chỉnh chúng cho công bằng. Quá trình này phần nào giống một nghệ thuật hơn là kỹ thuật. Hãy thực hiện và thảo luận trong cuộc họp đội thay vì đối đầu. Độ chính xác thường sẽ được cải thiện khi đội ngày càng trưởng thành.

Loại bỏ rủi ro bằng Spike dự án
Theo Từ điển Agile, định nghĩa của Spike là:
“Một nhiệm vụ nhằm trả lời một câu hỏi hoặc thu thập thông tin, thay vì sản xuất sản phẩm có thể giao được. Đôi khi một câu chuyện người dùng được tạo ra mà không thể ước lượng tốt cho đến khi đội phát triển thực hiện một số công việc thực tế để giải quyết một câu hỏi kỹ thuật hoặc một vấn đề thiết kế. Giải pháp là tạo ra một ‘spike’, là một công việc có mục đích cung cấp câu trả lời hoặc giải pháp.”
Khi ước lượng một câu chuyện người dùng, chúng ta không chỉ xem xét nỗ lực phát triển, mà còn phải tính đến các rủi ro và sự không chắc chắn liên quan. Đôi khi, một spike được tạo ra trước khi sprint chính thức bắt đầu để quản lý công việc cần thực hiện nhằm giúp ước lượng công bằng cho một số câu chuyện người dùng khác.