When most software teams estimate, they are answering the wrong question. This causes all kinds of problems, but when we understand why it’s the wrong question, and what a better one might be, that should no longer be a surprise. The question most teams answer is a variant of “how hard will it be/how much will it cost/how long will it take to do this thing”.

I should first point out that estimating is absolutely not necessary if you are asking and answering the right questions in other ways. The million-dollar question (often literally) is: “We’re spending a lot of time and money building software, how can I be confident it’ll deliver what we need?”. The best answer to this question is not an estimate or any kind of theoretical or non-tangible thing: the best answer is real results. That means working software, in the hands of real customers, and data that shows that the software meets the needs, and that business objectives are being met. Anything else is a poor surrogate for that. If there is confidence and trust that a team are delivering results – and outcomes – on a regular basis, reliably, then people won’t need to ask for guesses of when that might happen, because they already know. That’s not to say you must not estimate – if it genuinely helps you in some way, then go for it, but you’d be doing so because the team choose to for the team’s benefit, which is not common.

A mistake we often make in software is ignoring the real world(!!), where many of the problems we encounter already have very elegant solutions. For example, I like guitars, and my favourite guitar store is Andertons (check out their amazing YouTube content!). There are 3 key things on their web page that I want to focus on:

There’s always more than one option, so that you can choose the one that might fit best. In software, we can do this by resisting the temptation to lock down specifications and designs too early and trying to come up with multiple ways of solving any given problem.

You can filter out options by cost, to only the ones that match what your budget is. In software, we can do this by thinking about how much a problem is worth before deciding to solve it at all, and by then treating that as a budget, where we only consider solutions that match that budget.

You can sort by cost, so you can see what you get if you spend slightly more/less. We can take the options we’ve come up with, and have a discussion where we explore which parts of them we could combine to give the most value within our budget. This might be things like deliberately only building part of a feature at first, especially if the “add-ons” are where the complexity is – perhaps a search box, with or without autocomplete for example.

Andertons also do an excellent series of videos with titles like “Sound like <your favourite band> without busting the bank”. Let’s just pretend that the one for Nickelback isn’t there. The premise of these videos is very simple: take a well-known artist’s sound, and try to come up with a set of equipment that can get as close to that sound as possible within a fixed budget. What you’ll nearly always find is that the results are very impressive.

And of course, something else you probably want to do – especially if you’re thinking of buying something more expensive – is to actually try out the options before picking one. If you have chosen one of the ideas to try out, that doesn’t mean you need to see it through to the bitter end come what may! Don’t be afraid to step back and re-evaluate whether a design or option is working for you, at any stage, and try a different one instead.

So, if you are currently asking “how hard will it be/how much will it cost/how long will it take to do this thing?”, try changing the question to “given this outcome is worth ___ to us, what are some of the options to achieve that outcome within that budget?”, and see if you can try the options out cheaply. It’ll open up all sorts of new possibilities!