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

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?

• Fast Estimation
• Story Points are only one third of the reason to estimate
• Top Tips for Planning Poker

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: andrewrusling@hotmail.com