Agile — Why, When and How to Estimate


Estimating is a very common concept in Agile, especially in Scrum teams, which usually estimate their product backlog and sprint backlog. Estimating as a concept makes quite a lot of sense, without it life would be pretty hard and surprising.

Estimate, Agile, nature, trees
How many trees are in the picture? How many leaves?
Estimating can be hard. Why, when and how should it be done?

This article is also available on Medium.

Estimations are done and used in many different situations. How long will something take? How much will it cost? When will it be ready? What will bring the most value with the money I have?

Estimation is not about getting the exact answers, but answers that are good enough. Creating an understanding of what result an action or decision will lead to is important, especially in business life. And why is this?

Why Estimate

Estimations can save time and money. They can give answers to when something can be delivered, how much can be delivered and how much resources would be needed.

It also helps in prioritizing work and in making decisions. Even if something would bring a lot of value, developing it might not be valuable if it takes way too much time.

The tricky part with estimates is that quite often, especially in business life, estimations are treated as exact numbers or promises. I’ve experienced too many times at my work as a consultant, that team’s estimations have gone wrong and afterward, management sits in meetings pondering about why this happened. Understandable, as usually a lot of money is involved. 

But in that case, we’ve missed the root cause for the challenges and are focusing on wrong things that will just generate waste.

Therefore, it’s important to think about how estimations are done, when and what units to use.

But first, we must acknowledge, that estimations should be treated as estimations. Estimations can bring value, help in decision making, prioritizing and give predictability. But they can also be big pain points in organizations and cause a lot of waste.

So, when should we estimate and how should it be done?

Product Backlog

The product backlog contains different types of work and functionalities desired by the product. There are a few good reasons for estimating the product backlog.

  • It helps teams to make predictions about how much can be delivered and when.
  • It aids in prioritizing work. Especially product owners (and managers) will find it beneficial.
  • Risk management and fewer surprises. Teams become more familiarized with upcoming work if they have so much knowledge about the requirements that they can do actual estimations.

Let’s say then that you should estimate the backlog for a year or one quarter. These kinds of estimations can help in decision-making and resourcing. Should a project be started or not? What are the priorities? Do we need more people?

Note that there more exact you try to be with your estimations, the bigger the risk that the estimate will be inaccurate. Trying to give very specific estimations for a lot of work is also very time-consuming. Trying to estimate a project in hours or days might be very inaccurate if the requirements are not known.

Hence, it doesn’t make sense to estimate hours or days for long periods. It’s better to use story points or T-shirt sizes instead. This will give an idea about the future workload and the type of work. Are there big, time-consuming features in the backlog? Or maybe there are many small tasks that need to be worked on? What kind of expertise would the team need for upcoming work?

Sprint Backlog

The sprint backlog consists of tasks that the team will complete during a sprint. Estimating the sprint backlog brings value because

  • It helps to determine how much work to bring to the sprint
  • It identifies different tasks and estimating them helps in coordinating the work

When estimating the sprint backlog, it makes more sense to use hours or days compared to using these units for the product backlog. The sprint is much shorter and contains fewer items, so being more specific is acceptable. Note that it’s not a must, but something that can de done.

Estimating the workload for a sprint will help the team in planning. The team plans who will work on what items, see if there are some dependencies and the team can assess the workload. As the timeframe is shorter, it makes sense to be a bit more accurate with the estimations.

When To Not Estimate

Estimations should not be done if the work is way too big anyway. If the requirements are unknown, you must first invest time in understanding what is needed for the feature. Only then is there any reason to estimate. Otherwise, it’s just guessing, which is not the same thing as estimating.

There is usually no need for estimates if the team is very mature and the product itself is already established, mature and predictable. Additionally, if the team is in a flow of predictability and the product is in a repeatable cycle of life estimations can be a waste of time.


It’s good to remember that even though how accurate estimations would seem, they’re still estimates. They’re not deliverables nor a velocity. Not a promise. Not a fact.

But estimates are not waste either if done correctly. We just need to think a bit about how we do them, when and why.

Tue kokonaisvaltaista hyvinvointia

Auta minua kohentaamaan muidenkin kokonaisvaltaista hyvinvointia jakamalla kirjoitusta. Jos kirjoitus herättää ajatuksia tai kysymyksiä, voit jättää kommentin tai ottaa minuun yhteyttä sähköpostitse tai sosiaalisessa mediassa.

Lue myös :

Read more

Vastaa