Blog Cognitive Biases That Can Impact Your Scrum Team
The human mind is not infallible. Over time, an extensive list of cognitive biases have been identified.
By Brian Lantz / 16 Dec 2017 / Topics: Application development
Over time, an extensive list of cognitive biases have 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. Let's look at five cognitive biases that could negatively impact your Scrum team.
Planning fallacy
People are overly optimistic and generally fail to recognize the complications 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're 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, this planning fallacy will also impact smaller efforts, such as estimation, within your Scrum teams. The planning fallacy can be particularly detrimental to the 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 embodied within a project. Although it's tempting to try to perfectly estimate all of your team’s work, such a feat is impossible, and any estimation made is an approximation. Spending time in an effort to refine an estimation likely won't provide any additional value.
Anchoring
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 endpoint — 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 graph below represents a hypothetical sprint in which team members were, for the most part, satisfied with each day’s work. However, on one day team satisfaction dipped to -4 (the most extreme point during the sprint). The peak-end effect postulates 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 the team would view this sprint through a negative lens.
During the sprint retrospective, the team needs to draw attention to all activities and events throughout the concluding sprint. It's easy to focus only on the worst or best day within a sprint, but these days can't 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's 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 his or her job.
Assuming 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's necessary for a high-functioning Scrum team. Letting feelings of resentment fester within the team will break down trust and, ultimately, impact the team adversely.
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 steer the conversation in a productive path and avoid assigning blame.
Blind spot bias
This article wouldn’t be complete without 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's not enough to be only aware of them. Steps need to be taken, in the form of structured activities or self-introspection, to recognize and prevent the biases from impacting decision-making and performance.
Brian Lantz
Project Services Consultant
Brian is a business analyst with experience ranging from working as a member of small Scrum teams to leading requirements analysis and management efforts on projects for Fortune 100 clients. Through strong technical, organizational and interpersonal skills, he's committed to delivering quality software. Brian is a certified Professional Scrum Master and Professional Product Owner through Scrum.org.
