Story Points Explained - Part 1: The Whys

This is the second of 8 posts. In this post series I'll try to tackle one of the more "mystical" topics of Agility: story points. In this post I will tackle the history of story points. I will also dig into why people find them helpful.

 

Let's start with a bit of history. Early Extreme Programming projects used the term "Ideal Man Days" to express estimates. As you can guess an iteration can be less than ideal. They set "correct expectations": we will do our best to stick to the plan, however things might not go our way. The "ideal time", was then adjusted using a "load factor".

Ron Jeffries first mentions "Gummi Bears" in 1999. He used the term to further emphasize that our plans will change. It was in that period that story points also appeared as a unit of measurement.

As you've guessed people liked the term story points more.

 

So what is the point of Story Points? Why use them?

 

1. They make estimations less time consuming

Agilists determined that working software is the best measure of success. While estimations help with planning, they are not "working software". They only give a "rough idea" of the workload involved in the project. They are also based on false premises:

  • we know what we need to develop up front

  • we won't have any surprises with technology

  • we know the exact people that are going to work on the project for X amount of time

Every hour spent in estimation is an hour not developing or contributing to the project.

2. They set the correct expectations

The future is unpredictable. Story points acknowledge that. They do not mean a hard commitment. This means we have room for error.

Together with the team "commitment" they make a pretty good system of planning for the future. Not perfect, but decent enough that you don't waste too much time debating.

3. They help with "shared codebase" mentality

A story point is neutral. A time estimation is subjective to the person that does the estimation. A story point estimation is subjective in comparison to other story points.

Once individual commitments are out of the way, your team can start being flexible in who does what. This makes the team more adaptable to changing requirements from business. People in the team can shift tasks as needed, focus on biggest value items first. You can see how this is more helpful to business than "I can only work on this" mentality.

 

I hope this post was a good read and gets you excited about implementing story points in your team!

Previous
Previous

Story Points Explained - Part 2: Usage

Next
Next

Story Points Explained - Part 0: Introduction