Sample Product Backlog Estimates

• User Story #1 - 4 points
• User Story #2 - 1 points
• User Story #3 - 2 points
• User Story #4 - 2 points
• User Story #5 - 8 points

So, why not just estimate in hours? The answer is in how the human mind deals with numbers.  

There are two primary examples to consider.  First, we don’t estimate things to take 26 or 27 hours.  Instead, we say a task might take 24 hours because we convert this in our minds to 3 work-days. Or we might even give an estimate of 20 hours which makes us strain just a bit harder and think in terms of half work-days, but we are willing to do the mental conversion because we feel its worth the additional granularity. Second, if I ask you to tell me whether a specific task will take 26 hours or 27 hours, you probably couldn’t reliable say either way.  A difference of 2 hours when compared to 26 feels negligible. 

These two examples are reflections of two challenges:  

1) Anything over about 8 hours of effort causes us to begin doing mental conversions to internalize the amount of time involved.

2) When numbers grow in size we have difficulties having conviction in our estimates.  How can you make a strong argument to management that a task, feature, or user story can’t be done in 48 hours, that it requires 56?

Story points solve these problems by normalizing estimates around a unit of 1 story point.  So, the smallest user stories may take 1 story point of effort to complete while harder ones may take more (2, 4, 8, etc.)

This immediately solves our first problem, since I no longer have to convert estimates during the estimation process.  I’m making relative comparisons of overall complexity and effort.  The human mind lives in the domain of relative comparisons.  So, it’s much easier for our brains to determine that one user story is about twice as big as another than to say one will take 16 hours and another 32 hours.  So much easier, in fact, that some companies have found that by estimating projects in terms of story points their time spent on project estimation has reduced by 80%.

Story points also solve our second problem of both defending and having conviction in our estimates.  Since we are dealing with story points, as estimates get larger we don’t worried about maintaining the same level of granularity as we might if dealing with hours.  We don’t size user stories in half story points.  In addition, management is less likely to argue that a particular user story should be 2 points versus 4 points.  However, if they are reviewing estimates in hours, all too often they will argue than 80 hours “seems to long” for a particular piece of work.