The vision has been set, the awesome user experienced visualised; time to build. The project team gets together, and the sponsor energetically asks, “OK team, how much is this going to cost?”.

‍

The product manager and the tech lead nervously look at each other. A bead of sweat slowly drips down the senior developer's brow. Are they being asked for Estimates, or Commitments?

‍

What’s the difference? Let’s look at the dictionary!

‍

Estimate: “to guess or calculate the cost, size, value, etc. of something”

Commitment: “a promise or firm decision to do something”

‍

That seems pretty clear! So from where does the confusion arise? Let’s start with the process that most teams aspire to: Agile.

‍

The Agile Manifesto guides us to prefer working software over comprehensive documentation, but doesn’t really speak to estimation. Scrum tells us to use relative estimates, and to make it an iterative process while planning our sprints and grooming our backlogs.

‍

However, estimating is really hard:

• Tech moves quickly - even if you were to do the exact same function every 5 years, you would probably end up using different technologies every time.
• Application building has an incredibly complex supply chain, and each part of the chain can introduce bugs or complexity
• When you’re building a product, you’re probably trying to do something novel. If you’re not, then maybe this should be a Buy, not a Build.
• Open Source frameworks have revolutionised how we build applications - but it can be hard to know if there is something available, and more importantly appropriate, until you research it. Often the estimate is requested before this research is possible.
• We often don’t know what we don’t know. And even when we think we do, we are wrong. This really sits at the heart of the Agile movement. Even when we estimate every element accurately, things will change once we put into place our user feedback loops. Plus as we learn more about the product and the market, new requirements will necessarily emerge.

‍

‍

This difficulty has led to the “No Estimates” movement - even endorsed by one of the authors of the Agile Manifesto, Ron Jeffries. The argument basically revolves around the idea that the more time we spend creating (often wrong) estimates, the less time we spend shipping code. And anyway, it will be ready when it’s ready, so we might as well just get on with it.

‍

But estimating is important. Stakeholders need some kind of idea of what they’re funding, and to make priority calls. Denying this, as the ‘purists’ do, is naive - especially given those same technologists inherently estimate everything automatically, but a business user might not realise that their request to “integrate partner X’s API” is never quite that simple.

‍

However, we need to agree that Estimates are not Commitments. Everything breaks down when the two become conflated.

‍

‍

This immediately breaks psychological safety for the team. They were working as hard as they could, but they were distracted by an emergency production upgrade that was needed. They didn’t realise how complex the problem was. The open source library they used had a bug. They hadn’t really taken into account that half their time is spent in meetings, and the other half is spent trying to regain flow.

So what do they do? They avoid honest estimation at all costs - they don’t want to be held to them. Fundamentalist “Agile” values are cried out: “estimating is evil!”. Ridiculous estimates start being given: “ooh, changing that button will take 5 weeks”.

‍

The conflation of Estimate & Commitment becomes even more pronounced when dealing with vendors and partners. The same organisation that makes a big deal about their agile practices turns around and asks for fixed pricing for a complex & early stage piece of work from their partner. Choose a partner you trust, and use Estimates just as you would your own team.

‍

We cannot give up on estimates. They are an essential part of our craft. But things we can do:

• Ensure alignment with stakeholders that these are Estimates, not Commitments.
• Don’t spend the entire retro talking about why an estimate was ‘wrong’. Get back to building.
• Be self-reflective, was there an opportunity to improve your estimate?
• Use ranges, not specific points. Reality will almost always be closer to the upper range, not the median.
• Break down the larger pieces into smaller ones. An interesting exercise is to compare the sum of the estimates of the smaller pieces with the estimate of the larger one. Spoiler alert: it’s probably much bigger!
• I have previously written about the concept of the fixed cost/scope six week Surge Sprint, and perhaps something like this is the answer - especially for vendor agreements.
• As mentioned in the Surge Sprint - when faced with highly ambiguous estimations, do a quick prototype first. A week of actually trying something will improve your understanding way more than trying to gather more requirements up front.

‍

‍

If you’re pre Product Market Fit, then it’s even more important you don’t spend excessive time worrying about estimates that are often wrong, or why they were wrong. Spend your time shipping code and getting feedback.

‍

The tension between estimates and stakeholders who need to know how much to budget remains a critical challenge. As with so much in life, communication is key.

‍

When updates are clear, delays well communicated and trust established, the need for iron-clad commitments is reduced. And stakeholders, please understand that your team is doing its best - admonishing them for inaccurate estimates destroys team morale. Building great product is a team sport.
‍

Happy building!