How to Run a Sprint Retrospective with Miro’s Distributed Team Retrospective Templates

 Everyone understands the importance of a Sprint Retrospective, yet as our teams become more distributed, it becomes even harder to run one successfully. Scrum masters are trained to perform sprint retrospectives in person with their team, but what to do if someone in your team is becoming distributed? We created this guide to show you that even if you can’t be in the same room, it’s still possible to lead a successful retrospective.

We also complemented the guide with useful tips from Lieuwe van Brug from, who has practiced running retrospectives with distributed teams many times.

What is a sprint retrospective in Agile?

A sprint retrospective meeting, also called an Agile retrospective, is a brief exercise where scrum team members discuss what could have made the last sprint/scrum more efficient. Its goal is to allow the scrum team to reflect on the sprint and determine how they can use that knowledge to improve future sprints. In essence, it is a meeting where the previous sprint is discussed.

Sprint retrospectives usually happen at the end of each sprint and help build a strong scrum framework through continuous improvement. This helps make the next sprint planning much easier for the scrum master/product owner/whoever is running the next sprint/scrum.

Read our recent post on agile methodologies for product managers


Lieuwe van Brug

coding architect and Agile specialist with over 20 years of experience, founder of

Follow him: on Twitter or LinkedIn

Historically, the whole team has met in a conference room for the exercise, but today’s prevalence of distributed teams requires new solutions.

 Lieuwe van Brug, founder of

The driving principle for the retrospective is that a team can always do better and should always be looking for ways to improve. It’s best applied in environments where a set team works on multiple projects or iterations. A retrospective should not take more than two hours, and includes the entire team as well as a facilitator.

A successful retrospective will generate outcomes that are quantifiable actions. It’s not enough to recognize what went well, or what problems were encountered, one has to generate a list of commitments for further iterations that will improve the team’s performance in the long term.

Read our full guide to team building activities and games to be a better facilitator

How to run a sprint retrospective in 5 steps

The scrum handbook is deliberately vague on exactly how to perform a retrospective, instead, leaving it in the hands of the scrum master to determine the best methods for each team and scenario.

That being said, there are several steps that every sprint retrospective should include.

Make sure you also check our post on the barriers to successful sprint retrospectives.

Step 1: Attendance and engagement

For a Sprint Retrospective to be worth the effort, the entire team must be involved. That means that everyone must be present and take part in the event. After people have completed several previous retrospectives, they are liable to lose interest and not contribute. It’s the Scrum master’s job to ensure everyone stays engaged and they should be ready to change direction if they feel that their initial techniques are not working. It’s also important that all participants feel free to express their honest opinion, free from the threat of retribution. If someone is afraid to discuss a problem, it will remain a problem for the next Sprint.

At the same time, it should be recognized that a retrospective’s goal is not to point out individual people’s mistakes, but to figure out how the team can improve. As such, all participants need to accept that everyone did the best work they could, given their skills and knowledge at the time.

Lieuwe van Brug from has practiced running retrospectives with distributed teams to a great extent, so here is the tips from the pro:

  • Be creative and surprise the team if you are responsible for organizing the retrospective. If you vary a lot in how you organize it, you get a lot of different feedback
  • Retrospectives are a lot about emotions, attitude, etc. When you are in the same room, you can read someoneʼs attitude, body language. This is easily lost in a distributed environment

The retrospective is then often very factual. And thatʼs not per definition a bad thing, only you miss out on a lot you could learn from.

To solve this — partially — you could use good cameras and make sure everybody is visible during the retrospective. Body language is an important part during discussions. Just the fact of being aware of the risk of losing the emotional part can be helpful. Asking more explicitly on emotional subjects can improve the situation as well.

An agile team should be a team and operate as a team. Emotions play a big part in that.

Step 2: Sprint review

The entire retrospective should only take an hour and a half, with most of the time dedicated to discussion. To aid that, a quick summary should be provided of the Sprint in question. Mention key facts, such as what the plan was, how it was followed, and what the outcomes were. This brings everyone onto the same page, and gives people a feeling for whether the Sprint was a success or not, from a measurable standpoint.

Tip from Lieuwe van Brug from

  • Choose subjects you want to focus on during a retrospective. One subject per sprint. Zoom in and make sure you get an actionable solution. If you focus on different subjects every sprint, you donʼt get the same problems mentioned every time.

Step 3: Discussion

The discussion is the main part of any retrospective. It can be very open-ended, so it’s best to use predefined tools and methods to ensure proper outcomes are met. The Scrum master should make use of the tools that they’re most familiar with and that they feel will prove most useful. Examples of such tools are provided later in this article.

Most tools focus in some way on what the team feels went well in the last iteration, what they need to stop doing, and what different things they can try for the next iteration. Ideas should be generated by the team, and recorded for evaluation. Reference can also be made to actions as defined in a previous retrospective.

Tip from Lieuwe van Brug from

  • One of the things I personally always pay extra attention to is making sure that everybody is heard. People are different. Some are loud and very outspoken. Some are quiet and observe more.

Itʼs important to catch everyone’s opinions. In a live environment, this is already challenging, so remotely, itʼs even harder.

LIEUWE VAN BRUG, founder of

One of the things you can do is to give everybody a personal part somewhere on Miro. Copy the visuals you are going to use during the retrospective per person and let every person zoom in on their personal part of the board. This way, everybody can fill out in different rounds the good, the bad, etc. In the discussion rounds you assemble all input to a central place on the board. This way you make sure everybody is heard.

Step 4: Actionable commitments

The main goal of the retrospective is to identify what actions must be taken in the next iteration. From the ideas discussed, the team should determine measurable actions that they can implement.

When we say measurable, what we mean is: it’s not enough to say that code reviews need to be done more quickly. Instead, a value must be assigned to the statement. For example, all code must be reviewed within 4 hours of submission. This way, it is clear to tell whether an item is achieved or not, and gives team members a set goal to work towards.

It’s important that there is a consensus among the team on the final actions.

Your end result should be a list of less than ten items, preferably five, which the team agree to work on, and will aim to achieve for the next Sprint.

Tip from Lieuwe van Brug from

  • Make sure that you prioritize what to solve in one sprint. Donʼt be too ambitious. Small achievable goals work better and are sustainable over longer periods of time.

Step 5: Retrospective retrospective

At the end of your Sprint Retrospective, it’s important to take five minutes to discuss how the retrospective went. Be open and encouraging of feedback from the team, and in the same way as the Sprint was discussed, look at ways to improve the Sprint Retrospective the next time round. If new tools were used, how effective were they?

5 retrospective templates for remote sprints

Any Scrum master will be able to tell you how important it is to use the right retrospective technique for a specific team. Both the team and the facilitator’s experience can play a large part in the success of a retrospective, and different tools can be used to enhance different situations.

Online whiteboarding tools offer all the benefits of a traditional whiteboard, while giving all participants an unhindered view with the ability to add and edit information in real-time. An online whiteboard can be used in a single location on a shared computer, but has even more value as a tool for remote users.

Using this tool you can also benefit from keeping all the retrospectives’ results at one endless online board, so it helps jump-start discussion for the next retrospective.

To start your next retrospective, just choose one of pre-made templates, several of which are discussed below.

We’ve included 5 popular types of sprint retrospective templates: 

  1. Start, Stop, Continue
  2. Glad, Sad, Mad
  3. 4 L’s
  4. Quick Retrospective 
  5. Sailboat

The beauty of retrospective tools

is that the majority of them revolve around the use of a whiteboard and sticky notes, with variations on how the board is divided and what is recorded. This has made it extremely easy to convert the retrospective to the digital realm.

1. Start, Stop, Continue

Start using this template in Miro

The Start, Stop, Continue method is aimed at quick idea development. Instead of listing all topics, grouping them and then trying to action specific groups, this technique tries to identify actions straight away.

The team should reflect on three things:

  • What should the team start doing?
  • What should the team stop doing?
  • What should the team continue doing?

A template is separated into three areas, labelled: start, stop and continue. Participants add digital sticky notes to each column, identifying actions that they want to start doing in the next iteration, and those from the previous iteration that they want to stop doing, or continue doing.

The actions don’t have to be measurable, but the previous iteration can be used to generate benchmark values to help define the actions for the next run.

2. Mad, Sad, Glad

Start using the Mad, Sad, Glad retrospective template in Miro

This technique is one of the most common ones used. It is fairly simple, which makes it a good starting point for new teams. Initially, participants are given 15 minutes to come up with a list of observations they’ve made from the previous sprint. They record each observation on an index chart.

Each participant is then given the opportunity to describe their observations and place it on a whiteboard. The whiteboard is divided into three areas: Glad, Sad and Mad. The participant places the observation in the column that best matches their feeling of the observation, what make them glad, sad or mad.

Observations are again grouped by similarity and voting takes place to determine which ones have the most value. Thereafter, a discussion takes place on the highest voted topics. The conversation must be driven towards determining actions for the next Sprint.

The exercise can continue until the time is up or all the important topics are actioned.

3. 4 L’s

Start using the 4 Ls retrospective template in Miro

The 4 L’s is a variation on the World Café, developed by EBG Consulting. During the exercise, participants are requested to write down on sticky notes everything that they liked, learned, lacked, and longed for during the Sprint.

After some initial thinking time, participants are asked to place their sticky notes on the respective boards.

The group is then split up into four groups, one for each L. Time is then given for the groups to analyze the sticky notes on their board and to group them according to similar themes.

Once completed, each group reports on their findings, and then all participants discuss together what they can do to address the individual themes.

4. Quick Retrospective

Quick Retrospective

The Quick Retrospective template negates any fancy metaphors and dives straight in, asking direct questions: what was good and what was bad. Participants list their thoughts on sticky notes and place them in the appropriate box.

At the same time, the team must come up with new ideas that they want to try in the following Sprint, even if it’s unclear how effective it is going to be. Once all of these thoughts are on the board, the team must discuss them and come up with actions that they are going to take.

Everything gets recorded on the board where it’s up for everyone to see. It is a good starting point for new teams who are not experienced with retrospectives as it’s easy to understand and get going.

5. Sailboat


The Sailboat is a technique that compares the Sprint to a sailboat. It was originally developed by Luke Hohmann. In the same way that a sailboat is propelled forward by the wind, and held back by anchors, a Sprint has factors that slow it down and speed it up.

The team records things that they felt helped the Sprint move forward or slowed it down. These are then placed either on the sail or below the boat, indicating that they are anchors or wind.

Once all the ideas are on the board, select a team member to group the sticky notes into similar categories. Get feedback from the rest of the team as to whether the grouping is fair, or if changes should be made.

Once the grouping is complete, have the team vote on what they feel are the critical groups to focus on. Once you’ve identified key groups, you can start some root cause analysis and develop some outcomes.


Although the thought of running a Sprint Retrospective for a remote team may have sounded like a nightmare previously, we hope that this article has informed you otherwise. Online whiteboards provide a secure environment for running Sprint Retrospectives that can easily be accessed by an entire team, no matter where they are located.

Miro offers a number of preconfigured templates to get your retrospectives started in record time, allowing your team to stay immersed and engaged over multiple Sprints.

Miro is your team's visual platform to connect, collaborate, and create — together.

Join millions of users that collaborate from all over the planet using Miro.

Try Miro