Who should conduct retrospective meetings?

Here’s a bit of an open secret: success in life is all about learning from the past.

Whether that’s remembering a shortcut that shaves 10 minutes off your commute time, or simply doing things better the second time, it’s a fact of life that helps us all improve.

It’s this ethos that underpins the concept of the retrospective. In the context of agile development, the retrospective takes place at the end of each individual sprint.

But, as a team activity, who conducts the retrospective meeting? Which of your team should you look for a meeting structure, agenda points, and tight time keeping?

Let’s find out.

The conventional approach to sprint retrospectives

Who conducts retrospective meetings in the agile model?

Ask this question to most teams working via the Scrum agile methodology and they’ll likely give you the same answer: the Scrum Master. After all, as described in the official Scrum Guide, the Scrum Master “is accountable for the Scrum Team’s effectiveness” and does this by “enabling the Scrum Team to improve its practices, within the Scrum framework”.

It’s only logical, then, that the Scrum Master would also be responsible for managing the sprint retrospectives, at the end of each block of time. That fits nicely into their remit, right?


But it also makes sense for a Product Owner to host the retrospectives, too. After all, it’s in their interest to have a clean and concise product backlog — one that’s running at top efficiency to reach project goals. But wait… doesn’t that also apply to Product Managers? Or even Project Managers?

Phew! As you can see, there are as many different approaches to the retrospective as there are agile teams.

So what’s the common thread here?

Who should host the retrospectives?

To be clear: in most cases, you’ll find that the retrospective is conducted by the same person. It doesn’t matter whether it’s the Scrum Master, Product Owner, or anyone else, most Scrum teams — and agile teams in general — will have the same person host the retrospective meeting every time.

It might be this way is easier, faster, and less fuss to organize… but is it the best way? Could there be a more optimal approach to sprint retrospectives, delivering better long-term results?

You bet there is.

Why it’s (sometimes) okay to break convention with your retrospectives

What if you had no fixed facilitator for your sprint retrospectives? Or what if, every time you finished a sprint and sprint review, you then selected a different person from a small pool of options to host the meeting?

At face value, these approaches may seem messy and illogical. But there are actually several good reasons to rotate or “outsource” the facilitator of your sprint retrospectives:

  • The team avoids stagnation. When the same person conducts the meeting every single time, you risk uncovering the same tired conclusions or missing things someone else might catch. And that’s a quick way to plateau your progress.

  • You’ll get a different point of view. Some agile teams actually go entirely outside of their own group to find a facilitator for their sprint retrospectives. Why? Because it brings a totally fresh perspective from someone who might be able to see the wood for the trees.

  • Your team might lack the necessary skills. Retrospectives are meetings like no other. It’s not just about going through a to-do list. The facilitator needs to know how to conduct a retrospective properly, covering goals, challenges, key take-aways, and more. If this person isn’t in your team, you’re better off finding them elsewhere.

The art of the retrospective — 3 top tips for meeting leaders

Okay, so let’s imagine you’ve decided to mix up your sprint retrospectives by either bringing in an external facilitator or rotating through a small pool of people.

They might just need a bit of help to hit the ground running, so here are our 3 best tips to help meeting facilitators lead a quality sprint retrospective.

#1: Try not to frame the meeting as a product problem-solving session

By their very nature, retrospectives will always involve some discussion of the problems the team has faced during development (and when you do, the 5 Whys can really help). But that’s not an invitation to start troubleshooting specifics of the development there and then. The goal of the meeting is to identify overall trends and bottlenecks, not to start fixing specific product issues.

#2: Avoid playing the blame-game. Always.

Another natural consequence of the retrospective meeting is that it covers things that perhaps didn’t go to plan. This isn’t about pointing out faults, but the facilitator should remember that team members might feel like they’re being accused of some wrongdoing or other. It’s vital to emphasize that the retrospective is about the team — not about the individual.

#3: Retrospect your retrospective

It might sound odd, but it actually makes good sense to do a little retrospective on your retrospective. This is especially valuable when you have rotating facilitators. Just take five minutes at the end of the meeting to discuss your approach to retrospectives and whether or not the team feels like they’re getting value from them. Are they useful? Are they fun?

If not — and in the spirit of a true retrospective — you can tweak the parameters and try again next time.

Looking to level-up your team’s retrospectives?

With EasyRetro, learning from the past is… easy.

Retrospective meetings become treasure troves of actionable insights thanks to our easy-to-use digital platform. Even better, our suite of tools and features means that any member of the team can host the retrospective and still deliver true value and action items for the next sprint.

Not sure that sprint retrospectives could ever really be fun? With EasyRetro, it’s just a few clicks away. Try it now, risk-free, with a 14-day free trial.

Want to create a free retrospective with your team?