Measuring work: The Story Point

Author: Jesús Espejo Dominguez

One of the many stages of every software development process is the estimation. It’s needed to budget, to know costs, for commercial purposes and for internal use. It could be even said that estimation is the daily routine for many professional in the industry. However, although it’s frequently used, there is still a lot of improvement in the processes. At least, it could be said many professionals are very conservative and reject new fresh approaches. Let’s elaborate a bit.

The reason

We estimate because we are trying to measure the size of a piece of work. Measuring work pieces using ‘Time’ has been a common practice for other industries but this approach brings special disadvantages for software. In fact, besides all the ‘Time’ has done for us all over these years, it’s time to move on.

‘Time’ measures time and it’s not good way to measure work. These are some known inconsistencies when using hours to estimate work:

• Junior developers spend 20h doing something that was estimated in 8h. Isn’t really the same amount of work for them?
• Junior developers work during a whole week to perform a task estimated in much less. Haven’t junior developers worked 40h of work every week if they have just done 20h of estimated work?
• Super-Senior developers are capable of achieving 50h of estimated work in their 40 regular hours of weekly work. How can you fit this in the company forecast?
• Senior developers tend to give lower estimations (using hours) compared with a junior. What if a junior has to finish the estimated task of a senior?

Story Points

Following the Scrum approach, the solution is the Story Point. Skipping the explanation about the naming convention, the brains behind the methodology wanted to define a unit to get rid of the ‘Time’ imperfections. They proposed to stop measuring ‘Time’ and start measuring ‘Effort’. How much effort is a Story Point? It depends. It depends on the company, it depends on the technology and it even depends on the Team.

It might sound mind blocking but let’s put some light on it. There are several ways to define how much effort a Story Point will be:

• Defining the minimal effort: Acknowledge something easy that everyone knows and name it 1 Story Point.
• Selection: Take a relatively small piece of work among all needed to estimate and assign 2 or 3 Story Point.

For both cases once the Story Point is defined, other pieces of work will be estimated by approximately scaling the effort.

Team Velocity

Surely managers are wondering how to translate those Story Points into ‘cost’ (measured in euros) and ‘Time’ (measured in hours). There is another concept needed: Team Velocity. The team velocity is the amount of Story Points the team is capable of doing during a Sprint. Once the velocity is known, it’s very easy to calculate the needed time. And from ‘Time’ managers can calculate cost. So it’s not about how many Story Points a project estimate has, it’s about the relation between the Story Points and the team velocity.

Let’s look at an example. How much time will it take to finish a project estimated in 150 Story Points? It depends on the team velocity as well. Let’s suppose the team velocity is 10 Story Points per sprint. That makes 15 sprints.

As you might have noticed the ‘Team’ concept has appeared several times. The Story Points approach is based in team distributions, where teams always have the same amount of workers. As a summary, Teams don’t split up when a project is finished nor the workers are re-distributed to other teams. Teams remain as a team when projects come and go.

What is the advantage of using Story Points in this Team-organized environment? It’s very easy to measure performance variations using Story Points. A team’s performance varies along the time. Usually a team’s performance improves with the time (since the workers get more experienced), however many projects fail due to underperformance. Here some examples:

• A team of 3 developers started doing 12 Story Points per sprint. That makes 4 Story Points each per average. After some time they are capable of doing 15 Story Points per sprint. That makes 5 Story Points per average. It looks they have improved and they are doing well.
• A team of 3 developers started doing 12 Story Points per sprint. That makes 4 Story Points each per average. After some time they are doing 10 Story Points per sprint. That makes 3.33 Story Points per average. It looks like they are having difficulties.

Now, how could this be done with ‘Time’? Let’s try:

• A team of 3 developers started doing 120h per week. That makes 40h each per average. After some time they continue doing exactly the same: 120h per week. Useless. There is no way to know whether they are not improving or failing nor there is a warning signal.

And coming back to the ‘Time’ inconsistencies:

• How are the seniors and juniors performing with Story Points? Probably seniors are doing 5 times more Story Points than juniors. It’s just a guess, however the important matter is that during those 40h per week some of them are doing 10 Story Points and others just 2 Story Points.
• What happens with the estimations? Estimations mean the same effort for seniors and juniors. If a senior estimates a piece of work in 10 Story Points you can easily know it’s a week of work for them, 5 weeks of work for a single Junior and less than a sprint for those teams previously mentioned.

What is the most important idea of all: 10 Story Points is the same amount of work for juniors, seniors and Teams but they all take different time to finish it!

To finalize, Story Points, Teams and Team velocity are concepts linked to many others that belong to the Scrum methodology and it’s difficult to commit them while skipping others. All those aspects brace each other and that makes Scrum such a strong approach.

Originally published at www.elements.nl on February 18, 2015.