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
One of the key aspects of Scrum/Agile is continuous learning and continuous improvement. By working in sprints, stopping every two weeks to retrospect and find improvement points, the team gets better and better at what they do. As a result, the team needs less time to perform a similar task.
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
It all starts with a different perspective. Yes, it makes sense to make a forecast based on the amount of time we think the work will take. But isn’t it smarter to base our forecast on the time we really spent on similar work? A forecast is a lot more realistic when it’s based on facts rather than assumptions.
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:
Average velocity and the sprint-planning
Switching from hours to size impacts the sprint-planning. When you’re working with hours, a planning-session is simple: just keep adding stories until the hours it takes to complete the stories equals the capacity of the team.
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
The velocity of the team is never constant. It fluctuates. And that impacts planning. Ideally, a team has a continuous pace. By dividing the amount of work on the backlog by it, you’re able to predict the moment in time when the product will be delivered.
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.
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:
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:
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:
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!
When working with user stories, the team has to estimate the effort it takes to complete it. Imagining the number of hours needed to perform the task seems the easiest way to do so. But by doing so, you’re taking away the ability to measure the efficiency of the team, and you’re taking away the product owner’s ability to come up with accurate planning!
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.