We now know many things estimates are not.
But then, what are estimates, actually? And what are they really for?
The Oxford Dictionary says that an estimate is “an approximate calculation or judgement of the value, number, quantity, or extent of something.”
In our case, the approximate calculation or judgement of the amount of work needed to achieve some specific outcome using the most effective approach available.
But why do we care?
There are a few reasons.
First, they surface obstacles, complications and uncertainties as we develop.
Suppose you have a work item you need to work on. When you start, you estimate it will take you, say, one week to complete it fully. Yet after three weeks you’re still working hard on it.
Should you just keep going and push through?
The answer is, it depends. Did something happen that changed the picture? Did you discover something, as you were working on the thing, that made the job many times more difficult? Are you blocked on some external thing?
Without a baseline expectation, it’s impossible to know if we should reevaluate the priority of the task or even if we should do it at all.
Second, it helps the team analyse the problem
“We can just implement our own operating system, doesn’t sound that complicated.”
Engineers are optimists by design. They think at a high level and ignore the myriad of details and implications of a project. They just want to go build stuff and do it well. That’s exciting.
So, when the ask is, “go from Los Angeles to New York”, they’ll picture the map of the US, and think: “well, it’s about 4000 km. If I drive at 100 km/h, I can make it there in 40 hours. Let’s say two days, to allow some buffer.”
Estimating the actual work, however, acts as a forcing function: you need to consider traffic, fuel stops, eating, sleeping, and the fact that you can’t really drive in a straight line across a continent.
Whatever number of actual days you come out with, you will have gained some clarity on what needs doing and can decide early that maybe driving cross country isn’t a great plan, and flying instead might be better.
Third, dates and reliable delivery matters to the business
Pretend you’re having your bathroom remodeled.
The renovating team shows up, and says: “we’re going to start tearing stuff out. We don’t know when we’ll finish. I guess we’ll be done when we’re done”.
I am ready to bet that you won’t hire that team.
Yet, you sometimes get software teams asserting exactly that: “we don’t have an estimate, we’ll finish when we finish”.
That’s fine maybe if you’re working on your hobby project: then, the craft is the goal, not the outcome necessarily.
In business, however, it’s not just about what you deliver, but also when and how. Your project might be something leadership has committed to to unblock some customer, or some dependent team. Or you might have a small window of opportunity to deliver the outcome. For example, a launch event, or a conference, or some other event after which your work loses value.
As a manager, I need to know when we’re expecting to be done, and possibly negotiate different scope or different dates, or do some other resourcing magic behind the scenes to ensure things are happening as reliably as possible.
Without some type of estimate, we can’t commit to having anything done by any given time. That kind of sucks.
So, go estimate your work!
How you ask? Well, that’s next.