The Perfect Way to Run an Agile Retrospective Meeting

If you find your company struggling to separate what should be scrapped from what’s worth pursuing, you might be skipping an important step in your agile journey: agile retrospectives.

Perhaps you’ve only heard these mentioned in a development context. But in recent years, agile retrospectives have worked their way out of development and into all facets of the business, from marketing right up to management. Anyone can benefit from the payoff.

By the end of this post, you’ll have a better idea of what that is, plus examples and tips to try in your first meeting.

What is an agile retrospective?

Also known as a sprint retrospective or sprint retro, agile retrospectives are meetings held to recap each iteration of an ongoing project. They’re a great opportunity to pause, step outside the work bubble, and assess what’s working and what’s not. Through this analysis, agile retrospectives follow the principles of kaizen: finding ways to continually improve.

This isn’t to be confused with sprint planning. First up in the inspect and adapt cycle, sprint planning is when the team picks items from product backlogs to address in an upcoming sprint. Agile retrospectives come at the end of the larger scrum process and inform the next sprint.

They’re also the last, but by no means the least, of the twelve principles of agile development:

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Regular being the operative word.

Without regularly checking in on how things are going and making small improvements, it’s pretty difficult to make big things happen. Retrospectives work best at set intervals.

But I know it’s just as difficult to justify spending more time in more meetings when you’re busy enough as it is. At this point, you might be wondering where you’ll find the time for agile retrospectives–or if they’re even worth your time. Bear with me, because they absolutely are.

Why do retrospectives?

At their core, agile retrospectives help us avoid the age-old trap of repeating the same thing and expecting different results. But there’s even more potential than that.

Run well, agile retrospectives can:

Energize: Retros should be positive, supportive, rewarding experiences. Think of them as a team-building exercise and a way to get everyone excited about finding new solutions to old problems.
Empower: Retros should foster a culture of ownership. Given the chance to own their decisions, teammates are more likely to embrace than resist anything that needs to change–the very attitude agile teams need to thrive.
Inform: In part, agility is about speed. But focus too much on speeding ahead and, naturally, you forget to reflect. As I mentioned earlier, agile retrospectives help regulate the crucial process of failing fast and singling out what no longer moves us forward.
Build relationships: Not only can retros help build teams themselves, but they can also help teams better articulate problems to leadership–thereby improving the odds budgets are approved–while also building trust with customers sprint by improved sprint.

So how to run this meeting well, you ask? Let’s explore what a successful retro looks like.

How to run an agile retrospective: sample agenda

In their definitive book Agile Retrospectives: Making Good Teams Great, Esther Derby and Diana Larsen came up with a five-stage framework for retrospective meetings, which I’ve adapted below to include a few exercises I find work well.

A quick note on this sample agenda: the timing is adjusted for a lean 30-minute retrospective. You might need as much as an hour, or even two, depending on the scope of work or the size of your team. Feel free to scale each step accordingly.

Also bear in mind that while it’s important to keep timing, attendance, and the general format as consistent as possible to help formalize the process, that doesn’t mean you have to stick to the exercises I’ve suggested. Have fun and switch them up! Don’t worry–I’ll show you where to find alternatives.

As for the housekeeping:

When: For traditional two-week sprints, at the end of each sprint. For Kanban-style workflows, monthly or quarterly will do.

Who: Everyone on the team. And if necessary, folks who contributed to the current sprint from other departments.

What you need: Whiteboard, markers, sticky notes in three colors, timer.

Prep: Pick a scrum master (more on this below) and write two headers on the whiteboard: “What went well?” and “What can be improved?”

Let’s dive in.

1. Set the stage (5 minutes)

This is about getting the team engaged. Make attendees feel like valued contributors from the start by taking a moment to thank them for investing their valuable time, and have each person explain briefly what they hope to get out of the session. With this in mind, clearly outline prevailing themes to help keep the session on course.

Tip: Use the timer to give everyone equal time to have their say.

2. Gather data (10 minutes)

Here’s where you start to paint a picture of the current sprint. Collect data on anything meaningful to the team: action items and results, decisions made, milestones achieved, new technologies implemented. Of these, what went well or not so well?

Exercise: This is where the whiteboard comes in. With one item per sticky (one color for good, another for areas of improvement), have team members arrange the above data under those two headers. Group similar stickies together to facilitate discussion.

Of course, this method can get old pretty quickly. Another of my favorite prompts is known as the 4 Ls, which replaces “what worked well/not so well” with:

What did you like?
What was lacking?
What did you learn?
What do you long for going forward?

Note that the more nuanced the prompt, the more time you’ll need. For lack of time or for more ideas, check out Retromat (a free idea generation tool) or these games from agile retrospective expert Luis Gonçalves.

3. Brainstorm ideas (5 minutes)

As you know, data is useless without insight. This stage focuses on what went wrong and linking cause to effect: having identified shortfalls, note why. The why behind problems is what guide ideas for smart solutions. And you’ll need several, as the first possible solution is rarely the right one.

Exercise: To get to the root cause of problems, try an exercise like the 5 whys (or my edited version). Use this straightforward analysis to come up with a range of viable solutions, one per sticky of your third color.

Tip: To find solutions that get real results, don’t forget to consider the potential outcomes.

4. Pick a solution (5 minutes)

Once you have a good handful of workable solutions, narrow down to two or three ideas you can reasonably take into your next iteration. I say reasonably because it’s easy to get overly ambitious.

Exercise: One of the most effective decision-making strategies I know of for this is a simple “dot vote”: everyone grabs a marker and adds a dot to their top three priorities. Simply add up the scores.

5. Close (5 minutes)

Remember, agile retrospectives are the perfect segue into iteration planning. Don’t send attendees away without:

A clear summary of what you learned
Concrete action items, broken into as small and easy-to-implement steps as possible and assigned owners and due dates
A clear idea of the process for follow-up, feedback, and/or measuring results

On that note, while it might seem meta, this is a good time to improve the retro itself by asking for feedback on how it went.

Exercise: Try what Luis Goncalves calls return of time invested (ROTI).

First, draw this on your whiteboard:

Each teammate can then cast a vote for their chosen quadrant by adding a sticky note (with their reason for the choice).

Final tips

Two things agile retrospectives should never be are boring and unsafe.

On the contrary, the best retrospectives cultivate environments where team members can feel engaged and comfortable enough to speak their minds and feel heard without judgment or finger-pointing. This is about actions and outcomes, not blaming people, and creating a space where the team can contribute to collective success.

Here are a few tips for creating this sort of environment in your retro:

Don’t call it a retro

To most, the term “agile retrospective” is probably too much of a mouthful, not to mention formal. Just giving the meeting your own name can change the tone. What word would get your team more excited–or at least less intimidated–to participate? Huddle? Whiteboard Friday? Hour of Power? All of these are great options.

Choose your scrum master wisely

Not just anyone can become a scrum master. It takes a few specialized capabilities to mediate agile retrospectives productively, for example, being able to:

Address different perspectives
Remain impartial and judgment-free
Ask relevant questions
Prioritize solutions
Ensure everyone is heard and understood

Least qualified for the job are team leaders. Management might have the best of intentions, but under their eye, team members might not feel comfortable to speak freely–and that’s key.

You might also want to try appointing a new scrum master for each meeting to share participation and keep things fresh.

Find the positive spin

Studies show that positivity directly relates to higher performance. Imagine carrying that positive sense of momentum into your next iteration. Where can you put a positive spin on your agile retrospective?

Early in the meeting, by starting with and focusing on what went well?
During the meeting, for example by asking that people express “wishes” instead of complaints? (Another nod to Luis for that wonderful example.)
After the meeting, ending with a round of acknowledgments and by giving the teammates a chance to thank each other personally?

Choose your environment wisely

Similarly, you’d be surprised how powerful it can be to take teams out of their normal environment, where spirits might not be high after challenging sprints. On the other hand, there’s no reason not to use the positivity in the room if the sprint went well.

Record (but don’t share) everything

You never know what seemingly throwaway comment can make valuable learning material down the road. Make detailed notes on your meeting, take pictures of the whiteboard, and share these in a way that’s easily accessible to the whole team. And be sure to establish up front what can go public and what stays in the room.

Assign responsibility

Production challenges can often feel out of anyone’s control, but there’s always something the team can do to improve their situation. When someone identifies a problem, give them an opportunity to explain what they’re going to do about it. This helps reiterate the message that when you don’t act, nothing changes.

Put another way, here are a few frequently-encountered anti-patterns to watch out for:

Your retro always turns into a complaint session.
This is a place to feel free to vent and let go of frustrations. But there are unproductive ways to give feedback. Try starting your meetings by establishing rules of engagement, for example, “listen with an open mind” or “everyone’s experience is valid.”

The discussion was dominated by one or two people.
Use your timer to make sure everyone has the same opportunity to speak up. If you still notice an imbalance in participation, your scrum master might need to step in and ask questions or give gentle prompts (you don’t want to force participation).

Actions aren’t getting done.
They might not be clear enough. Commit to one problem at a time and make solutions as specific and measurable as possible (as in, easily defined as done or not done. Something like “improve communication” is too vague).

The team isn’t excited about the solution.
You probably shouldn’t implement it–at least not in this iteration.

The team or leadership isn’t taking the meeting seriously.
Your team can’t get the most value out of agile retrospectives without seeing the value in them. Formalizing this as a regular thing and using the tips above can help make it attractive, but if all else fails, you might want to organize a team workshop to explain how retros can help your organization.

Chances are, a workshop would be useful anyway. Remember, continuous improvement doesn’t just apply to sprints, it applies to agile retrospectives too.