Why do we use Story Points for Estimating?

Story Points – An Introduction

The scrum guide tells us that estimates should be provided by people that will be doing the work but it doesn’t tell us how we should provide estimates. It leaves that decision to us. A common tactic used by scrum teams is to estimate using a unit of measurement referred to as the Story Point. But why use Story Points instead of hours or days or any other well-known unit of time? Are we deliberately trying to obfuscate? In this article I look at the pros and cons of using Story Points and come to a surprising conclusion.

What is a Story Point?

Unsure about Story Points?
Unsure about Story Points?

I did a quick search on Google for the phrase “What are Story Points”. I was hoping to get a clear definition of the term but it proved highly elusive. The list I got back from Google wasn’t overly helpful and some of the higher placed links were, in my view, simply wrong in places. Surprisingly (to me at least) an article I had written, a necessarily terse precis on estimating in Scrum appeared on the first page of the search and I hadn’t tried to define what a Story Point was at all.

Summary: I couldn’t find a clear definition of what a Story Point is on the Internet. So, here’s my attempt:

A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide relative estimates of effort for completing requirements

 Why use Story Points?

Story Points are intended to make team estimating easier. Instead of looking at a product backlog item and estimating it in hours, teams consider only how much effort a product backlog item will require, relative to other product backlog items.

Ok, so it makes estimating easier but how is that useful? Story Points are of no value whatever to a business because they can’t be used to predict cost or delivery dates. Even the Scrum team cannot make any predictions as to how many Story Points it can complete in a sprint (velocity) until it’s got a few sprints under it’s belt, some months down the road.

Story Points are confusing

Confused about Story Points?
Confused about Story Points?

Story Points themselves are confusing.

Mike Cohn, respected author of the book “Agile Estimating and Planning” recently wrote an article explaining why you should use effort and not complexity in deciding relative sizes of product backlog items.  It’s a good article but the comments from readers leaves you in no doubt that here’s a lot of confusion around the topic of Story Points.

What’s wrong with using time as a unit of measure?

For hundreds of years we’ve had standard units of time. Why can’t we use hours or days? Well, in a nutshell, because your hour is not the same as my hour.

If you ask two developers to estimate the same task, you’ll get two different answers. While some of the difference might be explained by gaps in the specification or understanding, the fact is that developers have different knowledge and experiences so it will take more or less time to do the same work.

Ask those same two developers to rate the amount of effort required to complete one product backlog item relative to another product backlog item and you’re far more likely to end up with a consensus.

The real reason for using Story Points

So, up until now, you may have been unconvinced about the need to use Story Points. Ok, they show the relative effort to complete work on different product backlog items but how does that help anything? Until we understand what the team’s velocity is, we still can’t predict when product backlog items are likely to be completed. Worse, if the membership of the team changes, the velocity will change and we won’t know what that new velocity is until some time down the road.

All these problems have led many to try and make a correlation between Story Points and time but as Mike Cohn points out in his article on relating story points to hours, it’s not trivial.

But to try and match Story Points to hours is missing the point. What’s important is how many Story Points a team can complete in a sprint, known as the velocity. When you know this, you can make some predictions and you know what, they’re likely to be good. Very good.

Delighted about Story Points!
Delighted about Story Points!

The real reason for using Story Points is that they’re accurate.

Who says so? Jeff Sutherland, the co-author of the Scrum Guide. In his article on why Story Points are better than hours he puts it like this:

 Story points are therefore faster, better, and cheaper than hours and the highest performing teams completely abandon any hourly estimation as they view it as waste that just slows them down.

It’s nice to get clarity on these things.

Derek is a Professional Scrum Trainer with Scrum.org and the owner of a small, UK based business called Webgate. He loves to help others learn Scrum and provides scrum trainer, agile coach and scrum master services across the UK and Europe. A software professional with many years experience of software development, software project management and teaching, he is a passionate advocate of agile software development and Scrum.

  • Randy

    Great article.

    “If you ask two developers to estimate the same task, you’ll get two different answers.”

    This is true and we should also point out that the problem isn’t only with multiple team members.

    You can get different answers from the same developer over time.

    Effort * Business Conditions * Technical Ability of Team * Team capacity = Time

    Therefore, you will also get different answers from a single developer if business conditions, technical ability, or team capacity changes.

  • Steven Gordon

    We use story points because estimates ultimately do not matter, so we should do everything we can to reduce their criticality and the amount of time we waste on them. If we could get away without even estimating, that would even be better.

    People argue that the team story-pointing generates discussion that leads to a better understanding of each story. A story that everybody instantly agrees is a “5” generates no discussion, yet there could still be a lack of consensus on what the story is really about.

    Instead of coming to a number for each story, breaking each story down into thin vertical slices of approximately the same size would accomplish an even better understanding of each story and would lead to lots of other goodness which assigning a number does not.

    If you said that slicing stories into however many 1-point stories it entails is just another form of estimation, I would have to concede the point, and then recommend that as the way to do estimates.