Comments on: Separate Scales for Story and Task Estimates http://www.rallydev.com/agileblog/2007/11/separate-scales-for-story-and-task-estimates/ Adopt, Scale and Succeed with Agile Development Tue, 10 Jan 2012 03:30:50 +0000 hourly 1 http://wordpress.org/?v=3.0.5 By: Alex Pukinskis http://www.rallydev.com/agileblog/2007/11/separate-scales-for-story-and-task-estimates/#comment-6462 Alex Pukinskis Mon, 26 Jul 2010 22:38:33 +0000 http://www.edsauer.com/beta/blog/?p=48#comment-6462 I would recommend sticking with the more conservative commitment, expecting that in future iterations, you would discover a similar amount of work. Use the initial plan estimates, not revised estimates. I would recommend sticking with the more conservative commitment, expecting that in future iterations, you would discover a similar amount of work. Use the initial plan estimates, not revised estimates.

]]> By: Mari Gonzalez http://www.rallydev.com/agileblog/2007/11/separate-scales-for-story-and-task-estimates/#comment-6406 Mari Gonzalez Thu, 22 Jul 2010 14:13:35 +0000 http://www.edsauer.com/beta/blog/?p=48#comment-6406 Hi Alex, Your response seems very practical, thanks. On your second paragraph, however, if a team is able to complete 38 hours of work instead of the planned 33, did you really mean to say that in the next iteration they should plan again for 33? Shouldn't it be for the feasible 38 hrs? Or is your whole point the fact that more tasks will be unveiled during the sprint thus we should stick with the more conservative commitment? Thanks for the clarification! Mari Hi Alex,

Your response seems very practical, thanks.

On your second paragraph, however, if a team is able to complete 38 hours of work instead of the planned 33, did you really mean to say that in the next iteration they should plan again for 33? Shouldn’t it be for the feasible 38 hrs? Or is your whole point the fact that more tasks will be unveiled during the sprint thus we should stick with the more conservative commitment?

Thanks for the clarification!
Mari

]]> By: Alex Pukinskis http://www.rallydev.com/agileblog/2007/11/separate-scales-for-story-and-task-estimates/#comment-6392 Alex Pukinskis Tue, 20 Jul 2010 22:40:22 +0000 http://www.edsauer.com/beta/blog/?p=48#comment-6392 Hi, Mari: Developers should feel like they have all the detailed acceptance criteria when they're breaking down tasks. They should do their best to identify tasks in iteration planning based on what they know. There's always a chance that you'll discover more tasks over the course of the iteration. But after a couple of iterations, you should know how many planned hours of tasks the team can do. For example, imagine the team plans for 33 hours of tasks in an iteration, but they discover 5 more hours of tasks and complete all 38. It would seem like they should then plan for 33 or fewer hours worth of tasks in the next iteration. The goal is to not plan perfectly, but to do your best at planning, deliver what you commit to, and adapt your future commitments based on what you learn. Maybe the team needs some encouragement to commit to less in the early iterations, and pulling in more work if they finish early. After a few iterations that feel like wins, planning usually becomes easier. Hi, Mari:
Developers should feel like they have all the detailed acceptance criteria when they’re breaking down tasks. They should do their best to identify tasks in iteration planning based on what they know. There’s always a chance that you’ll discover more tasks over the course of the iteration. But after a couple of iterations, you should know how many planned hours of tasks the team can do.

For example, imagine the team plans for 33 hours of tasks in an iteration, but they discover 5 more hours of tasks and complete all 38. It would seem like they should then plan for 33 or fewer hours worth of tasks in the next iteration.

The goal is to not plan perfectly, but to do your best at planning, deliver what you commit to, and adapt your future commitments based on what you learn.

Maybe the team needs some encouragement to commit to less in the early iterations, and pulling in more work if they finish early. After a few iterations that feel like wins, planning usually becomes easier.

]]> By: Mari Gonzalez http://www.rallydev.com/agileblog/2007/11/separate-scales-for-story-and-task-estimates/#comment-6385 Mari Gonzalez Mon, 19 Jul 2010 19:25:42 +0000 http://www.edsauer.com/beta/blog/?p=48#comment-6385 Thank you for the detail in this post, Alex. It is very helpful since we haven't used hours to estimate individual task. We have stayed with points at the story level so far. I get the greatest resistance from developers when it is time to break down stories into tasks. Often they tell me they have to research the story before identifying all the tasks. I want to be flexible, understanding that maybe up to 30% of tasks are not completely thought out at a planning meeting. So if the tasks are not all identified and estimated at the planning meeting, how should I represent that work in a burndown chart in the meantime? Thank you for the detail in this post, Alex. It is very helpful since we haven’t used hours to estimate individual task. We have stayed with points at the story level so far.

I get the greatest resistance from developers when it is time to break down stories into tasks. Often they tell me they have to research the story before identifying all the tasks. I want to be flexible, understanding that maybe up to 30% of tasks are not completely thought out at a planning meeting. So if the tasks are not all identified and estimated at the planning meeting, how should I represent that work in a burndown chart in the meantime?

]]>