Estimating in Scrum uses 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?

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 best effort:

“A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide broad brush relative estimates of effort for completing requirements stated in User Stories“

I am certain it would benefit from refinement so if you have any thoughts on this, please leave me a comment.

Why use Story Points?

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

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

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 User Stories.

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 User Story relative to another User Story 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 User Stories but how does that help anything? Until we understand what the team’s velocity is, we still can’t predict when User Stories 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.

The real reason for using Story Points is that they’re accurate. Jeff Sutherland is the co-author of the Scrum Guide and knows what he’s talking about. 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.

Scrum training

Turbo-charge your Scrum implementation with any of our Agile or Scrum training courses.