This article is about estimates in a relatively perfect world. It is not about problems that teams run into when dealing with estimates in a world where estimates are often misunderstood and where parties try to pile up additional meanings and metrics to estimates.
So what is an estimate?
Estimating the work to be done is great if you know what the work is, But software development teams often have no idea what the work really will be until they do it. It is a lot like sculpting — give a sculptor a block of wood and he'll have to work carefully while he uncovers 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.
Enter estimates. An estimate is a representation of the team's understanding of the complexity of the work required to accomplish a desired feature.
In order to separate the idea of an estimate from the idea of "how long this work will take," estimates should not be created 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. In order to separate time from complexity, some teams use t-shirt sizes (S, M, L, XL), some teams use the Fibonacci series (1, 2, 3, 5, ...). Each unit of work gets a "size".
An estimate, once set, is unchangeable. There is value only in the original decision. This is somewhat counter-intuitive, since the moment before the team begins is the moment where it knows the least, but we are not looking for the perfect number. We can only get the perfect number once the work is done, and that perfect number is only valuable for this single instance of work. We are looking for a more abstract, general understanding of the complexity of the work, because this more general understanding will help us, in the future, have high-level conversations about work yet to be done.
Since the estimating is done with imperfect knowledge, it will be wrong. So why is this a good idea? Because there is value in having a way to know at a grander scale how much work can be accomplished. Evaluating this big picture allows us to discuss how much work can be done before a given deadline, as well as the overall health of the team.
An estimate can be understood as a measurement known to be wrong and only meaningful in the context of other estimates.
Estimates over time
The velocity
When you have time boundaries (note: kanban users, this is your red flag), 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 that we know to be wrong and meaningless, by definition.
So far, this all sounds like a load of hard work for no reason at all. So why is this a good idea?
Attaining self-consistency
A team that is allowed to generate its own estimates based on the units of work they receive will gravitate toward 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?")
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.
The value of self-consistent estimates
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.
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).
How Estimates fit into the team's process ecosystem
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 toward 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 that only makes sense in the system within which it was built, but which nonetheless allows effective conversations to happen and valuable data to be gathered.
Aldric Giacomoni
