This post will take me two story points to write

Why do we estimate?

Are you chasing accurate estimates? Do you see an inherent problem in that? But more importantly, do you know why you’re estimating? I’m a firm believer that until you start the implementation phase of a given initiative, you truly won’t get a good idea of how long something will take. Yet, we often try to estimate with very little information. Truly, estimations aren’t the problem, it’s the expectations that we attach to them.

Real life doesn’t play well with estimates

There are so many reasons why you won’t hit your estimate. GitHub goes down, your kid is sick and you have to stay home, the API docs for a service you’re integrating with are abysmal, there’s a critical error that has to be addressed—or simply, you find yourself week after week having a profound appreciation that software development is tricky, requires patience, practice, and dedication.

Estimating takes time

The irony with estimates, is that the act of estimating takes time. Time away from active development. So the more estimates we request, and the more accurate we want them, the more distraction we create for our teams trying to do quality work in meaningful and impactful ways.

That’s the catch 22 many organizations struggle with, as they want clear expectations on delivery that then help contribute to new delays, creating a vicious cycle from which it’s difficult to escape.

Estimates turn on us quickly

A key problem I see estimates are that they are usually being used as shields that all of a sudden turn against the estimators. Usually it’s done to appease expectations from outside the product development organization. “Let’s just get these estimates to get the business off of our backs”.

Estimates are always, the best guess at the time. Yet, we forget that so quickly and those loose guesses quickly get entrenched in unrealistic expectation. We also have to recognize that these expectations often come without giving development teams the opportunity to truly understand the work needed to be done, and not heeding their expertise.

This in itself is one the largest problem with estimations, which begs the question, what value did they bring if they can repeatedly be used to set unrealistic expectations?

What is the value of estimates?

In speaking about estimates with software developer and author, Stephen Belyea, he highlighted a positive upside of estimating. When done well, it can be the catalyst to the necessary discussion that brings a better understanding of the root problem being solved, and uncovering unanswered questions and missing information. If estimates help in that regard, that’s great.

One word of caution around this though — you can achieve this level of understanding without the act of estimating. If there is a need to better understand the work, estimates themselves are not the outcome that is required — it’s a shared understanding of the problems being solved.

If this sounds like I’m slamming estimates, I’m not. What I’m proposing is to carefully consider why estimates are important and why they are being used in your organization. They can be catalsyts to great and necessary conversation, but they can also be used as failed defence mechanisms. Understanding the root of why we need estimates I think will help us become better development teams.

Oh, and by the way. I wildly underestimated this Medium post. Definitely not a two-pointer. I’ve been coming back to this draft for almost four years now and it has changed and evolved so many times before finally publishing it.