The #NoEstimates hashtag is, effectively, a container. Within that container are many different conversations happening about estimation practices, the resulting estimates from those practices, and the business behaviors driven by these estimates.
A common reply from the skeptics is, “#NoEstimates is a solution looking for a problem. If teams want to improve they shouldn’t dump estimation, they should work on making better estimates!!!”
False assumptions about what #NoEstimates means aside, improving estimation is an interesting idea. But what does that really mean?
The Problem of Uncertainty
Let’s start with what makes estimation difficult: uncertainty. We live in a world of uncertainty, and software projects provide a great microcosm of the types of uncertainty we face in our lives.
This uncertainty can manifest itself in two ways: accidental complication and essential complication.
Accidental complication includes the things we can improve. Craftsmanship, code quality, development processes, and management practices are all examples of the types of accidental complication we can reduce and manage.
Essential complication is inherent to the kind of work we are doing. The difficulty level of a problem you are trying to solve is an example of essential complication.
J.B. Rainsberger introduced these terms at Øredev 2013. He invited the audience to consider the idea that accidental complication often dominates the cost of a feature, thereby making estimating the cost of a feature an exercise of measuring dysfunction in your software practices and codebase.
This means our estimation is often not driven by the difficulty of the problem we are trying to solve, but rather by the health of our codebase, the quality of process, and how much discipline we have in our management practices.
It reminds me of the old joke about a junior developer asking a senior developer how to make sure their estimates are “right.” The senior developer replies, “Easy! Take your estimate, multiply by two, and add two weeks.”
This is why project management offices have created Excel spreadsheets that add percentages (padding) to estimates based on past outcomes—to try to come close to accounting for the accidental complication within their organization. There are times when fixing systemic issues is cost-prohibitive, and this approach can work.
However, if you want to improve your estimates and you agree that accidental complication dominates the cost of a feature, then agile and #NoEstimates thinking can have the biggest impact on your team’s success.
Reducing Accidental Complication
Accidental complication can exist in many parts of a project, but here are three areas where many teams can start to reduce uncertainty and improve the quality of their estimates: craftsmanship, software development processes, and management practices.