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?
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?
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!
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.