How to use story-points, velocity, and the cone of uncertainty to deliver in time

Estimating a story in hours is common practice. But often, estimations in hours prove not to be accurate. How much time it takes to complete a task depends on a lot of variables. There’s a better way. Estimating stories by size rather than the time needed to complete it, results in more reliable planning, and allows the team to respond when their pace slows down.

It’s easy to estimate the number of hours it takes to complete a task. Everybody can do it. It might even be the easiest way to estimate. So, if that’s not the way to go, then how do you estimate? And if you don’t know how much time it takes to complete a story, then how will you know when you’ll deliver the product?

Why hours don’t work

But teams don’t always improve. Sometimes the efficiency of the team drops. As a result, they deliver less in a sprint. And that’s fine! As long as you’re aware of it. Then you’re able to respond.

The amount of time spent on a task is meaningless if the size of the task is unknown. That’s what story-points are for! By measuring both size and time, rather than just time, the efficiency of the team becomes visible. If the size of the completed work over a given amount of time increases, then the team got more efficient, and visa versa. As a result, you’re now able to see when the project is in danger, and you’re able to respond!

How to estimate a user story

To be able to do so, you’ll need the size of a user story rather than the time you think it will take to complete it. But that leaves many teams with a problem. Size is abstract. Everybody can estimate how long they think a task takes, but how do you estimate the size of a story?

There are several exercises and metaphors available on the internet to get a better grasp on “size”. The fruit-salade technique, for example, or the dog grooming salon exercise.

The “size” of a story depends on the number of unknowns in it and the difficulty of the task. Use this flowchart to get to determine the size:

Use this flow-chart to estimate the size of a user story.

Average velocity and the sprint-planning

To determine what the size of the sprint will be and what the team can commit to when you’re not using hours, you need to know how much work they've completed in the past. Most teams use the average of the story points that have been completed in the past four sprints to decide what they can commit to. They keep adding stories to the sprint-backlog until that number is reached.

Ideally, the amount of story points a team completes in a sprint is always the same (or just slightly different). If there are big differences in the velocity, every sprint, that’s an indicator the team isn’t functioning well. Usually, one, or multiple scrum-anti-patterns are the cause of it. Address them, and fix it!

The average amount of story-points a team completes in a sprint is called the velocity of the team. Velocity literally means the distance covered towards a goal over time. How long it takes to get somewhere depends on the distance that needs to be covered and on the velocity with which you’re traveling. Scrum works the same way: the average velocity is used to forecast when the product will be delivered.

The cone of uncertainty

This is visualized in the graph below: The blue line represents the amount of work that still needs to be done and how it decreases over time. When the amount of work is 0, the project is done.

If all goes well, and the velocity is a constant, you’ll deliver in September

In a perfect world, everything goes as planned. But the world isn’t perfect. The velocity can drop after a couple of months because of increasing technical debt, for example. Or because there’s a new team member. (Yes, increasing team size may cause the velocity drop.) All of a sudden, you end up delivering in November:

Technical debt increased, you’re going to deliver late!

As the graph shows, you’re going to deliver late because the velocity dropped. So, respond to change! These are your options:

  • Your first option: Restore the velocity. Find out what’s holding the team back, and fix it! (Reduce the technical debt, for example.)
  • Second option: Reduce the number of features that will be delivered. Less work takes less time to complete. In this case, you’ll probably drop the features that are nice to have.
  • Tell the customer you’ll deliver late.

Life’s not always bad. After reducing the technical debt, for example, the velocity may increase. All of a sudden, the burndown could look like this, and you might end up delivering early:

And eventually, you might end up delivering early.

You’re in charge. There are several variables you have an impact on. By monitoring and responding to the velocity, you’re able to take charge and deliver when you want!

But you have to embrace that when a project starts, there’s no way of telling when it will be done. There’s always an optimistic scenario, a pessimistic one, and everything that’s in between. (This concept is known as the cone of uncertainty)

By making a forecast based on the sizes of stories, and by taking the average velocity, and by embracing the fact that it might decrease or increase, you’re able to make the following picture:

The orange line represents the optimistic scenario, the blue line is the “happy scenario”, and the gray one is a pessimistic scenario…

it’s safe to say that in this example, you’ll probably deliver somewhere between August and November. By monitoring the velocity of the team, and carefully choosing the work that needs doing first, you are the one that decides when the delivery date is!


Think about it: to keep the estimates accurate, the team would need to re-estimate every story on the backlog if their efficiency changes. Only then will the product owner be able to tell when the product will be done!

It doesn’t make sense to measure the number of hours a team burns. It’s a given. Everybody on the team has the same amount of hours to spend, every week. The number of available working hours in a print rarely changes. It’s what the team does with that time, what matters!

Instead, focus on the size of a story. Measure the size of the work delivered by the team, every sprint, to measure the performance of the team. Based on the amount of work they average, the delivery date can always be calculated. By keeping track of the delivery date, every sprint, the project team can respond to changes in the performance in the team, and thereby the chances of delivering in time significantly increase.

software developer / consultant @

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store