The Trouble with Estimating
One of our biggest challenges so far is figuring out the best approach to estimating stories. From a project management perspective, I’d like to:
- Understand how much work we thought we’d get done in a sprint
- Understand how much work we did get done
- Understand how accurate our estimates were, at two levels: estimating the size of the story, and estimating the effort for tasks when the story is broken down
I’d like to understand these for two reasons:
- To help the team get better at estimating, and
- To help me get better at release and product planning
Our primary challenge so far is in finding a unit of measure which is applicable across all types of estimates. For example, the often cited proportional story estimate techniques (1, 2, 3, 5, 8 or XS, S, M, L, XL and so on) aren’t quantifiable. And in the end, the team is estimating tasks in hours (2, 4, 8, 16). Having a story that was originally ball-parked at a ’5′ or ‘M’ and eventually estimated in detail at 16 hours doesn’t do me much good, because it’s difficult to correlate the two.
On top of all this I wonder if I’m totally missing some critical piece of ‘agile’ thinking in trying to get this structure in place.
Right now, we’re estimating like this:
During a weekly story time, the team is estimating total effort for a story using 1, 2, 3, 5, 8, 13. Each number represents an ideal day of effort for the team. I can then translate that into hours, so a 3-point story works out to 24 hours. When we break the story down into tasks during our sprint planning, we can see what that really looks like — for example 30 hours. The one missing piece here is that in our original estimates we’re not taking into account how many team members will be working on a story — for example a 3-point story may or may not involve some heavy UI design, which would add to the total overall hours. I’m kind of hoping this will all come out in the wash. More likely I still have some thinking to do.
We just started doing this — I moved away from using the Fibonacci number as a relative estimation technique for now. I can see the value, bit it’s not working for us.
Besides figuring out if this will work and adjusting again, the next challenge is getting the team comfortable with this broad estimating technique.
