Estimating is like measuring nuts hardness
And only by looking
In recent years there has been a trend in software development that tries to avoid estimating, it is a topic that began with the #NoEstimates of Woody Zuill (one of the first promoters of Mob Programming) and about which there has been a lot of talk (resources in spanish):
- Estimar es timar: Example Mapping by Dani Latorre
- The Futility of Estimating Complex Problems by Simón Muñoz
- Estimating is not a scam, but it looks a lot like it by Jerónimo Palacios
- Estimar no es timar by Javier Martín de Agar
And the fact that there’s been a lot of talk about it is important, as it’s greatly influenced the way we develop. In some environments, estimation has even become a taboo that makes it not only unappreciated, but also seen as a stigma.
However, as some of the articles I’ve mentioned above suggest, estimating isn’t entirely wrong, but it’s undoubtedly dangerous. Therefore, in this article I will give you my opinion on when it is necessary to estimate and under what conditions to do it.
When estimation is needed
As developers, we continually estimate, even if we often don’t verbalize either the process or the result. We estimate every time we think about how we’re going to solve a problem, how we’re going to iterate a part of the product, or create something new. The mere process of thinking about the steps to take to reach our goal gives us a rough idea of how much it can cost us.
And this type of estimation is essential and necessary for the proper functioning of a team that develops software. One of the keys to success of an agile team is the good prioritization of the tasks to be carried out. Without that estimation that tells us where the shots are going, this prioritization not only becomes complicated, but it becomes a game of chance.
In this sense, the role of the developer is key in planning. In all the teams in which I have worked, the phrase “this is going to be a hard nut to crack 🥜” has come up more than once, which rigorously indicates the difficulty of the proposed task. That phrase is nothing more and nothing less than a vague estimate of the effort required to tackle that task. And those kinds of estimates are necessary so that the PM or person responsible for prioritization can then make the most informed decisions possible.
How accurate the estimate should be
When we place the PM in front of a basket of nuts, the estimation ceases to have meaning and becomes the game of roulette again. The cost of the developments ceases to be relevant and what defines the prioritization becomes exclusively the set of external stimuli that have led to the consideration of each of the tasks, making the prioritization, therefore, less precise in the mid and long term vision.
That’s why developers should be able to estimate the hardness of nuts just by looking at them (although sometimes we have the opportunity to get close to testing them in the form of a spike).
However, estimating the hardness of nuts doesn’t have to be an exact science by any means. For the task we are facing, it is enough simply to know which nuts are harder than others and which nuts are disproportionately tough (these will require extra consideration when prioritizing whether they are essential for the product).
What are the dangers of estimating
As you can imagine, estimating nuts hardness using only the sense of sight is a complicated task and far from accurate. These restrictions are important to keep in mind, as expectations about that measure need to be clear.
The problems come when we take a nut’s hardness too seriously or assume that its measurement is more accurate than it is. When we talk about nuts we have to assume that the hardness we have given them is approximate and that, like real nuts, it can vary over time.
Therefore, we have to avoid the danger zone in which we commit to an estimate of its hardness, since betting everything on a nut is never a good strategy.
On the other hand, the time we spend measuring nuts hardness can also be problematic. If we dedicate more effort to measuring each of the tasks than we invest in solving them, we will be wasting time.
And as for the time spent, we have to avoid estimating entire projects, since we are never going to get it right, all the effort we dedicate to estimating each of the moving parts of a project will be wasted effort.
When and how to estimate
As we have seen, estimating (i.e. measuring the nuts we are facing) is sometimes necessary, since any prioritization that affects the mid term requires knowing roughly how much time the team is going to invest in each part of the development.
On the other hand, these estimates should be considered imprecise and should be taken into account that they may change during the creation process. If halfway through development we realize that a nut was harder than we thought, we can act accordingly and reprioritize if necessary.
And finally, I emphasize again to take into account the time we spend outside in the field measuring nuts hardness. It should not consume the precious time we have to develop and we must understand that the more scope the functionality or project we are estimating has, the further it will be from reality.
TL;DR
The estimation process in software development is crucial to the smooth running of an agile team, as it provides guidance on the direction and effort required in each task.
However, estimating is not an exact science and can lead us into dangerous territory if we cling too closely to numbers or spend too much time on this task. It is important to understand that estimates are approximate and may change during the development process.
Therefore, we must use our time efficiently and be aware that the broader the scope of the project, the more inaccurate our estimates will be.
In short, estimating is necessary in certain circumstances, but we must do so with caution and flexibility, always recognizing its inexact nature and its potential to change over time.