← Blog.

5 Things to Avoid in your Retros

Find the Article in Scrum Experts

Sprint retrospectives — done well — are great ways to keep your team on track and productive. They’re a way to take a step back, look at how you’re working and offer ways to work together better in the next sprint.

Of course, retrospectives aren’t a place to assign blame or force a confession. Effective retros are about focusing on and openly discussing what went well and how to refine that over and over. One of your jobs as a scrum master is to frame the discussion in good terms that assumes that everyone did their best within the limitations of the sprint. Make sure your discussions focus on the positive aspects and work toward improving your process. Always try to find ways to motivate your team by empowering them to find ways to do their work better.

Here are five situations to avoid in your retros and ways to turn them around if they do occur.

The Blame Session

We’ve all sat through the retro that descends into resentment and finger-pointing. Ideally, scrum masters or other retro facilitators should reign in this kind of toxic discussion. Retros are not blaming sessions. The whole point is to focus on improving working methods and becoming more productive in the next sprints.

One of the key assumptions in the Agile methodology is the prime directive. It just means that everyone on a scrum team go in knowing that everyone else did their best work. Even if there were breakdowns in a process or mistakes in the sprint, the prime directive guides individual team members to frame the discussion in ways that improve team workflow as a whole.

If there is a larger breakdown in communication or in performance, the retrospective is not the place to address it. Try pulling individuals aside and addressing issues directly outside of the allotted retro meeting time.

The Micromanager

This will vary across organizations, but generally, upper managers should not be present in retrospective meetings. These spaces are to gather honest, open feedback about how the team is operating and should be free from outside interference or meddling. One of the main points of the retro and of the scrum methodology as a whole is to have self-organizing teams that know what they need to do and how to do it best.

If your organization is truly a flat organization or you have a very strong culture of openness, managers can contribute, but the scrum team should be the ones bringing up and deciding on what tasks to do to achieve the overarching goals and how best to get their work done.

Scrum masters also should not be dictating how work gets done, or which tickets to focus on. Their role is to guide the team in completing the retrospective and encouraging a grassroots approach in team decision-making.

The Honey Roast

Retrospectives are about honest feedback, both good and bad. While you should focus on ways to improve your working methods and ways to repeat your successes, this doesn’t mean you should only have gushing praise for your previous sprint. If nothing needs improvement, it can give the team a false sense of productivity. It can also sow resentment among team members who can clearly see that not everything is going so well all the time.

As a scrum master, it’s vital that you create a safe space where everyone can bring up and express their ideas for what needs improvement and how to implement it. To address areas of weakness or failures, frame it in a way that you’re constantly improving your sprints.

The Cricket Chorus

As in all things, you’re going to need buy-in from your team to run your retros effectively. If your retros are a chore, your team may be reluctant to speak up. This can lead some organizations — even ones that claim to follow scrum — to skip retros altogether. Not enough time, not enough benefit, or some other excuse are some of the reasons some teams give for not holding this vital scrum ritual.

Get your team excited and eager to talk about how to do better work. Icebreaker tasks or some other retro activity are great ways to get the blood flowing and get your team talking. If you use a scrum app to do your retros remotely, using one that isn’t too difficult to use can also help motivate your team to actively contribute.

The Confessional

Confessionals put team members on the spot, asking for reasons why a ticket did not go to plan. It’s a pretty consistent morale-killer and can crop up even in the strictest scrum teams.

Similar to the blame session, the confessional is another situation you want to avoid in your retros. Confessionals can be a confluence of factors, especially if you have a micromanager sitting in, or if you’re micromanaging the tasks yourself. Again, the point of the retro is not to get a confession or to assign blame, it’s to allow experts to organize their own work better over the course of a project.

If tasks were not completed in the sprint, work on ways to organize your task flow better as a team and adjust as you go. Rather than asking why things were missed, or a deadline was not met, get to the bottom of why those things fell through the cracks in the first place.


Good retrospectives help refine your workflows and allow you to get more done in the sprint. As long as you create an environment where ideas and suggestions can flow, you should have productive meetings that help ground your team and encourage self-organizing work.

Many of the situations you want to avoid in your retrospectives have to do with not setting expectations or framing the discussions in positive, constructive terms. Minor shifts in your own communication and goal setting can have a big impact on your retrospectives.

Making these meetings about finding solutions, not trying to assign blame to micromanage future tasks is the key to making your retros more valuable to your team and organization as a whole.