Psychology of Estimation: Biases That Can Affect Planning in Scrum

How teams approach software development has been transformed by the Agile methodologies, allowing for a flexible, iterative process that keeps pace with the ever-changing world of requirements. Central to this is estimation, which resides at the very essence of Agile planning and plays a vital role in sprint planning, backlog prioritisation, and stakeholder communication. Despite all the tools, techniques, and practices at our disposal, however, estimation is one of the most vexing problems in Agile planning.

At the heart of this problem are cognitive biases—systematic patterns of deviation from norm or rationality in judgment.

These biases influence how we perceive and estimate effort, time, and complexity, leading us to make inaccurate predictions that can sink even the best-planned sprints

Let's explore the common biases that affect estimation, as well as the impact they have on planning and the strategies we can use to overcome them.

The Planning Fallacy

Scrum teams can suffer from planning fallacy, which is the bias of underestimating the future action's time, costs, and risks while overestimating its benefits. Daniel Kahneman and Amos Tversky introduced this concept in 1979. Particularly in the context of Agile estimation, we are living a bit in the past when we think we can just add up the time estimates and get a clear view of the future.

Impact on Agile Planning:

An overly optimistic outlook may be at the heart of why Agile teams are sometimes unable to keep up with their pledges. The planning fallacy shows up in sprint plans as a sort of wishful thinking. We generally underestimate the time it takes to get stuff done. Agile teams plan sprints in a canine way—by hoping. Some researchers see the cause of this problem as being diluted by team members' innate speed preferences.

Mitigation Strategies:

• Historical Data: Relying on past performance data can help counteract the planning fallacy. By analysing the actual time taken to complete similar tasks in previous sprints, teams can develop more realistic estimates.
• Buffer Time: Incorporating buffer time into sprint planning can account for unforeseen delays and complexities, reducing the impact of underestimation.
• Regular Retrospectives: Conducting sprint retros with a focus on estimation accuracy can help teams recognise patterns of underestimation and adjust future estimates accordingly.

Anchoring Bias

In cognitive psychology, anchoring is a human tendency to use the first piece of information encountered as a basis for making decisions. When applied to estimation in the Agile framework, this bias suggests that the first estimate given for a deliverable will likely set a standard that later estimates will adhere to, regardless of whether the later estimates should in theory be closer to the actual deliverable timeframe.

Impact on Agile Planning:

Providing an initial estimate can set an unrealistic standard that affects all subsequent estimates. Take, for instance, the situation where you estimate a complex task at two days. You will then likely maintain that figure in your mind and will have to forcibly justify to yourself why the figure ought to change if, in fact, it does need to change. Your brain doesn't like rethinking numbers it has already settled on, and it doesn't like learning new numbers either. Once your brain has settled on a number, it pretty much figures that's the number, with very few justifiable exceptions along the way to keep your brain from thinking about it.

Mitigation Strategies:

• Independent Estimation: Encourage team members to provide their estimates independently before discussing as a group. This can reduce the influence of a single anchor point.
• Re-estimation: Regularly re-evaluate and re-estimate tasks as more information becomes available, particularly during sprint reviews or backlog refinement sessions.
• Wideband Delphi Technique: This method involves multiple rounds of estimation by a group of experts, with feedback provided after each round. The process helps to average out individual biases, including anchoring.

Optimism Bias

The optimism bias leads people to think they are less likely to encounter bad outcomes and more likely to meet good ones. When this bias operates in the world of Agile software development, it results in some overly sunny, and often unrealistic, assumptions about task complexity, resource availability, and external dependencies.

Impact on Agile Planning:

Teams can underestimate the risks and challenges associated with a task and overcommit during sprints because they are overly optimistic. Of course, during sprints, teams shouldn't be adding more tasks than can realistically be completed—that's the definition of scope creep. But why do teams sometimes add more tasks than they can complete? One reason is an optimism bias whereby we overrate the amount of work that can be accomplished in a given period and the rate at which tasks can be completed.

Mitigation Strategies:

• Pre-Mortem Analysis: Before a sprint begins, conduct a pre-mortem analysis where the team imagines that the sprint has failed and works backwards to identify potential reasons. This helps uncover hidden risks and encourages a more realistic approach to planning.
• Realistic Pessimism: While it's important to maintain a positive outlook, fostering a culture of "realistic pessimism" can help balance optimism. This involves encouraging team members to critically assess potential challenges and plan accordingly.
• Scenario Planning: Consider multiple scenarios (best case, worst case, and most likely case) when estimating tasks. This approach helps balance optimism with a more rounded view of potential outcomes.

Confirmation Bias

The tendency to look for, interpret, and remember information in ways that confirm our preconceptions is known as confirmation bias. In Agile estimation, this can lead us to pay selective attention to the kinds of information that would confirm our initial estimates or our plans, while we tend to discount the kinds of evidence that would suggest to us that a task might actually be more complex or more time-consuming.

Impact on Agile Planning:

When teams are dedicated to a specific plan or estimate, they can be quite tunnel-visioned about it. They tend to ignore or even actively dispute information that goes against their chosen course. Why? Because they're making a plan for an uncertain future—and no one likes to be told that their future plans are in jeopardy. This can, and does, lead to all sorts of unfortunate outcomes: missed deadlines, repeated "unstick" challenges, and half-baked rework. In sum, it shoots the efficiency of the Agile process right in its metaphorical foot.

Mitigation Strategies:

• Devil’s Advocate: Assign a team member the role of a "devil's advocate" during planning sessions. Their job is to challenge assumptions and highlight potential flaws in the team's estimates or plans.
• Diverse Teams: Diverse teams, in terms of experience, skills, and perspectives, are less likely to fall into the trap of confirmation bias, as they bring a broader range of viewpoints to the estimation process.
• Open Communication: Foster a team culture where questioning and constructive criticism are encouraged. This can help surface alternative perspectives and prevent confirmation bias from taking hold.

Availability Heuristic

The availability heuristic is a mental shortcut that relies on immediate examples that come to mind when evaluating a specific topic, concept, or decision. In Agile estimation, teams might base their estimates on the most recent or memorable experiences, rather than a comprehensive analysis of all relevant data.

Impact on Agile Planning:

If a team recently encountered a particularly challenging task, they might overestimate similar tasks in the future, expecting them to be equally difficult. Conversely, if recent tasks have been straightforward, the team might underestimate the complexity of upcoming work. This bias can lead to inconsistency in estimation and sprint planning.

### Mitigation Strategies:

• Comprehensive Data Review: Before making estimates, review a wide range of past sprint data, not just the most recent or memorable examples. This helps ensure that estimates are based on a representative sample of experiences.
• Continuous Learning: Encourage a culture of continuous learning where past sprints are regularly reviewed, and lessons learned are documented and shared. This can help teams develop a more balanced view of task complexity and effort.
• Debriefing Sessions: After each sprint, hold debriefing sessions to discuss what went well, what didn’t, and why. This helps build a more nuanced understanding of task complexity over time, reducing the reliance on the availability heuristic.

Conclusion

Estimating is a tough part of Agile planning. It is like trying to hit a moving target just when you think you've got it in sight. Some planning factors are mostly beyond our control (for example, changing requirements), while others we can influence (for example, team composition). Still, there are many cognitive traps and biases that we fall into when we make judgments about these influences, and understanding them can help us avoid the snares they set for us.

After all, our judgment is how we get to our estimating, and if our judgment stinks, then we're not going to get to good estimates. And a good estimate that gets us to our destination is much better than a bad or no estimate at all.