Scrum ước tính lại câu chuyện

Mỗi ngày, sau khi đứng lên , nhóm của tôi và tôi cập nhật các ước tính của chúng tôi cho từng câu chuyện. Tôi có cảm giác rằng có điều gì đó không ổn với cách chúng tôi làm điều đó, vì vậy tôi cần sự giúp đỡ của bạn.

Đây là cách chúng tôi làm:

Câu chuyện Ước tính: 24 giờ (8 giờ mỗi ngày - chúng tôi sử dụng "ngày lý tưởng" làm thước đo)

• Ngày N: nhà phát triển bắt đầu làm việc trên Story A vào buổi sáng (8 giờ hoàn thành công việc vào cuối ngày)
• Ngày N + 1: Ước tính lại Câu chuyện = 16 giờ (một ngày làm việc được lấy ra từ Câu chuyện A, từ ngày N)
• Ngày N + 2: Ước tính lại Câu chuyện A = 8 giờ (một ngày làm việc được đưa ra khỏi Câu chuyện A, từ ngày N + 1)
• Ngày N + 3: Câu chuyện A nên được thực hiện ngay bây giờ. Nhưng nó không phải là. Nhà phát triển cho rằng sẽ mất thêm 3 giờ để hoàn thành. Chúng tôi cập nhật những câu chuyện trên các tấm bảng và burndown cho phù hợp.
• Ngày N + 4: Câu chuyện A mất cả ngày để kết thúc thay vì chỉ 3 giờ! Bây giờ đã xong. Sự khác biệt, 5 giờ, hoàn toàn không được tính trong kế hoạch của chúng tôi.

Làm thế nào chúng ta nên ước tính lại hàng ngày câu chuyện của chúng tôi?

Sự khác biệt, 5h, hoàn toàn không được tính trong kế hoạch của chúng tôi.

Có, nó được hạch toán ngầm vì các nhiệm vụ sau bị trì hoãn. Nếu có một biểu đồ phát sinh chỉ dành cho nhà phát triển đó, bạn sẽ nhận thấy rằng đường cong vẫn "phẳng" trong một ngày trong khi nó sẽ đi xuống nếu nhà phát triển đã hoàn thành đủ sớm để thực hiện một nhiệm vụ khác.

Không có gì sai với cách bạn ước tính lại trong cuộc họp hàng ngày, ước tính lại là về việc chúng ta có thể làm cho nó kết thúc nước rút hơn là theo dõi độ trễ chính xác của từng nhiệm vụ. Tất cả những gì bạn cần trong Scrum để có thể điều chỉnh kế hoạch hàng ngày là điều gì đó cho thấy tiến trình của Sprint và khoảng cách bạn đạt được mục tiêu của Sprint (thông thường, biểu đồ phát sinh).

Câu hỏi bạn nên đặt ra là: chúng ta có nên đánh giá lại những câu chuyện của mình không?

Tôi sẽ lập luận rằng bạn nên cho phép "phép thuật" Agile cân bằng các ước lượng dưới và quá mức của bạn so với số lần lặp khi tính vận tốc của bạn cho lần tiếp theo (đó là lý do duy nhất để điều chỉnh giá trị). Xem Dự toán và lập kế hoạch nhanh nhẹn của Mike Cohn để biết thêm thông tin.

Tuy nhiên, có một trường hợp bạn nên đánh giá lại: nơi mà bạn đã học về một loại công việc điều chỉnh tất cả các ước tính trong tương lai.

ví dụ. Nếu việc thêm một cột vào cơ sở dữ liệu được ước tính mất một giờ lý tưởng, nhưng hóa ra phải mất 3 giờ vì một số yếu tố không ai xem xét và có vẻ như yếu tố đó sẽ được áp dụng mỗi khi bạn thêm trường vào cơ sở dữ liệu sau đó tất cả các ước tính cho công việc có tính chất đó nên được điều chỉnh, bao gồm cả dự đoán bạn đang làm việc.

Những gì tôi thấy là hiệu quả nhất là:

• Câu chuyện kích thước theo điểm (hoặc kích cỡ áo phông.)
• Ước tính lại bất kỳ câu chuyện nào trong hồ sơ tồn đọng của sản phẩm bất cứ lúc nào (nhưng đặc biệt là ngay trước khi lập kế hoạch nước rút.)
• Không ước tính lại các câu chuyện được lên lịch cho lần chạy nước rút này - vui lòng đưa ra các mối quan tâm khi đứng lên, nhưng không thay đổi các ước tính.
• Sử dụng thời tiết của ngày hôm qua để lên lịch chạy nước rút

Nếu các câu chuyện đang đi vào giai đoạn nước rút với các ước tính không có thật, các ước tính lại kế hoạch trước khi chạy nước rút sẽ cho phép bạn khắc phục chúng trước khi chúng trở thành một vấn đề. Nếu các câu chuyện mất nhiều thời gian hơn dự kiến ​​vì nhóm quá lạc quan, thời tiết của ngày hôm qua sẽ giúp bạn theo dõi.

Ước tính lại hàng ngày về những gì còn lại có xu hướng hoàn toàn không có thật, như bạn đã mô tả trong câu hỏi của mình. Công việc hoàn thành / còn lại là một con số không có thật được thiết kế để làm cho nó trông giống như bạn đang làm việc "đủ cứng". Tốt hơn hết là hỏi: "Khi nào bạn nghĩ bạn sẽ hoàn thành" và nói rõ rằng nếu có vấn đề với câu chuyện, nhóm sẽ đẩy mạnh để giúp đỡ.

Tôi nghĩ rằng đây không phải là một vấn đề. Thay vào đó, nó có thể thiếu kinh nghiệm. Bạn càng theo dõi scrum, các nhà phát triển càng quen với việc cung cấp các ước tính chính xác hơn. Đây là kinh nghiệm của chúng tôi về việc thực hiện scrum sau 5 tháng.

Trong kế hoạch các phiên poker , các nhà phát triển của chúng tôi đã đề xuất các ước tính rất đa dạng cho từng PBI và từng nhiệm vụ trong lần chạy nước rút đầu tiên. Tuy nhiên, bây giờ, chúng ta gần như bằng nhau về thời gian và ước tính. Bạn dùng scrum bao lâu rồi? Nếu không nhiều, hãy cho nó một chút thời gian. Nhưng nếu đó là một thời gian dài, thì như @pdr đã đề xuất, hãy xem xét thêm tiền ký quỹ cho các nhiệm vụ có rủi ro cao hơn . Ví dụ: mỗi lần nhóm của chúng tôi muốn tạo một phần trình duyệt chéo UI, chúng tôi sẽ vượt qua ước tính của chúng tôi. Do đó, chúng tôi luôn nhân ước tính của các tác vụ trên nhiều trình duyệt với một yếu tố để đảm bảo rằng chúng tôi có thể bao quát nó.

Ước tính lại các câu chuyện người dùng đã cam kết trong khi chạy nước rút không có ý nghĩa. Nó chỉ lãng phí thời gian của bạn. Bạn đã thực hiện cam kết và không thành vấn đề nếu bạn ước tính lại hay không.

Tình huống khác nhau là với những câu chuyện của người dùng không được cam kết cho lần chạy nước rút hiện tại. Thỉnh thoảng nên lập dự toán lại (không quá một lần cho mỗi lần chạy nước rút trước khi lập kế hoạch). Các tình huống tại sao có thể hợp lý để ước tính lại có thể là:

• Chủ sở hữu sản phẩm đã thay đổi bất kỳ câu chuyện người dùng nào
• Chủ sở hữu sản phẩm chia hoặc hợp nhất bất kỳ câu chuyện người dùng nào
• Chủ sở hữu sản phẩm đã thêm câu chuyện người dùng
• Bạn có một số kiến ​​thức bổ sung không có trong câu chuyện của người dùng trước
• Bạn thấy rằng một số câu chuyện của người dùng có liên quan và bạn đã thực hiện một phần của câu chuyện khác chưa được cam kết
• Vân vân.

Bạn không nhất thiết phải ước tính lại mọi câu chuyện của người dùng nhưng bạn có thể. Để ước tính lại hoàn toàn, bạn thường cần một số phương pháp nhanh. Lập kế hoạch chơi bài có thể rất chậm, không hiệu quả, nhàm chán và đôi khi cũng không chính xác nếu bạn mất hơn 10-20 câu chuyện để ước tính. Thay thế có thể là ước tính Magic .