Why Use Points for Estimation?

April 4, 2018 • John Vandivier

I've often been asked to map points to hours as part of an estimation process. This kind of works and kind of doesn't. I'll give my rule of thumb at the end, but first I want to defend the use of story points qua story points.

If the only purpose of story points is to map on to hours, then why not use hours to begin with? The introduction of story points in that case merely obfuscates the variable of interest and makes accurate estimation harder, so the result is an inaccurate forecast. If the goal is an hourly estimate then estimates should be done in hours.

Clearly, then, there are two possibilities:

Story points have some other utility
Story points have no utility.

I argue in favor of the former. Experience leads me to believe the two main factors give utility to story points:

Using abstract points eases the mind of developers, reducing the estimate padding and noise associated with fear of being held to a deadline.
Using points makes comparison easier.
1. Similar stories may vary at the hourly level, but they don't vary by much.
2. Similar stories are also implemented similarly, and the level of complexity and risk is also similar.
3. These factors are exactly what points capture, allowing the grouping of stories by kind to occur naturally.
4. Then, people can logically say \"This kind of story is this number of points, but this other kind is more or less complex/risky, so let me modify the points by 1 level.\"
  1. Where a Fibonacci level is like 5->8 or 5->3.
  2. Basically, the imprecision of points here becomes an advantage. Where a manager could complain \"Why is this 16 hours and not 15? What makes you so sure?!\" They have no room to complain with points. The developer moved the estimate just one level and this is easily logically defended.

Because points are imprecise, it's also faster and easier for developers to generate accurate point estimates based on limited information, where they could not generate accurate hourly estimates given the same information. However, after teams develop estimation routines around points, there emerges a normal ratio of time per point. This is properly a retrospective observation, it is not proper to declare hours per point prescriptively. Why? Because if you declare the hours per point prescriptively, you have just removed the easing effect (benefit 1) and the advantaged imprecision of points (benefit 2). You also incurred the resolution cost of points. So you are net worse off. You should have just done hours.

The method I recommend has the best of both world in my view. It's a triple estimation approach:

Release planning with quickly generated point estimates
Revisit and update estimates as needed during elaboration time
Add hourly estimates and actual hours during elaboration and development time

This allows retrospective identification of the natural, non-forced, hours-to-points ratio. These hours are actuals, not estimates, which is even better. So now you can have developers go estimate a backlog in terms of points and get an actual hour estimate without directly asking them for it, resulting in an hourly estimate with minimal error. Much less than the biased, obviously high estimate you would have gotten by asking directly.

Googling around to see why other folks like points turned up <a href="http://www.agilebuddha.com/agile/agile-estimation-9-reasons-why-you-should-use-story-points/">this article discussing 9 reasons to use points. I think it's pretty good, but my notes on their 9 points are below:

Points don't make things more accurate by using velocity for planning.
1. It makes things more accurate in the short run by not forcing developers to commit to hourly estimates they are (properly) uncomfortable with.
2. It makes things more accurate in the long run by producing an low-bias instrument for hourly estimation.
I agree! Using points reduces the need to re-estimate each work item because the point itself is a variable construct, like a size-based estimate.
I agree. This is a subtle observation, but a great one.
1. Using points actually shifts the whole Agile mindset from a time-minimization process to a productivity-maximization process.
2. This processes may be mathematically and even economically isomorphic, but they are attitudinally worlds apart.
3. Asking \"how can I improve our productivity\" is a positive psycho-sociological approach.
This was my point #1. Totally agree.
Agree. It also focuses the client on clarifying and simplifying requirements, rather than focusing them on timeline and cost.
I agree. Because points are targeted to the average developer, not me in particular, it forces developers to converse and uncover what the average developer even looks like.
Meh. I guess.
Interesting. I'll have to read the paper. This seems to overlap with my point #2.
Absolutely agree.

Finally, below is my rule of thumb. The way I describe this rule of thumb is that I bring it up during onboarding. Different teams estimate along different norms, so I only bring it up as a starting point and an introduction to my team starting expectations. It's always taken to be a rule of thumb and a starting point, it's never taken to be binding.

1 point means the item is already done and a tester has already approved or it doesn't need to be tested. It just needs to be recorded in our Agile requirements tracking software.
2 points means it will take less than an hour to develop or it's already developed. It mainly needs to be tested.
3 points means it will take about a day, maybe a part of a second day.
5 points means 2-3 days.
8 points is roughly a week.
13 points is roughly two weeks.
1. In Agile teams with a 2 week sprint there is no guarantee that time will be left for testing, but it's possible.
21 points means it will take more than three weeks.
1. It is too large for a typical Agile sprint, regardless of whether the team uses 1, 2, or 3 week sprints. (Sprints over 3 weeks are not a best practice.)