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

Albert Starreveld
7 min readDec 2, 2020

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?



Albert Starreveld

Passionate about cloud native software development. Only by sharing knowledge and code we can take software development to the next level!