How I think about estimates

In one of my previous posts I talked about what Happy path engineering is and how understanding the time to implement plays an important factor in that.

So, if time to implement is important how can we get better at estimating the time we need and how can we help others understand the benefits that estimates bring (and, the often, innacurate nature of them)?

I have heard a lot of different opinions about this over the years by a lot of people, with different backgrounds, skills, seniority and experience:

  • estimates are hard
  • estimates are never accurate
  • we don’t need estimates we are working in an agile manner
  • we don’t need estimates we only need a list of priorities

And to be fair I have found that there is truth in all of these statements. Yes estimates are hard, yes we don’t always get them right, yes we do want to have a clear list of priorities that we can adapt as we go. But all of these still don’t mean that estimates are a bad thing to aim to get right or that they don’t genuinely help us make better decisions every single day.

How estimates help


One of the most important things that estimates help us with is planning for our time and our team’s time. There are always a lot of things that we can be developing and this is part of the fun of being an engineer 🙂. Estimates can help us priotise and understand roughly where we could be in X amount of days, weeks or months. Can we actually realistically get there is one of the questions that we can help answer.

Making trade-offs

They affect our technical and non-technical decisions. For example if you estimate that producing a solution to cover a particular requirement will take up your team’s time for the next 5 months you may decide to evaluate other solutions or even changing the requirements a bit.


Another important factor, if we can’t meet our goals and we can’t cut down scope then what do we do? Here is where estimates can also help us with additional support. By the way it’s not uncommon to need additional help either by someone with skills that your team does not currently have or by other engineers.

Estimate levels

Estimates apply to different levels. If you are a Tech lead or Manager and you are leading a project for your team, then the estimates you produce may affect the decisioning process of many engineers, your whole team or even your company.

At a macro level

At this level there is usually a lot more ambiguity and uncertainty about how to go about producing a “good enough” estimate. A few quick tips on how to practise this on a project basis:

  • at the beginning of a project produce a rough estimate of the work you anticipate (this helps with longer term planning for the team)
  • if there are high levels of uncertainty then do a targeted spike to remove unknowns
  • at the end of the spike re-evaluate and set mile stones for the work

At a micro level

As an individual contributor working on a particular ticket or feature you can practice this even on a ticket basis. The next time you are about to start something new:

  • set an expectation for yourself of how long you think it’s going to take
  • do the work as you would normally do
  • look back and see how far you are from what you thought and see what was unexpected

By doing these simple things you will see so much improvement (and so quickly as well) that you’ll be surprised !

Anti-patterns / Things to avoid

The most common anti-pattern I have seen and a common reason why a lot of people do not want to provide estimates for their work is that the initial rough estimates are often converted to deadlines that they simply can’t meet. This not only creates a lot of unnecessary pressure but also significantly reduces the team’s moral as people constantly feel behind the plan.

Another anti-pattern is massively overestimating the time to implement to avoid being pushed in a conrner with deadlines. This I would say it’s a defence mechanism to the first malfunction of treating initial rough estimates as deadlines.

And finally another anti-pattern is becoming to rigid on the estimates and missing the point that estimates are there as a guide and there is no way to completely avoid anything unexpected happening. How we react to unexpected issues and use estimates to guide our decision making is what we should be focusing on in these cases.

Final thoughts

Estimates are a skill that you can definitely develop. The more you consciously work on it the better you become and the more confident you can be to bring others along with you.

Leave a Reply