How to Use Estimates for Software Development

I originally posted this on my blog a few years ago. I decided to reshare this here after conversations with a client about choosing a system to estimate the work building a backend for a mobile app. We were discussing what a healthy estimating practice looks like. Let’s talk about the right way to use this tool.

Why talk about estimating at all?

Software development teams often have no idea what the work really will be until they do it. Give a sculptor a block of wood and they’ll have to work carefully, as they uncover the imperfections within the wood. How long will it take to reveal a bust of Artemis drawing an arrow? The sculptor doesn’t really know beforehand.

Yet, there is value in having a way to know at a grander scale how much work can be accomplished. Evaluating this allows us to discuss how much work can be done before a given deadline, as well as the overall health of the team (through changes to this measurement over time).

What is an estimate

An estimate is a representation of the team’s understanding of the complexity of the work required to accomplish a desired feature. Since it is done with imperfect knowledge, it will be wrong. That is why it is called an estimate.

In order to separate the idea of estimate from the idea of “how long this work will take”, the estimate is not given in units of time (e.g. an hour, a day, two weeks…). Since the idea of an estimate is to represent complexity, time does not map well. Some teams use t-shirt sizes (S, M, L, XL), some teams use the Fibonacci series (1, 2, 3, 5, …). Each unit of work would then be given such a “size”.

Estimates over time

The velocity

An estimate can be understood, then, as a completely wrong and overall meaningless number. So why is this a good idea? When you have time boundaries (note: kanban users, this is your cue), you can stack up the value of the estimates of the units of work accomplished over that period of time and get a number called velocity. The velocity tells you how much complexity of work the team has gone through in a given period of time. Remember: this is all based on a number which we know to be wrong and meaningless, by definition.

Attaining self-consistency

So far, this all sounds like a load of hard work for no reason at all. So why is this a good idea? Over time, a team which is allowed to generate its own estimates based on the units of work they receive will gravitate towards a self-consistent system. This means that units of work will be understood to relate to each other based on complexity (e.g. “Remember when we did X? This is the same kind of work, isn’t it?”)

The value of self-consistent estimates

Over time, this means that velocity will also become consistent. It will become a wrong and meaningless number created from other wrong and meaningless numbers. However, at this point in time, the team has something it did not have before: self-consistency. The numbers will be wrong in the same way. I have worked on teams where the velocity was 4 and teams where the velocity was 78. This means that over time, the stable number obtained based on accomplished work complexity during a unit of time turned out to predictably be this number. This says nothing about “how fast” or “how slow” the team got work done. It does mean that after estimating a new feature, the team could then have a conversation about the translation of that number to the unit of time.

How estimates fit in the team’s process ecosystem

This can then lead to discussing scope. In the first case, that feature translates to a relatively short amount of time. In the second case, it is a choice that will have significant impact (no other work can happen during three units of time). Estimates will always be wrong; that’s why they’re called estimates. As long as the team is allowed to estimate the work without external pressures, the team will eventually gravitate towards a self-consistent system of estimates. This means that while all estimates are always going to be wrong, they will be right relative to each other and that is the only thing that matters. The velocity, built on top of this self-consistent system, is also a number which only makes sense in the system within which it was built, but which allows nonetheless effective conversations to happen and valuable data to be gathered.

I hope this helps you come up with a more effective software delivery process.