« Back to Planio Blog

Jory MacKay on November 11, 2020

Jory MacKay

Jory is a writer, content strategist and award-winning editor of the Unsplash Book. He contributes to Inc., Fast Company, Quartz, and more.

November 11, 2020 · 14 min read

Have you ever had one of those bad dreams where you keep making the same mistake over and over again? Like showing up to the final exam without studying or standing up at a meeting only to discover you’re not wearing any pants?

Now, what if that dream became your team’s reality? (Hopefully, everyone’s still wearing pants!)

If you feel like your team keeps making the same mistakes over and over, they probably are. Luckily, there’s a tool you can use to break the cycle.

Sprint retrospectives are a powerful opportunity to highlight opportunities for change, generate meaningful improvements to your workflows and processes and speed up future projects, and stop your team from falling into the same traps.

That’s if you run your sprint retrospective properly.

If done poorly, these agile meetings can turn into a bad case of the blame game with everyone pointing fingers and screaming “No, it’s your fault!”

Nobody wants that. So what does it take to run a proper, effective, and efficient sprint retrospective?

In this guide, we cover the basics of what is a sprint retrospective, when it happens, and how to run one and then cover some of the best examples and ideas for running a successful one.

Want to supercharge your sprint retrospectives? Jump to our 7 unique sprint retrospective templates and examples you can use today.

The basics: What is a sprint retrospective, when does it happen, and who attends?

Chances are, if you’re using an Agile development methodology then sprint retrospectives are already a part of your regular routine. However, let’s quickly go over the basics to make sure we’re all on the same page.

What is a sprint retrospective?

The official Scrum Guide describes a sprint retrospective as:

A meeting held at the end of a sprint where the Scrum Team can inspect itself and create a plan for future improvements to systems, processes, and workflows.

In more straightforward terms, it’s a safe space for the development team to discuss what went well and what missed the mark during the just-completed sprint and how they can improve in the future. During the sprint retrospective, the facilitator (most likely the scrum master) encourages conversation and documents each team member’s input in summary form.

Agile project development is all about continuous improvement. And as such, the ultimate goal is to come up with a list of actionable steps to make the next sprint more successful and enjoyable for everyone.

For example, your team might discuss:

• Specific events that happened during the sprint–the good, bad, and ugly
• Improvements to processes like your daily scrum
• Changes to how you communicate internally or with stakeholders
• Any other places where someone sees an opportunity for improvement

Each sprint is an opportunity to learn, grow, and improve your processes. The sprint retrospective is a chance to formalize this process and make sure actions are taking place, lessons are being learned, and positive change is being driven throughout the team.

When does the sprint retrospective happen?

As the name implies, a sprint retrospective happens at the very end of your current sprint, usually immediately after the sprint review and before your next sprint planning meeting.

If you’re a little confused by the difference between the sprint review and retrospective, here’s a simple way to tell them apart:

• The Sprint Review is equivalent to a user acceptance test. During the review, the project team demos the deliverables to the product owner who reviews them against the acceptance criteria.
• The Sprint Retrospective is closer to a project post-mortem where the whole team takes a step back and inspects their processes and workflows.

In other words, a sprint review is about the product while the retrospective is about the process.

How long should a sprint retrospective last?

While there are no established rules around how long a sprint retrospective should last, like all agile ceremonies, it needs to be time-boxed.

A good rule of thumb is to keep your sprint retrospectives to no longer than 45 minutes per week of the sprint. That means a one-week sprint would have a sprint retrospective of maximum 45 minutes, while a month-long sprint could take up to 3 hours.

How long your meeting lasts depends on a number of factors, such as who’s attending, what style you’re using, and how new your team is. In many cases, they can be significantly shorter. You’ll learn what works for your specific team as you run through a few of the examples below.

Who should be at the sprint retrospective meeting?

The point of a sprint retrospective is to highlight all of the ways your team might improve in the future. And so it’s important to have a diverse set of voices present. In almost all cases, your sprint retrospective meeting should include the product owner, scrum master, development team members, and potentially even project stakeholders.

What are some red flags to watch out for during a sprint retrospective?

Any full team meeting runs the risk of going off the rails. But it’s especially risky when your team is talking about failures, mistakes, or places for improvement.

As you run your sprint retrospective, be sure to watch out for these red flags:

• Don’t let teammates feel like retrospectives are being used against them: These meetings need to be a safe space for open discussion. But that won’t happen if your team feels like talking about their mistakes will lead to punishment. Make sure to express how the insights from the retrospective meeting will be used otherwise you’ll end up with a lack of conversation or apathy.
• Make sure ideas from the retrospective are followed up on and turn into real actions: The goal of the retrospective is to facilitate continuous improvement not just air grievances and complaints. Make sure you have a process in place for capturing ideas and turning them into actionable tasks or user stories.
• Don’t use the same format every single time: Like any meeting, sprint retrospectives can get repetitive with time. To get the most out of them, make sure that you switch things up, such as:
  • Cadence: Do you need a retrospective after every one-week sprint? Try experimenting with when and how often you run these meetings.
  • Style: Don’t use the same process each time. We’ve provided 7 different examples of sprint retrospective ideas you can try out below.
  • Who’s there: While the core team should stay the same (product owner, scrum master, development team), try switching up other members. For example, invite project stakeholders or other teams doing dependent or complementary work.
• Be aware of the context (i.e. is your team in “crunch mode”?): Your team will have a hard time being retrospective if they’ve got a deadline breathing down their necks. Make sure the retrospective you’re planning is the best use of time given your team’s current commitments.

The goal of the sprint retrospective is to facilitate continuous improvement not just air grievances and complaints.

5 steps to run an effective sprint retrospective and make real change

Ok. Now that we understand what a sprint retrospective is, when it happens, who attends, and what to watch out for, let’s get into the specifics of how to run one.

What we’re going to cover here is more of a sprint retrospective template. While it covers every aspect you need to consider, it’s more of a barebones process that you can either choose to follow or dress up with your own style and flair (we’ve listed a few alternate sprint retrospective ideas below).

If you’re new to running these sorts of agile retrospectives, start with the basics. With time, you’ll learn what works best for your team and your project.

1. Prepare and gather your tools

If you think you’re going to bring your team together for a sprint retrospective and just wing it, well… Good luck to you!

Every meeting needs preparation to be a success and a sprint retrospective is no different. A few days before your meeting is set, take some time to prepare and gather the tools you’ll need. At a minimum, this means you should review the notes and actions for the previous retrospective and ask a few questions:

• Did these actions actually take place? Why or why not?
• Did you get the depth of insight you were hoping for? If not, what questions can you ask that will prompt your team to be more introspective?
• Are there recurring themes popping up in previous retrospectives? If so, how can you dig deeper into them and find real solutions?

Next, you’ll want to gather the tools you need to properly conduct your sprint retrospective. These are collaborative meetings and so you’ll need to make sure you have:

• A meeting space booked for the maximum allotted time plus extra for set-up and tear-down
• Whiteboard or somewhere else to put up insights
• Markers and sticky notes for team members to write their thoughts
• A timer to keep the meeting on track
• Project management tool like Planio to organize insights and turn them into actionable tasks
• Sprint retrospective template to keep you organized

Note: If you’re a remote team, think about using a video conferencing tool like Planio Meet and a shared Planio Wiki instead.

2. Set a time for the meeting and send an agenda

Now that you’ve thought through your sprint retrospective and gathered your tools, it’s time to set a meeting time and invite your team (and anyone else who’s going to attend). However, simply setting a meeting time isn’t enough. As we wrote in our Guide to Running Effective Meetings:

“Don’t just set a meeting and hope that things will progress on their own. You need to steer the ship. This starts with understanding exactly what you want to get out of the meeting.”

Every good meeting needs an agenda to set expectations and put everyone on the same page before they show up. At a minimum, outline what’s going to be talked about, who’s running the meeting and your ideal schedule. Read more about how to keep your meetings on track with our Guide to better Meeting Notes.

You’ll also want to take a few minutes to gather data to help everyone remember what happened during the previous sprint. This is especially important if your sprints are longer (like one month).

Go back into your project management tool and look at the completed tasks and issues from the previous sprint as well as what came out of your sprint planning meeting.

For example, here’s a sample agenda for a 45-minute sprint retrospective:

• Opening (5 minutes): Set the stage and discuss the goal and outcome of the previous sprint (or more).
• What went well (10 minutes): Give everyone time to talk about the positive aspects of the sprint.
• What needs improvement (10–15 minutes): Move onto what needs improvement.
• Next steps (10 minutes): Concentrate on what you can do to improve or fix those issues you just identified.
• Closing (5–10 minutes): Leave a bit of time to thank everyone and run through the list of follow-up items, who’s responsible for them, and when they’re due.

3. Before the sprint retrospective starts: Establish a set of ground rules

Once everyone has arrived for the sprint retrospective, take a few moments to welcome them and establish a set of ground rules that will guide the meeting, such as:

• This is a positive ceremony: No matter how the last spring played out, make sure everyone knows that the point of the retrospective is to focus on continuous improvement of the team and processes. Stay away from the blame game and put the onus on ways to move forward.
• Don’t make it personal (and don’t take it personally): Project management is about people. But a sprint retrospective is about processes. Make sure everyone knows that they’re critiquing workflows, situations, and systems, not the individual actions of other teammates.
• Everyone gets an opportunity to speak without being interrupted: Respect the agenda and ask everyone to listen with an open mind.
• Set boundaries of discussion: Set a limit on what’s going to be discussed and don’t fall into the trap of “backpacking”—bringing up issues from previous sprints, quarters, or years.

4. During the meeting: Run through what worked, what could have been better, and the next steps

Alright, now that everyone’s on the same page, it’s time to get into why you’re all here.

While there are many different ways to run a sprint retrospective (we cover 7 of them below), the best is often the simplest. This means going around the team and asking people to quickly talk through their answers to two questions:

1. What did we do well? Start the meeting off on a positive note and discuss what went well. Rather than staying high-level or issue-oriented, dig into specifics such as:

   1. What motivated us to act this way?
   2. What did we do differently from past sprints?
   3. Which skills or knowledge contributed to the success?
   4. How did the team work well together?
   5. What was the process or workflow that made this success happen?

2. What should we have done better? Once you’ve heard from each team member, it’s time to dig into what didn’t work as well. Again, this isn’t about the performance of an individual, but about the processes and workflows that held the team back. Ask about processes, tools, or even schedules. This might get awkward (especially if you’re the person who set some of these processes in place), but remember that this is an opportunity to improve for everyone. Don’t take it personally.

Give each team member the opportunity to speak and have their thoughts heard and then stick a summarized version onto the whiteboard (you can even use different colored stickies for the different questions). Have the facilitator or scrum master group similar or duplicate ideas together.

Project management is about people. But a sprint retrospective is about processes. Make sure everyone knows that they’re critiquing the processes, not the individual actions of other teammates.

Finally, focus on the next steps you can take as a time to improve and fix these issues. This is more of an open discussion but it still needs to be tightly focused on actionable tasks. As people give their ideas, ask them to be specific so their ideas can be turned into actions.

Once there are a few solutions up on the board, group them together and discuss it as a team. What should take the highest priority? Who is going to take ownership or seeing that change happen? When will it be due?

Make sure you have a solid plan of action before everyone leaves the meeting.

And remember, this won’t always be easy. Emotions will inevitably run high when discussing failures (even if they aren’t publically pinned to a specific teammate). But as Shaun Gamboa, a veteran scrum master, explains:

“A successful retrospective means someone’s feelings probably got hurt but then they took that lesson and became a better team member from it. An unsuccessful one means no one had anything to say.”

5. After the sprint retrospective: Document what was discussed and update your product backlog

Team meetings are one of the most expensive uses of time you have. And there’s no point in taking everyone away from their work if you’re not going to see tangible benefits.

After the sprint retrospective is done, take a photo of the board and then transfer those tasks and issues into your project management tool. Using Planio’s powerful task management system you can add each next step as a new issue alongside the rest of your tasks, user stories, and product backlog.

You can then give them a priority and due date, attach them to your next sprint or milestone, assign them to the agreed-upon team member and even link them to the full Meeting Notes you have written up already.

Not only does this ensure that your big ideas get seen through, but it also gives you a record of each sprint retrospective that you can go back through before the end of your next sprint.

7 unique sprint retrospective templates and examples to supercharge your meetings

Like any process, once you’ve run through your sprint retrospective a few times it’ll get familiar. And then boring. The point of these meetings is to inspire your team to look for changes and get excited about future projects, not to doze off as you go through the same steps over and over.

In order to keep your sprint retrospective meetings fresh and interesting, you need to switch the style up from time to time. This doesn’t have to be a drastic change, but simply a different way to think about those same core questions:

• What went well?
• What didn’t?
• What do we do now?

Here are a few different sprint retrospective examples and templates you can use when it’s time to switch things up for your team:

1. Start, Stop, Continue

At its core, a sprint retrospective is asking what you should start, stop, or continue doing. And that format is a great way to think about running them (as opposed to the traditional “what went well/wrong?”)

However, as Kuba Niechciał, engineering manager at Intercom, explains:

“The order of Start, Stop, Continue is broken. The best sessions should begin with Continue, progress through Stop, and finish on Start.”

His reasoning is that we all love to think about new things and it’s easy to get overwhelmed thinking about what you should start doing. However, every new action or workflow you start has a trade-off.

Instead, focusing on what you should continue to do means your team is reflecting on what’s currently working. Next, stop is a more forceful way of asking what’s blocking your final potential. And finally, at this point, you know the trade-offs you’re willing to make to start something new.

How to use Continue, Stop, Start:

1. Set up a whiteboard or shared document with three separate areas: Continue, Stop, Start
2. Give each team member a set amount of time to add to each section
3. Group similar ideas and discuss them as a team. The top suggestions from each are added to actionable tasks, given a due date and owner.

2. The 4 Ls: Liked, lacked, learned, longed-for

The 4Ls help you look at your previous sprint from a more factual perspective and ask what you liked, lacked, learned, or longed-for. It’s an especially good process for looking at longer timeframes (like months, quarters, or years).

How to use the 4Ls:

1. Set up a whiteboard with four quadrants labeled Liked, Lacked, Learned, Longed-for
2. Spend around 10 minutes as a team filling in each quadrant
3. Organize answers and prioritize each section either as a new issue, lesson learned, or process change.

3. Glad, sad, mad

While you might want your retrospective to be all about the facts, it’s inevitable that emotions will take over from time to time. So occasionally, you might want to give your team time to look back at previous events from an emotional viewpoint. That’s where Glad, Sad, Mad comes into play.

Think of it as a combination of the traditional sprint retrospective template and group therapy!

How to use Glad, Sad, Mad:

1. Divide a whiteboard into three areas: Glad, Sad, Mad
2. Give everyone 10–15 minutes to write down observations from the previous sprint that fit into each category
3. When the time is up, go around the room and ask each person to briefly describe their notes and place them in the corresponding area
4. Group similar observations and then discuss the most common ones as a group
5. End by coming up with a list of next steps for each of the most-common or contentious issues

4. The sailboat method

Visual metaphors are great for changing the way people think about past events. In the Sailboat method, you visualize your team as a boat heading towards an island surrounded by rocks. There are things propelling you forward (like wind), holding you back (like an anchor), risks (like rocks) and an ultimate goal (the island).

Use this image as a starting point to discuss the outcomes of the previous sprint and re-group around your ultimate goal.

How to use the Sailboat method:

1. Draw a picture of a sailboat with all of the elements around it: wind, anchor, rocks, island. (If you’re not artistically talented, you can download an image or just list each section as a row on a whiteboard).
2. Set the stage and explain what each element signifies and re-state the ultimate goal of the previous sprint to make sure everyone is on the same page (this is your island!)
3. Ask each team member to write down ideas or factors that helped the sprint move forward, slowed it down, or are potential risks.
4. Add the ideas to the corresponding areas and then group similar ones together
5. Discuss which ideas or risks are the highest priority and transfer them into actionable tasks

5. Dot voting

Many of these sprint retrospective ideas have some version of “group ideas together and vote on the most important.” However, this seemingly simple process can end up slowing things down significantly. Loud voices prevail and you end up with a biased view of your team’s priorities.

Dot voting is an easy way to get equal input from everyone and consensus on what issues deserve your time.

How to use dot voting:

1. Once you have a ton of ideas up on your whiteboard give each team member 3–5 “dots” to place on their top choices. Multiple votes can be placed on a single idea (if you feel strongly about it).
2. When you are finished, tally up the votes and move onto the next steps

Use your sprint retrospective to reflect on anything. The best way to avoid future mistakes is to get clear about past ones.

6. Dig deeper into the issues with the “5 whys”

Another common issue you might come up against when doing your sprint retrospective is not getting at the heart of the issue. Especially when talking about failure or mistake, it’s easy for people to hold back their true thoughts. In this case, you need a way to break down what they’re really thinking.

The 5 Whys is a strategy used to dig into pain points and find the real issues that need to be resolved.

How to use the 5 Whys:

1. Identify risks, failures, or issues that aren’t clear enough or need more details
2. For each, ask “why?” a number of times (up to 5)
3. Give 5–10 minutes maximum for each pain point
4. Digging deeper will help you identify root causes and long-term solutions

7. Significant events

If you’re doing a retrospective after an especially long sprint or even after a quarter, it’s important to set the stage and get everyone on the same page. At this point, it’s good to create a “shared history” for your team.

Everyone remembers things differently. So give them each an opportunity to highlight the most significant events across the given time period.

How to use Significant events:

1. Find a big whiteboard and draw a horizontal line across it
2. Ask each team member to come up and mark what they see as the most significant events across the timeline—releases, wins, failures, changes, etc…
3. Use this as the set-up before moving onto the rest of your sprint retrospective

Agile teams made retrospectives popular, but they work for any team

While sprint retrospectives are firmly rooted in the world of Agile product development, we can all benefit from a structured process for learning from past mistakes.

You can use these sprint retrospective examples and templates for reflecting on anything: sprints, personal achievements, company goals, etc… The best way to avoid future mistakes is to get clear about past ones.