Estimating through biases
One of the main reasons behind inaccurate estimates is the influence of cognitive biases. The good thing about this is that biases may be a topic that is not largely discussed in the software industry, but we can apply to software development processes many lessons learned across other industries. This is particularly true of the financial sector; there is of course a direct correlation between good estimates and healthy budgets in the software industry, but this is far, far more transparent in finances. This article is an attempt to analyze some of these learnings, with emphasis on how cognitive biases impact different steps of the estimation process.
Let’s get started. The first cognitive bias to appear, as it has an impact even before the actual estimation process begins, is The Focusing Illusion. This phenomenon leads us to misjudge, attaching too much significance to one particular feature of an event or situation. For example, while we focus on the complexity or size of a task and keep these variables at the center of our estimations, we may be leaving behind other factors that are just as important.
Once a task and its context have been defined and we start thinking about how to weigh it, we face the cognitive bias that accounts for the biggest single cause of risk in estimations. This is The Optimistic Bias, which leads us to underestimate the costs and completion times of planned decisions.
We tend to be overly optimistic and fail to recognize the complications that we could face, and this creates estimates that just fall short. And as if this bias would not be enough to influence our estimates, it comes accompanied by the Planning Fallacy. Its signature is that not only are we optimistic while planning, but we also tend to maintain our optimism about a project even in the face of historical evidence to prove us wrong.
In the same line, we can complete this triad with the Illusion of Control. We tend to ignore uncertainties and overestimate our ability to control events, and this is particularly strong in stressful situations like gambling, financial trading, or… yes, estimating.
In a nutshell, we are likely to underestimate a task even when we are aware that we almost always underestimate them. This is brilliantly put in the recursive Hofstadter’s law coined in the book Gödel, Escher, Bach: An Eternal Golden Braid, which states that “The time to complete a task of substantial complexity always takes longer than you expect, even when you take into account Hofstadter’s Law.”
Following the usual approach that teams conduct for estimations — excluding the rare cases in which everyone agrees — , right after every team member has provided their estimate the discussion begins. And so begin the next set of cognitive biases.
The Anchoring effect creates a tendency to rely too heavily on the first piece of information that is presented to us. The classic example of this bias is in negotiations. The first party to mention a price sets an anchor; an expectation of a range price of what is acceptable that influences the entire course of the negotiation. This bias can be avoided with techniques such as Planning Poker, but it presents itself when there is no agreement after the first round of estimates, which is usually the case. The first person to speak will turn the discussion course, affecting considerably the resulting estimate.
As each team member presents their arguments for their estimate, we need to be aware of the Availability heuristic and Confirmation bias. When evaluating a decision, we tend to weigh recent information as if it were more important than what it actually is, making our decisions biased toward the latest events that are available for us to recall. As for confirmation bias, we tend to provide a higher value to information that is in line with what we believe, selectively remembering the data that confirms what we already think.
Once our tasks have been estimated and we can happily move on to getting the work done, there are still cognitive biases that affect our behavior and how our projects play out.
If you were ever in the middle of a project that just did not seem to have a finishing line, that kept extending and extending without ever completing, you have probably experienced Loss Aversion Bias. In finances, loss aversion appears as it suppresses a trader’s ability to move on and seek new achievements, or at least prevent further losses. And in the software industry, it creates a tendency to continue with projects beyond what is reasonable, merely because of all the time that we have already dedicated to it. To avoid feeling the loss we stick to a plan hoping for a gain, and sometimes this just leads to a bigger loss.
Perseverance is a good thing, as long as we understand the state of things and the value of continuing with a determined task.
The last two that are worth mentioning make their appearance once a project is completed. The first one has been popularized by Nassim Taleb as Epistemic Arrogance, and is the fact that after an unexpected event, we tend to say that we saw it coming. This works along with the Narrative Fallacy, which is our tendency to bend a story to fit with our perception of what we know.
These biases come to play when we are analyzing how a project developed, finding root causes for problems, or explaining deviations. They make us rationalize events just because we know how things ended, and lead us to believe that we knew beforehand that something that happened was going to happen.
Since much of what I have written here comes from lessons learned in the financial sector, I will close it in the same line with a well-known quote from Warren Buffet, as a summary of what an unchecked estimate can be: “Forecasts may tell you a great deal about the forecaster; they tell you nothing about the future.” Oftentimes we may think that we are seeing things as they are, but we are just seeing them as we are.
