RallyDev.com
Fri 16 Nov 2007
Separate Scales for Story and Task Estimates
|
Traditional teams estimate all of their work in one unit type – regular time. These teams then spend a lot of time wondering why their estimates are off and struggling to get more accurate estimates. Many teams are able to bypass this struggle by estimating on two different estimation scales – points and hours. User Stories in your product backlog should be estimated in terms of their relative size. Imagine writing your product backlog out on index cards, and sorting them in order, least effort to most effort. It should be relatively easy to apply a simple numeric scale to represent relative size. If your first story is at a size of one, and the next one seems like it would take twice as much effort, you’d score that one a 2. Once you’ve numbered your product backlog like this, you can measure how many of these units you’re getting done each iteration by adding up the numbers for each accepted story. Over time, if you keep your team together, this “velocity” number should stabilize. If your velocity has been about 15 in the past, you can predict that if the team stays the same, you’ll get 15 done each iteration moving forward. Whether you call these units “days” or “points” or “tomatoes” is irrelevant, as long as you track how many you’re getting done. I like calling them “points” because it’s politically useful to do so. If a 5 person team is getting 10 days worth of work done each week, management might wonder why they’re only 40% efficient. If they get 10 points worth of work done, the efficiency discussion doesn’t come up in this way. Why use hours for tasks then? Story estimates are basically numbers you pull out of the air, after a couple of minutes of discussion. But when you’re planning tasks at the start of the iteration, you know a lot more – the detailed acceptance criteria, the detailed task list, and maybe even who’s doing the work. Estimating tasks in hours reflects the precision of the estimate (although I try to stick to 1, 2, 4, 8, and 16 hours because you really can’t be more precise). |
|
| Consider this pattern when: |
|
| Be careful with this pattern when: |
|
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?
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 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
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.