Smarter ideas worth writing about.

Cognitive Biases That Can Impact Your Scrum Team

Tags: Agile Enablement , Scrum

The human mind is not infallible. Over time an extensive list of Cognitive Biases has been identified. These biases, which arise from having too much information, feeling the need to make a decision quickly, filling information gaps, and deciding what to remember, impact all facets of decision making and influence our work. Listed below are a few cognitive biases that could negatively impact your Scrum team.

Planning Fallacy

People are overly optimistic and generally fail to recognize the complications that they could face, which results in understated estimations. Every IT professional can think of a project that spiraled out of control and was delivered over budget and beyond the projected date. Paradoxically, individuals are likely to underestimate a task even when they are aware that estimates are almost always understated. This is illustrated in Hofstadter’s Law: “It always takes longer than you expect, even when you take into account Hofstadter's Law.”

This fallacy has a tremendous impact on macro-level project goals, such as budgets and timelines. Keep in mind, however, that this Planning Fallacy will also impact smaller efforts, such as estimation, within your Scrum teams. The Planning Fallacy can be particularly detrimental to Waterfall development model, and should be taken into consideration when deciding which development model to pursue.

This fallacy can be prevented through minimizing the amount of planning and estimating that is embodied within a project. While it is tempting to try to perfectly estimate all of your team’s work, keep in mind that such a feat is impossible and that any estimation made is an approximation. Spending time in an effort to refine an estimation is likely not providing any additional value.


People have a tendency to rely too heavily on the first piece of information with which they are presented when making decisions. Anchoring appears, for example, when negotiating the price of a car. By being the first party in the negotiation to mention a price, the dealership sets, or anchors, the expectation of what is an acceptable price for the car.

The anchoring bias commonly appears during Scrum estimation efforts. If, in an unorganized estimation exercise, a development team member prematurely announces their estimate, then the remaining team members are influenced and may be less likely to raise further questions, state an estimate that differs from that of the anchor, or challenge the stated estimate. Anchoring can result in poorly contemplated, inaccurate estimates.

Properly implemented estimation techniques, such as Planning Poker, can teach teams to share their estimates simultaneously and to prevent anchoring. In the case of an anchor having already been set, the team needs to recognize the potential pitfall and try to overcome the anchor through open conversation, thus exemplifying the scrum values of courage and commitment.

Peak-end Effect

The mind has developed a shortcut for recalling events. When asked to reflect on an experience the mind recalls two points - the most extreme (good or bad) point and the end point - and computes the average. A true analysis of an event would include far more sample points. This heuristic provides us with a quick, but potentially misleading, remembrance of events.

The below graph represents a hypothetical sprint, in which the team members were, for the most part, satisfied with each day’s work. However, there was one day where team satisfaction dipped to -4 (the most extreme point during the sprint). The Peak-End Effect postulates that the team’s satisfaction for the overall sprint would be -1.5, the average of two points: the most extreme and the final. The outcome of this sprint is unknown, but, even if positive, it can be assumed that the team would view this sprint through a negative lens.

During the Spring Retrospective, the team needs to draw attention to all activities and events throughout the concluding sprint. It is easy to focus only on the “worst” or “best” day within a sprint, but these days cannot be evaluated in a vacuum. What happened in the preceding days to account for “most extreme” day? How did the events of that day go on to impact the remainder of the sprint? A properly facilitated and organized Retrospective will investigate both the memorable and forgettable days within a sprint.

Fundamental Attribution Error

If you miss a deadline or make a mistake it is easy to justify the result: You were busy, the requirements changed, the estimate was far too low. However, when another person makes a mistake we tend not to give that person the benefit of the doubt. The mistakes of others are attributed to that person being unsuited for their job.

Assuming that issues are the result of team members being lazy or unintelligent - rather than mistakes or misunderstandings - works only to deconstruct the spirit of cooperation that is necessary for a high-functioning scrum team. Letting feelings of resentment fester within the team will breakdown trust and will ultimately adversely impact the team.

To keep Sprint Retrospectives constructive, remind the team of the Prime Directive, which is the golden rule of Retrospectives:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” – Norm Kerth, Project Retrospectives: A Handbook for Team Review

Keeping this rule in mind should help to steer the conversation in a productive path and avoid assigning blame.

Blind-spot Bias

Such a blog post wouldn’t be complete without lastly listing the Blind-spot bias. After becoming aware of the biases listed above, individuals make themselves susceptible to the Blind-spot bias. Failing to recognize your biases is, in itself, a bias.

Many cognitive biases are the byproduct of heuristics. With these biases having been engrained in our psychology, it is not enough to be only aware of them. Steps need to be taken, in the form of structured activates or self-inspection, to recognize and prevent the biases from impacting decision making and performance.


About The Author

Project Services Consultant

Brian is a Business Analyst in Cardinal's Columbus office with experience spanning from working as a member of small Scrum teams to leading Requirements Analysis and Management efforts on projects for Fortune 100 clients. He is committed, through strong technical, organization, and interpersonal skills, to delivering quality software. Brian is also a certified Professional Scrum Master and Professional Product Owners through