The Main Benefit of Story Points

If story points are an estimate of the time (effort) involved in doing something, why not just estimate directly in hours or days? Why use points at all?

There are multiple good reasons to estimate product backlog items in story points, but there is one compelling reason that on its own is enough to justify the use of points.


It has to do with King Henry I who reigned between 1100 and 1135. Prior to his reign, a “yard” was a unit of measure from a person’s nose to his outstretched thumb. Just imagine all the confusion this caused with that distance being different for each person.

King Henry eventually decided a yard would always be the distance between the king’s nose and outstretched thumb. Convenient for him, but also convenient for everyone else because there was now a standard unit of measure.

You might learn that for you, a yard (as defined by the king’s arm) was a little more or less than your arm. I’d learn the same about my arm. And we’d all have a common unit of measure.

Story points are much the same. Like English yards, they allow team members with different skill levels to communicate about and agree on an estimate. As an example, imagine you and I decide to go for a run. I like to run but am very slow. You, on the other hand, are a very fast runner. You point to a trail and say, “Let’s run that trail. It’ll take 30 minutes.”

I am familiar with that trail, but being a much slower runner than you, I know it takes me 60 minutes every time I run that trail. And I tell you I’ll run that trail with you but that will take 60 minutes.

And so we argue. “30.” “60.” “30.” “60.”

We’re getting nowhere. Perhaps we compromise and call it 45 minutes. But that is possibly the worst thing we could do. We now have an estimate that is no good for either of us.

So instead of compromising on 45, we continue arguing. “30.” “60.” “30.” “60.”

Eventually you say to me, “Mike, it’s a 5-mile trail. I can run it in 30 minutes.”

And I tell you, “I agree: it’s a 5-mile trail. That takes me 60 minutes.”

The problem is that we are both right. You really can run it in 30 minutes, and it really will take me 60. When we try to put a time estimate on running this trail, we find we can’t because we work (run) at different speeds.

But, when we use a more abstract measure—in this case, miles—we can agree. You and I agree the trail is 5 miles. We just differ in how long it will take each of us to run it.

Story points serve much the same purpose. They allow individuals with differing skill sets and speeds of working to agree. Instead of a fast and slow runner, consider two programmers of differing productivity.

Like the runners, these two programmers may agree that a given user story is 5 points (rather than 5 miles). The faster programmer may be thinking it’s easy and only a day of work. The slower programmer may be thinking it will take two days of work. But they can agree to call it 5 points, as the number of points assigned to the first story is fairly arbitrary.

What’s important is once they agree that the first story is 5 points, our two programmers can then agree on subsequent estimates. If the fast programmer thinks a new user story will take two days (twice his estimate for the 5-point story), he will estimate the new story as 10 points. So will the second programmer if she thinks it will take four days (twice as long as her estimate for the 5-point story).

And so, like the distance from King Henry’s nose to his thumb, story points allow agreement among individuals who perform at different rates.


About the author
Mike Cohn
Author: Mike CohnWebsite:
Agile Software Practitioner, Coach, Author and Owner at Mountain Goat Software
Mike Cohn is one of the contributors to the invention of the Scrum framework. He is one of the founders of the Scrum Alliance and owner of Mountain Goat Software, a company that provides training on Scrum and Agile software development techniques.He began his career in the early 1980s as a Programmer in APL and BASIC before moving on to C++ and Java and running development groups. Cohn ran his first Scrum project in 1995 and has been a vocal proponent of Scrum ever since. Cohn is the author of Agile Estimating and Planning, User Stories Applied for Agile Software Development and Succeeding with Agile: Software Development using Scrum, as well as books on Java and C++ programming[4] and articles for Better Software, IEEE Computer, Software Test and Quality Engineering, Agile Times, Cutter IT Journal, and the C++ Users' Journal. He is also the editor of the Addison-Wesley Mike Cohn Signature Series of books. In 2012, Cohn was named #1 in The Top 20 Most Influential Agile People.

Past Events

Our Services

Contact Us

Bosnia Agile
Milana Preloga 12, Sarajevo 71000
Bosna i Hercegovina

This email address is being protected from spambots. You need JavaScript enabled to view it.