When we give a size-, effort- or time estimate, like “5 Story Points”, “7 ideal engineering days”, “this will be finished before End of May”, what does that actually mean? And how useful is the number?

That depends on what question we are actually answering with that number…

But We’d have to Know the Future…

Some people argue that, in order to estimate accurately, you need a time machine: Only when you know the future, you will be able to make accurate descriptions.

But that’s a classic straw man: While the statement is true, it completely misses the point. The estimates are not supposed to predict the future accurately. They are meant to be another data point for our decisions.

Other Factors

Our estimates will always be “wrong”. No matter how much time we invest.

We can never fully anticipate all the things that might go wrong during development. Or how often we will be interrupted by more urgent stuff. Or how our software architecture and design will have changed when we start. Or how third party systems will behave.

When we get better at producing high-quality software - get better at “crafting software” - some of those factors get smaller. But they never go away.

But We’d have to Specify Exactly…

This is something I hear from teams a lot. “Let’s write down what we discussed before we estimate, so that later, we will implement exactly what we estimated”. So, the team here wants a very exact, detailed specification before giving an estimate, to make sure the number is as “accurate” as possible.

That behaviour comes from our own perfectionism and from fear of the consequences of wrong estimates. Both are very real, and both probably highlight some major cultural problems in this team and company.

Specifying, in great detail, when producing an estimate will prevent them from working in a truly agile way.

But can they even estimate, without knowing the future, without knowing everything that might go wrong, and without even knowing exactly what they’ll have to do?

Some Version of That Feature

Everything we do has an expected benefit for at least some of the stakeholders. Hopefully without annoying some others.

When there is so much uncertainty - no clear, exact specification, all the other factors - an estimate cannot mean “We will deliver exactly that feature within roughly that time frame”.

But it can mean “We are pretty confident that we can deliver some software that will bring most of the expected benefit within roughly that time frame”.

When we learn to create features iteratively, we will have a first version of the feature ready long before the time is up. And then we can focus on adding more and more of the expected benefit.

Are there Other Ways?

Our estimates will always be “wrong”. No matter how much time we invest. So, is it even worth creating them?

Also, when we use the definition “some software that will bring most of the benefit”, there is always the danger that some people “misunderstand” us (sometimes even deliberately) and turn our estimates into commitments.

And the usefulness of our estimates also depends on what kind of software we produce and where we are in the life cycle of the project.

But I will write about that later. Today, I want you to review what an estimate means in your team. And discuss whether this definition is useful within your context and what you can improve. And if you are allowed to, please tell me about it!