Friday, July 12, 2013

Story Points do not equate to Time

A.k.a. Story Points allow us to separate Estimation from Commitment

I have known (through experience) for a long time that Story Points are a great way for teams to estimate their work. However it has taken me a long time to come up with an explanation that can convey what I already knew. If you are interested in that explanation, then please read on.

Story Points vs. Ideal Days

Story Points are an estimate of the Size of the Story. Where Size is the combination of Complexity, Effort & Doubt:
  • Complexity – Difficulty, hard algorithms, complex logic extra, abstract concepts.
  • Effort – Raw effort / grunt work. I.e. Making a simple parameter change to hundreds of similar method calls.
  • Doubt – Uncertainty around how will we build it or what it is that we need to build.

Ideal Days or Ideal Hours is an estimate of how long it will take to complete the Story.

So while Story Points are made up of a single element: ‘Size’, Ideal Days are made up of two elements:  ‘Duration’ and ‘Size’.

Story Points cannot be equated to Ideal Days/Hours because they are made of different elements. i.e. Size vs. Duration & Size.

Here is an example that illustrates my point

Example user stories with size

Story A is estimated by the team to be 1 Story Point. Story B is estimated by the team to be 8 Story Points. Suppose that we get our two brand new graduates to work on Story A, while our two experienced Senior Developers work on Story B. Story A is completed in 5 working days, Story B is also completed in 5 days. Now suppose that we had given Story B to our new
 graduates, while our experienced Senior Developers worked on Story A. In this scenario Story A is completed in 1 day, while our graduates will struggle on eventually delivering Story B after 30 days! While the Size of the Story remained the same the Duration to complete them varied dramatically based on who worked on the Story.

Estimation vs. Commitment

We use Story Points because it allows the team to focus on estimating one element; the Size of the Story. When sizing the Story we do not have to consider Who will work on it, or consider Committing to the Story.

During Sprint Planning we decide which Stories to Commit to the Sprint Backlog. This is where the team considers who will work on which story; hence combing the elements of Size, Who & Duration.

Estimating in Story Points allows for Estimation and Commitment to be separated, giving better results for each.

Please give it a try, and let me know how it turns out for you.

Interested in estimation?

Training available in South East QLD, Australia

If this article was interesting to you, then your team would likely benefit from face to face training on Agile Estimation. I run a one-hour Agile Estimation training session, that is highly interactive, immensely fun and teaches the foundation of agile estimation along with how to effectively run Planning Poker as well as Fast Estimation. Please contact me to set up a training session for your team:


  1. Thanks for the great explanation! On the commitment part, though, the approach you've described works when a commitment is limited to a single sprint which is not always the case.

  2. Hi Dmytro, I am glad you like the explanation. I only get teams to commit on a Sprint by Sprint basis so it works for me. Do you get teams to commit across multiple Sprints? i.e. Committing to a Release Backlog?

  3. I found this post as I was looking for additional insight for the blog posts I was writing on estimation. I had already planned a blog post on story points, so I didn't want to comment until I had finished it. Since it went live today I finally am ready to comment. As I read this post it gave me an idea for another post on story points which I hope to have up by the end of November.

    You hit the explanation of the why on story points versus time just about perfectly. One thing I found useful, especially for the team new to Agile and estimation, is to further emphasis that story points are not time by obfuscating it further and dropping the number part off of story points. I am not sure if you allow links, but the post is here:

    I look forward to catching up on more of your posts over the next few weeks. The more time I spend learning about Agile Methods the more I realize that nobody will ever be done learning about them and we can all learn from each other.

  4. One of the benefits that comes from Story Points is adding them up to determine velocity, then using velocity to predict when a backlog of work will be completed.

    Removing the numbers, removes this benefit. This is why I go through the extra effort of mentally separating Story Points from Hours, for the teams I work with.

  5. I am glad you take pride in what you write. This makes you stand way out from many other writers that push poorly written content. designs

  6. I’m going to read this. I’ll be sure to come back. thanks for sharing. and also This article gives the light in which we can observe the reality. this is very nice one and gives indepth information. thanks for this nice article... grief