Why your estimates will never be correct, and what to do instead
“Under-commit and over-deliver.”
I’m sure many of us working in knowledge-based fields have heard this advice before.
The principle seems logical: give a lower estimate for what you think you can complete in a given timeframe, and rely on the fact that you will be able to deliver more than committed.
It’s advice given to young consultants looking to impress their seniors.
Or to teams creating sprint backlogs to help their velocity recover.
Or project teams estimating how much of their project will be completed this quarter.
Now there’s probably several arguments for why this isn’t the best advice. (Are you being dishonest with your capacity? might be one)
It does persist because it’s better than the alternative: over-committing and under-delivering.
But in my experience, the biggest problem is that the outcome of these two approaches is the same: a team or individual team member is unable to deliver what was promised in the timeframe promised.
Even with the buffer time implied in the idea of under-committing, so often we end up overshooting our estimates.
Why is that?
The answer is found in Hofstadter's law. This eponymous law states:
A project always takes longer than expected, even when Hofstadter’s law is taken into account.
Coined by Douglas Hofstadter in the 70’s, this law attempts to explain why it is so hard to estimate complex tasks.
Because even when we allow for the unexpected and buffer our estimates, tasks tend to take more time than we estimated. In part this is because the sheer number of variables and unknowns involved in the type of knowledge work that dominates knowledge-work fields like professional services and technology. (Although I’m sure Parkinson’s law also has something to do with it.)
So if it’s impossible to create estimates that we can hit, what do we do instead?
We can use appetites. I first learnt about this concept in Basecamp’s book Shape Up. The appetite is a statement about the amount of time a team is willing to invest in solving a particular problem.
Instead of defining a solution and estimating how long that solution will take to build, define the problem that needs solving and define how long you’re willing to spend on solving that problem.
There’s more to this approach, such as being ruthless with defining and managing scope, and sticking to your appetite when it’s time to stop. I definitely recommend reading Shape Up for more details and examples of how this is applied to software development. It’s available for free on the Basecamp website.
If you want some ideas on how this applies in professional services or internal functional teams, hit reply or message me on LinkedIn and I’d be happy to share my thoughts on how this approach could work for you to end the days of overshooting your estimates.
