Why do scrum teams estimate work in story points?

Companies that adopt agile or scrum often estimate their work in story points.

What are the advantages?

How are estimations best done?

Top-down versus bottom-up

Work can be estimated top-down or bottom-up.

A top-down estimation uses data of previous projects. Looking at this previous data, an estimate is given for the whole project.

Lets consider that a project “New Payment GUI” will be estimated and that a similar project ‘New ordering GUI‘ took 1000 man-days. A top-down estimate for the new payment GUI project could be 1000 man-days.

The risk with top-down estimations is that it can be difficult to find relevant historic data, and that subtle but important work in the new project is forgotten to be included in the estimation. You probably know projects yourself that surpassed their initial budget by more than 100% because the scope or complexity was underestimated.

What can we do about this?

One approach could be to investigate the scope and complexity better. Some projects start with a study phase in which we do a detailed estimation of the cost.

In a bottom-up approach, the project is first split into deliverables (via a ‘work breakdown structure’) or in stories. Each deliverable is then estimated, and the sum is taken to know the total cost of a project.

Sounds good, but does it provides better estimations?

Rarely.

There are still major risks when doing an upfront bottom up estimation of a project:

• Business requirements change every day. One of the reasons why agile scrum projects are popular nowadays is because they can cope much better with changing requirements.
• Business requirements are not always clear enough for team members to estimate properly.
• People often underestimate the overhead on their deliverables. People have to go to meetings, follow trainings, manage incidents, provide support. Staff cannot work 8 hour/day on deliverables. Senior project leaders often take a 100% overhead margin when doing a bottom-up estimation.

Looking at the risks above, one could be tempted to say ‘lets take a lot of effort to do a proper study upfront’.

Bad idea!

The problem with such an approach is that even a proper study can still not eliminate the changing requirements: the world is changing fast, and your project requirements as well!

An upfront study can be a big waste of money . The study itself creates no direct added value. Obviously, some industries (e.g. healthcare) need upfront studies. So you can’t always avoid it. Team members will not work faster because of the upfront estimations, at least not to the extend you invest in it. This is another reason agile scrum projects are popular nowadays in industries that permit it (like software development).

Using top-down or bottom-up estimation techniques are no silver bullets for accurate estimations. Let’s take a closer look further for other techniques we can use.

Dollars

Ultimately, the cost of a project is expressed in dollars (or your local currency).

You could estimate work directly in dollars for some top-down estimations, but bottom up estimations are rarely done for internal (non-outsourced) projects. Team members rarely have a clue how much a past deliverable costs in dollars, so it’s even more difficult to make accurate predictions on future work.

Man-days

In classic project methodologies, work is estimated in man-days (or man-hours).

It is feasible for staff to estimate the time that is needed to perform a task. You can always ask to Bob, our imaginable team member, “how much time do you think this tasks will take“? Bob will give you an answer.

But it is probable that the answer of Bob is based on his gut feeling and personal experience, rather than being based on actual measured performance of the whole team.

Even worse, the effort needed for Bob to perform a task still doesn’t say anything about the overhead Bob has besides the estimated task.

And what if Bob provides a perfectly accurate estimation, but another less experienced member of the team will implement the work afterwards? That person won’t deliver at the same speed as Bob, so even then the estimation would be incorrect.

T-shirt size

Can we solve those challenges?

Yes!

We simply have to take an abstraction of the exact time a person works on a task or deliverable. We will not ask ourselves anymore: “What effort will it take to perform a certain task?“. Instead, we will look at the amount of work a team can do per week, implicitly including all overhead.

Lets first divide work in deliverables or tasks of different sizes. These sizes range from Extra Small (XS), to Small (S), Medium (M), Large (L) and Extra Large (XL). Sizes that correspond intuitively to sizes of T-shirts.

Lets now imagine Bob executed 3 large tasks each week in the last month. We can now predict, with a relative good accuracy, that Bob will be able to perform 3 large tasks this week.

Great – we solved the overhead challenge for this simple case.

But what if we ask Bob to do 5 tasks with medium size. Will he be able to do that in one week?

We don’t know, because we can’t take a sum of different task sizes. That’s hugely impractical!

We need a better mechanism.

Story points

Lets stick with the principle of estimating work according to its size and complexity. But instead of T-shirt sizes, let’s use numbers: “story points”. So instead of XS, we can use ‘1 story point’, S is replaced with ‘2 story points’, and so forth:

For the sake of completeness, let’s also include uncertainty and knowledge as factors in the estimation. A high uncertainty increases the number of story points. A high level of knowledge decreases the story points. If Bob has to do a large task, but it is something he has never done before, we can account it for example to 8 story points instead of 5.

So a story point is a relative representation of:

• Volume: how much work is there to do?
• Complexity: how hard is the work?
• Knowledge: how easy is it for us to do?
• Uncertainty: what is unknown and a risk?

The higher the amount of story points per deliverable, the more time and effort it will take.

But what do we mean with relative?

Relative means that a story point estimation is given compared to previous deliverables. A story point has a different meaning to a different team. There is no absolute definition of a story point, because volume, complexity, knowledge and uncertainty have other meanings to other teams.

So when Bob estimates a deliverable to be 2 story points, it simply means it has a comparable volume, complexity, knowledge and uncertainty as previous deliverables of 2 story points.

Story points directly build on the past experience of a team, without the need to set up a complex time tracking system.

So simple, yet so powerful.

Story

Now that we know what a story point is, what is a story?

A story is simply a synonym for a deliverable. It is the final product of work, that will give value to the business.

Scrum teams use the term ‘story’ instead of deliverable. (more information)

Fibonacci

In the mapping table above, you might have noticed that we didn’t map the T-shirt sizes to a linear set of numbers. Large is mapped to 5 story points instead of 4 story points.

Why?

The higher the estimation, the lower the accuracy will be. It is a nonsense discussion to determine if a story would be 6 or 7 story points.

So we are not using every number for story points. We only use certain numbers for stories, the modified Story points sequence:

It is a modified Fibonacci sequence because higher numbers are rounded. For example, we use 20 instead of 21 as the latter implies a false precision that we don’t have.

A story point estimation of a deliverable will always be rounded to the closest figure in the Fibonacci sequence.

There is no such thing as a story with 9 story points.

If a story is in terms of volume, complexity, knowledge and uncertainty larger than 5 story points but smaller than 13 story points, it will be 8 story points.

Initial story points

The above explains how we can estimate story points relatively, based on previous deliverables.

But what if a team starts to use story points? How can they estimate relatively if there is no previous estimation to compare upon?

In order to start using story points, a team simply picks a small story on their backlog (a story that would intuitively take 1 day of development and testing combined is a good choice) and defines this to be the initial ‘1 story point story’.

Once this is defined, the team can define stories with similar volume, complexity, knowledge and uncertainty to also equal to 1 story point. Stories that have double the volume, complexity, knowledge or uncertainty are 2 story points large, and so forth.

Story points velocity

As mentioned before, we will measure how many work – expressed in story points – is done per team per time period (e.g. per two weeks).

Team velocity = number of story points / time period

For example, a team that delivered 5 story points last week, and 7 the week before has a velocity of 12 story points per two weeks.

As story points have different meanings per team team, velocities cannot be compared between teams.

So what do we use this story points velocity for?

If Bob and his team know their velocity (e.g. 12 story points every two weeks), they can efficiently estimate the work they will be able to perform the coming weeks: 12 story points per two weeks is the most probable forecast.

This forecasting can be shared with key stakeholders (other teams, business, management), to align on feature planning, release dates, marketing campaigns, etc.

Teams can also use the velocity figure to improve their functioning. They can use this figure in the retrospective meeting.

Example of story points velocities of a team with key ‘TLPRJ’ for previous periods.

Limitations of story points

Using story points sounds good , but what are the disadvantages?

The greatest disadvantage is the abstract notion of it. With proper coaching and support, a team can adopt it relatively easy.

But the challenge then lies in the communication between the team and the rest of the organization. The finance department and management still do their budgeting in dollars (or another currency), and the HR department still needs input on the presence and absence of staff in working days.

Using story points doesn’t replace financial budgeting and time tracking. But it can simplify it.

Story points and time/budget tracking

When you use story points, you are comparing future work continuously to previous work, and this without the need to track actual efforts of past deliverables.

This last point brings an advantage: it facilitates time tracking. Because we don’t need man-day actuals at deliverable level for future estimations, we can simplify time tracking mechanisms. Tracking and reporting actuals on deliverables can be time consuming itself, costly and even demotivating for creative staff members.

Which person likes to submit his time sheets? No one.

With story points we have a good reason to simplify timesheets to what is strictly necessary (e.g. for wage or invoice calculations). Communication with finance and HR departments can then still be done while talking in dollars and mandays. Those departments are usually only interested in the large numbers, not in the detailed estimations of each work package.

Conclusion

Scrum (software development) teams are using story points because it provide more accurate estimates by:

• Focusing on the drivers behind the work : volume, complexity, knowledge and uncertainty. One can explain – rationally – why a story is estimated to take more work than another story. This means an estimation can be discussed openly and factually in a team.
• Taking risk (uncertainty) explicitly into account.
• Taking overhead implicitly into account in the story points velocity.
• Comparing future work continuously to previous work, and this without the need to track actual efforts of past deliverables.

Organizations using story points use story points for work estimations, while still tracking dollar / man-days for global budgeting and HR purposes.

While heavily used in software development, story points might not be worth the hassle in other industries.

‍