ABCs of Story Estimation

Estimation, predicting the future, is an art at best. Backing estimation techniques with extensive mathematics and statistics may make upper management happy--it's always great if you can provide supporting data for something and distill it to a single number! (42, of course.) But such diligence only serves to bestow way too much legitimacy on a bunch of HAGs (remember WAGs and SWAGs? Well, the "H" is for "Hairy").

Agile teams use dozens of various techniques for deriving story estimates. As my doctor once told me, so many "solutions" means that none of them is very good.

Predicting the future with estimates is immediately setting ourselves up for failure. When we estimate, we are always wrong. Always. It's just a matter of degree. But that's ok--we can get better over time, and the business always finds value in estimates. Repetition and increasing familiarity with things can dramatically improve the amount of error.

Best advice: Start simply! These five guidelines should help get you on your way.

  • All contributors estimate - not just a representative developer or team lead, and most certainly not anyone from the customer team simply asking for the story (how bizarre!). Those who do the work get to have some say in how large the story is. It doesn't make sense any other way.

  • Break story down into tasks to verify scope - This exercise can help verify whether or not this is the right story, and often brings out discussions around things that will impact the estimate. Sometimes a quick task breakdown gets the team to concede that this is a much larger story than thought.

  • Come to Consensus using planning poker - James Grenning's wideband delphi-based technique is a fun, engaging, and expeditious way of deriving a lot of estimates from a good-sized team. Show the cards, and if all are in agreement, or close to it, pick the size and move on. If there's disagreement, debate for a few minutes, try again. If there's still disagreement, come back later and move on to the next story for now.

  • Decrease estimation granularity as story size increases - It's silly to think that we can estimate anything precisely. As the story gets larger, beyond a couple days, even a day variance on an estimate is too fine. "Is this 6 days or 7 days?" Gee, let's do it and find out. The Fibonacci sequence is a classic choice for agile teams. A story that the team thinks is a 6 is most certainly not going to be done in 5 days, so it gets bumped up to 8.

  • Estimate using relative sizes, not calendar days - There will be no end of debate on this, but sizes do not degrade over time, and they do not vary depending on developer capability and availability. Calendar days do. Mike Cohn's book Agile Estimating and Planning provides many good additional insights on the differences between the two.


  1. sorry about the re-post. I cleaned up the card a bit, it's a lot less cluttered, but then blogger seemed to have deleted something on me (no doubt operator error). Font = AndrewScript 1.6

  2. This post strikes me as a little too cutesy and glossy. That's the job of the card, not the text.

    While references to other people's books are good, you need to include the core details. How do I get from days (point D) to relative sizes (point E)? Where's a link to planning poker? Is the breakdown (point B) before or after initial estimation?


  3. Hi Austin--thanks for the feedback! The whole topic of estimation and planning seems cute and glossy to me, and so my perception did influence the writing. Sorry about that. You're right, also, in that it could use a bit more meat.

    I've encountered almost as many ways to approach estimation as I have encountered teams, so I resist the notion of prescribing flow. For example, task breakdowns can (and should) occur whenever necessary. Teams might have the prescience to determine immediately that a story should be broken down to estimate it, or they might decide they need not--until they find out (using planning poker) that there is no consensus on its size.

    Perhaps there is a set of "starter steps" we could add to the text here. This card right now is closer to guiding principles. Tim is taking a look and we'll figure out if this needs to be a different card or perhaps just redone.

    I did add a couple links, thanks for the suggestion.

  4. This comment has been removed by a blog administrator.

  5. This comment has been removed by a blog administrator.

  6. This comment has been removed by a blog administrator.


Note: Only a member of this blog may post a comment.