Estimates that build trust (not stress)
Developers hate estimates, yet we keep getting asked to create them. This isn't a paradox; it just means we don't understand the tremendous value that they can create.
I think this is because of two fundamental misunderstandings that we have about estimates:
That the most important information in an estimate is the number of hours it will take to build something.
That estimates are an artefact that we toss over the wall to stakeholders so they can approve project budgets.
If you want to turn estimation into a practice that will create value not just for your stakeholders but also for your development team, you'll need to confront these ideas and turn them on their heads.
1. Estimates quantify risk, not effort
Stakeholders aren't naïve. They understand just as well as developers that every number in an estimate is held up by a rickety scaffolding of unknowns, assumptions, and contingencies.
Where we run into trouble is we hide away those unknowns, assumptions, and contingencies and try to pretend as though they don't exist — and then stakeholders take us at our word.1
It's time to break the chain. When you're estimating, take all of those assumptions and risks that could potentially cause that number to change, and write them down along with the estimate.
Are there any requirements that are unclear or likely to change? Note them down.
Any dependencies or integrations that might not be compatible? List them.
Will you need to touch the legacy codebase that falls over every time someone so much as gives it a quizzical look? Don't keep it to yourself.
And so on.
Once you start doing this, you'll notice two things:
It will become obvious just by looking which are the riskiest parts of the project. The deliverables with the most (or scariest) assumptions backing them will stand out as the most risky.
You'll start spotting opportunities where the organisation could potentially invest in reducing some of that risk. Many unknowns can be explored, assumptions validated, and risks avoided simply by spending a few hours on additional discovery work.
On their own, these are two extremely important insights that your estimates can create for you. But if you want to unlock the true value of an estimate, you need to understand that...
2. Estimates are the start of a conversation, not the end of one
Developers often make the mistake of thinking of an estimate as a deliverable: stakeholders are asking us a question, and we give them an answer. Job done.
Then we go off and do the real (i.e. development) work, and no-one ever speaks of that estimate again...that is, until towards the end of the project when the stakeholders pull it up again and demand to know why we're so far off.
We need to squash the mode of thinking that estimates are something that developers create for stakeholders. An estimate isn't a deliverable — it's a framework for having constructive conversations about risk.
When you bring forward your perspective of where the most risk exists in the project, and stakeholders bring their perspective of where the most value can be created2, it facilitates making key decisions such as:
Valuable but risky deliverables where it makes sense to invest in some additional discovery to de-risk them
Risky and not-valuable deliverables that we should drop from the project entirely
Estimates with low certainty/confidence where it's worth spending additional discovery hours to map out some of the unknowns3
And so on.
Once you start having these conversations and making strategic decisions with stakeholders, you'll notice that you're more reliably avoiding major issues and changes that used to cause your projects to completely blow out their estimates. You'll stop getting pulled into obnoxious "please explain" meetings...and who knows, you may even find that your estimates start getting more accurate.
Oh, they may raise an eyebrow during the planning phase of the project, but that's as much goodwill as you're going to get. By the end when the project has way overshot its budget and timelines, you can be sure then that you're not going to get the benefit of the doubt.
Engineering also has an important perspective on where the value creation potential exists, especially where it reduces system complexity and enables future initiatives. For simplicity I've omitted that here, but you can imagine just how multi-faceted these conversations about risk and value can get.
By the way, this is a really good way to resolve those pesky "how long is a piece of string" estimation challenges.