An agile methodology can be an effective framework for a software team, providing the minimal amount of process necessary for the team to be efficient in delivering customer value.

One component of agile in particular, however, can be contentious - the sprint retrospective. At its worst a sprint retrospective functions as a bitch-and-moan session, where the entire team takes an hour every sprint to complain about various things. Nothing actionable is captured. Contrastingly, the intent of the sprint retro is to be a vehicle for the continuous improvement of the team. Regardless of how high performing your team is, there are always things that can be done better. The sprint retro is a safe environment to constructively criticize and for team members to hold each other accountable. At the same time it’s an outlet to express gratitude and give kudos to your teammates. Just as importantly, the end-of-sprint cadence signifies accomplishment and provides a chance to show off completed sprint work (sprint demos are worth an exploration all their own).

While many factors separate effective and ineffective sprint retros, this post will focus on recency bias and the challenges it presents to holding effective sprint retrospectives.

Just one of many cognitive biases, recency bias is simply part of being human. Our brains are adaptive and look for shortcuts when making sense of the world. To that end, recency bias emphasizes and places higher relative importance on more recent events over earlier events, regardless of any other particular aspect of the events in question. In this way, our perception of reality can be distorted. Sprint retrospectives are all about improvement and it is difficult to improve if the focus isn’t on the right problems, which is precisely what recency enables.

Consider the scenario in which your team has gathered to reflect on the sprint but no feedback has been prepared in advance. Everyone on the team provides their critique of the sprint with nothing more than what’s top of mind. It’s likely that the majority of issues discussed occurred only within the last few days or week - not throughout the entire sprint. You’re not talking about the thing from last week that could make a big impact. Instead, you’re talking about the thing that just happened, the importance of which will fade by tomorrow. The color of the sprint has been tinted with recency bias. Not only is the team focused on the wrong problems, but the retrospective is actively wasting the team’s time.

One tactic for combatting recency bias in sprint retrospectives is to ensure the team has a consistent, static place to put feedback whenever it should cross their minds. I have seen Trello boards work well in the past, though there are no shortage of options. There should be no need to search Slack channels or look through email for a link. Every person on the sprint retro invite should always know where sprint feedback goes.

Additionally, encourage teammates to regularly add thoughts and feedback throughout the sprint, and from sprint to sprint. It’s much easier to remove unnecessary content than it is to recall a fleeting thought from last week. On that same note, regularly trim and curate your own feedback, removing or updating items that have become moot.

Be aware how easily recency bias can sneak into sprint retrospectives and pull attention away from things that matter. Engage in relentless continuous improvement by keeping focus on the right problems. Reflecting on process improvements isn’t just an activity for sprint retrospectives - it should be happening throughout the sprint. Continuously funnel team feedback to a consistent location. In this way, the team has a full perspective of the sprint and can identify and take action to drive real improvement.