12 Fun & Useful Sprint Retrospective Ideas (& Why They Work)

12 Fun & Fresh Sprint Retrospective Ideas (& Why They Work)

While sprint retrospectives are an essential meeting for agile teams, they can quickly get stale and repetitive. To help you avoid this issue, we’ve gathered 12 ideas for keeping your retros fresh, fun, and useful.

These ideas cover three overarching themes:

With that in mind, let’s look at the 12 sprint retrospective ideas in more detail.

Note: We’ll be using Geekbot — our free retrospective tool for Slack and Microsoft Teams — to show how you can implement some of the ideas in this article. Visit our website to learn more.

1. Asynchronous Retrospectives

As we’ve discussed before, asynchronous retrospectives — where people answer retrospective questions on their own time — help you avoid the serious drawbacks of synchronous meetings, including:

  • Scheduling difficulties, since you don’t have to worry about multiple people on the same call.
  • Workflow disruptions, since participants don’t have to stop what they’re doing to join the retrospective.
  • Overly-long meetings, since answering the retrospective questions only takes a few minutes out of everyone’s workday.

As a distributed team, we know the benefits of asynchronous meetings first-hand. In fact, these benefits prompted us to create Geekbot — an asynchronous meeting tool used by over 170,000 users, including remote teams within Shopify, GitHub, and Zapier.

You can also use Geekbot to replace asynchronous retrospectives, with faster and less-disruptive asynchronous ones.

Here’s how:

First, our tool has a “Retrospective” template, which helps teams reflect on previous sprints.

By default, this template includes four questions:

  1. What went well?
  2. What didn’t go so well?
  3. What have you learned?
  4. What still puzzles you?

However, you can fully customize the template by adding, changing, or removing any questions. There’s also no limit to the number of questions you can ask.

Next, you select when Geekbot should send these questions to the retrospective participants (e.g., every last Friday of the month at 2 PM). Just like the questions, the schedule is also fully customizable.

At the specified date and time, participants get a Slack or Microsoft Teams DM with the retrospective questions.

Daily Status Updates: What went well? What didn't go so well? What have you learned? What still puzzles you?

Their answers get posted to a channel of your choosing. For example, you can post them in a channel like #general or #dev, or create a dedicated #retrospectives channel to have all answers in one place. From here, everyone can easily skim through their colleagues’ answers and discuss specific issues in a thread.

2. Staggered Retrospectives

Retrospectives can produce a lot of great ideas for improving your work processes. However, there’s often a lack of follow-through, as many of these ideas are discussed during the retrospective but never implemented in the next sprint.

In our post on how to run a sprint retrospective (based on Danny Varner’s method), we discussed how to avoid this issue by staggering your retrospective across four days:

  • Day 1: Data collection. You start by sending the retrospective questions and gathering everyone’s answers, as you would in a classic asynchronous retrospective.
  • Day 2: Consolidate insights. Then, you take the team’s responses and run a poll that asks “Which 3 things do you think we should address right now?”
  • Day 3: Decide what to do. Next, you run another poll that asks “What is something actionable we can do to change this issue?” This prompts your team to start brainstorming solutions.
  • Day 4: Commit and close the retrospective. Lastly, you put your team’s answers into a proposal and send out a poll with one final question — “Which actions from our retrospective will you do in the next 2 weeks?” This ensures the retrospective ends with a commitment from your team to follow through on key action items.

Each day of this staggered retrospective builds upon the answers and insights from the previous ones. Additionally, waiting a day between each step gives people time to reflect and think clearly about their answers.

Note: You can stagger your next retrospective like we just showed with Geekbot’s retrospective template and survey features.

3. “I Don’t Like Our Retros Because…”

Sometimes teams lose trust in retrospecitves to the point where they treat it as a time-wasting meeting that are obliged to attend.

In that case, trying to find one specific reason becomes counter-productive, as often it’s a combination of factors.

To get you out of this situation, try the “Why I Don’t Like Our Retros” format.

Ask every team members to anonymously write a journal that starts with a sentence “I don’t like our retros, because… ” about why they don’t like retrospectives. Let them just leave it all on the paper (or use anonymous pool tool like this one).

Here’s an example from one of the team members:

Ask your team members for unfiltered feedback. Let them ven out all of their frustration. To faciliate raw feedback, make sure the poll is anonymous and time box it. For example, give everyone 2 or 3 minutes. If that didn’t work out and people still hold back, ask them to use voice-to-text software that will autmativally turn their speech to text.

Important: this technique is to be used with caution. You will get a ton on raw, useful feedback, but if you don’t use it to improve and fix issues listed, your team trust will fall.

You can also use this technique to analyze recurring issues within Sprints.

4. The “Why” Retrospective

Sometimes it’s vbery hard to understand why a certain sprint issue persists for weeks and even months. Especially when different people have different opinions about it.

To gain more transparency and facilitate group thinking, let’s apply a common “Five Whys” technique to your retrospectives to better understand your Sprint issues, or any other issue, for that matter.

Here’s how to run the “Why” Retro:

  1. Get a list of issues from your team members from current or last sprint. (every retro should end with forming such a list)
  2. Pick one (usually the top one of the most pressing one)
  3. Ask every team member to answer the “Why this is an issue?” question
  4. Now, add “Why” to whatever answer they provided and repeat again
  5. Each team member will have their own chain of “Why” questions and may arrive to a different conclusion about why a particular issue persists.
  6. Add as many “Why” as possible, but don’t overdo it.
  7. If your “Why” chain leads to nowhere, try reframing the issue or start new chain where the last one ended.

Use gathered data to better understand communication silos in your team and how people preceive issue within your projects.

Here’s an example:

5. The Start, Stop, Continue Retrospective

The Start, Stop, Continue retrospective is one of the most popular alternatives to the classic retrospective. It includes three questions:

  • What should we start doing?
  • What should we stop doing?
  • What should we continue doing?

It’s a very simple and straightforward way to run a retrospective that doesn’t explicitly bucket items into “good” and “bad” categories.

Note: You can recreate this retrospective in Geekbot by simply changing the questions that get sent out.

6. The Sailboat Method

The sailboat retrospective is a great way to mix things up and stimulate out-of-the box-thinking. It includes four questions:

  • What’s holding us back? (the sailboat’s anchor)
  • What threats/risks do we face? (the rocks)
  • What is pushing us forward? (the winds)
  • What are we working towards? (the island)

Meeting facilitators can even visualize the sailboat and have the team use sticky notes to make the process more engaging.

The Sailboat Method: Wind (Helped us forward), Sun (Made us feel good), Anchor (Held us back), Reef (Future risks ahead)

Source: Sailboat retrospective visualization by Miro

7. The Starfish Method

Similar to the previous entry, the Starfish retrospective is about switching things up with an interesting metaphor. To run this retrospective, you need to split up a canvas or whiteboard into 5 areas:

  1. Start
  2. More of
  3. Continue
  4. Less of
  5. Stop
Starfish Retrospective Method: Start, More of, Continue, Less of, Stop

Source: Starfish retrospective visualization by TeamRetro

From here, participants fill out each category with sticky notes. The benefit of this approach is that it’s very specific. Rather than just saying what happened, participants provide a more detailed breakdown, which can help you identify the root cause of certain problems and make continuous improvements to your work process.

8. The Three Little Pigs Retrospective

The Three Little Pigs retrospective uses the classic fairy tale to highlight which projects or areas of your work may be under serious risks.

This method requires participants to place items into three categories:

  • House of Straw — this is where you put the items with the highest risk of breaking or malfunctioning.
  • House of Stick — the items here aren’t as critical as the ones in the previous category, but they still require some work and attention in the next sprint.
  • House of Brick — here are solid items that don’t require any immediate improvements.

Finally, for each item you put in the first two categories, write down what’s the “Big bad wolf” that can blow the house down — e.g., an overwhelming number of support tickets, excessive traffic to the site, or a service malfunction. This lets you assess the risk and prioritize the tasks for your next sprint accordingly.

9. The Glad, Sad, Mad Retrospective

This retrospective helps you get a better understanding of your team’s emotional state after the last sprint.

It includes three simple questions:

  • What are you glad about?
  • What made you sad?
  • What made you mad?

The benefit of using these questions is that you uncover how your team feels, instead of focusing only on what they did. This can help you find problems that plague a large part of your team, such as tight deadlines or cross-team collaboration.

10. Add a Kudos Section to Your Retrospectives

One of the simplest ways to make your retrospective more positive is by simply acknowledging team members who did well. This is usually done toward the end of a retrospective, as it helps you end on a high note.

However, you can also start your retrospective by giving kudos to different participants. This can act as a positive icebreaker and a natural transition toward the retrospective topics.

11. The ESVP Game

ESVP is a retrospective game popularized in the book “Agile Retrospectives: Making Good Teams Great”.

During the game, participants split up into four groups, depending on their attitudes toward the retrospective:

  • Explorers want to discover new ideas and insights.
  • Shoppers analyze information and aim to learn at least one useful idea.
  • Vacationers aren’t interested in retrospectives, but enjoy taking a break from the daily grind.
  • Prisoners feel forced to attend the retrospective and would rather do something else.

The game starts with the Scrum master explaining what each role entails and giving team members a bit of time to think about their role.

Then, let participants place themselves into one of the categories anonymously. This can be done by using slips of paper or an anonymous poll tool like Geekbot.

The goal of this experiment is to see how the majority of people feel about the sprint retrospective meetings. For example, if most participants identify as prisoners, there’s a serious issue that must be addressed before you can run effective retrospectives.

12. Truths and Lies

During this retrospective game, every team member comes up with three statements about the project, sprint, team, or work process. Two of those statements should be true, while one should be false.

The game is simple — participants share their statements and the rest of the team has to collectively guess which statement is fake. Statements that cause a lot of debates are often points of friction (or have the potential to become ones), so pay special attention to them.

Note: This game is recommended only for Scrum teams that know each other well and have a high level of trust.

13. Return of Time Invested

Unlike the previous two games, this one is played at the end of each retrospective. The premise is simple — you draw a chart on which participants indicate how useful the current retrospective was in terms of finding issues, gathering feedback, and general organization.

ROTI: Return of Time Invested graphic

This chart isn’t discussed during the meeting. The point is to gather everyone’s feedback while the retrospective is still fresh, make iterations over time, and compare it with charts from future retrospectives to see if you’re moving in the right direction.

14. One Question

This final game is about ending your retrospective on a high note. Again, the premise is very simple — you ask each participant to answer one question.

The trick is to frame this question in a positive way like:

  • Which colleague helped you out the most?
  • What are you most excited about for the next sprint?
  • What’s the one thing that improved the most during this sprint?

This framing helps team members think of retrospectives as positive experiences, rather than just problem-focused discussions.

15. Quick Wrap

Sometimes retrospecitves run too long, causing disengagement. Worse yet, disegagement becomes habitual, and whatever you do and no matter how many games you try, people are just not engaged.

In that case, here’s a challenge for you.

Conduct a retrospective as quick as possible.

But with all the required deliverables:

  1. List of issues form the last sprint
  2. List of actions to fix the issues from the last sprint
  3. Report about issues that you solved based on #1 and #2 documents.

The goal is to gather feedback in a usual metter, forming a list of issues that affected team productivity and action plan to address them during the next sprint.

Try doing all that in under 10 minutes.

If you succeed, try doing it in 5 minutes during next retrospective.

It’s crucial to still analyze action plan and how succesful you were at resolving issues in the next sprint (deliverable #3). If nothing changed and you didn’t improve, then you failed to conduct a proper retrospective, and you should repeat again.

Start Running Asynchronous Retrospectives with Geekbot for Free

Geekbot can help you run faster and less-disruptive asynchronous retrospectives, as well as many other remote check-ins, like standups, surveys, 1:1s, and much more.

Geekbot is also free for teams with up to 10 active participants. For larger teams, pricing is $2.50 per active user on the annual plan and $3.00 per active user on the monthly plan.

Click here to create a free Geekbot account.

You may also like…