A very common question from teams starting out with Scrum, is that about story points vs hours. How is estimation done? Can we use hours instead of points? Isn’t it the same thing? (Hint: it’s not.)

Before we proceed, I would like to make it clear that there is no definitive, general answer to how estimation should be performed, or whether you actually should be doing estimation at all. Every team must find its own answer. However, I find that the following is a good starting position.

And to get us going, we should start with the ”why?” before getting to the ”how?”.

Story points

Story points, or just points, are used in Scrum to estimate the complexity of an item in the product backlog. The estimation are typically done during refinement meetings or at the sprint planning meeting at the latest. Poker planning or swim lane sizing are common estimation methods. The purpose of the estimation is not only to get a complexity estimate – and therefore help the product owner in prioritizing – but also to check that the team has the same idea of the effort involved. The estimate is then used during sprint planning by the team to know how much work to commit to for the upcoming sprint, perhaps based on the number of points done during previous sprints.


Hours are used when estimating the tasks that needs to be done in order to reach the acceptance criteria specified in the product backlog item. If the remaining effort on each task is updated regularly during the sprint, it is possible to create a burndown chart that visualizes how much work remains to reach the sprint goal.


Story points Hours
Estimate of… Complexity Work
Estimated at… Refinement meetings Sprint planning
Can be used to answer… How much work can we manage in a sprint? How much work remains in a sprint?
Are updated… Never; or possibly at start of next sprint if not done. Regularly.

There is no conversion factor between points and hours. Never. Ever. There is a correlation between the two, however. You would expect an item with small complexity to have tasks that sums up to a small amount of hours – but this does not always hold.

Misusing the estimates

It might be tempting to reuse the hours estimate for other purposes than the one stated above. For example, you might feel tempted to grab the number of hours from a number of tasks, multiply by some hourly rate to get a cost estimate. That is a bad idea, since that was not why the estimate was made. In fact, any idea to map the hours of the task estimates to any other measurements of hours, such as the team’s available hours, is probably a very bad idea. If you need such an estimate, ask the team explicitly for this.

Story points and hours

Do we need to do both story points and hours?

If you do not care about how many points you commit to, but instead use some other method (perhaps your gut feeling?) to know how much work to put into a sprint, then you do not need points. Beware, however, as it is quite likely that you will miss out on necessary discussions during refinement meetings.

If you do not plan to visualize the amount of remaining work, or use some other way of visualization, or if you are unable to regularly update the remaining effort, then you do not need hours.


Each agile team must find its own way in doing estimates (if at all), but to avoid the common pitfalls you should understand how Scrum has been implemented before. Story points and hours are used in different circumstances, and the estimation for product backlog items and tasks have different purposes. Be aware of this.

And when someone asks you to estimate the entire backlog in hours, remember to ask ”why?”.