Sprint retrospective meeting ideas for remote teams

Sprints tend to involve multiple meetings to discuss, dissect, and resolve any issues, changes, and plans for the next round. One of those meetings is often a sprint retrospective, or retro. The purpose of the retro is to determine whether and to what extent a sprint could have gone better or worse.

There are multiple ways to conduct retrospectives. Oftentimes, advice on how best to run one focuses on in-person teams. As more and more work happens outside the office, it’s time for retro advice geared toward hybrid, remote, and distributed teams. 

If you’re a newly-minted scrum master, a team member or even a long-time product owner, understanding the remote sprint retrospective and how to improve the experience can benefit you, your team, and ultimately, the product. 

Read on for more about what a sprint retro is and how to set your next remote retro up for success. 

What is a sprint retrospective?

Part of the four types of scrum meetings, the sprint retrospective, is focused on the process – and the people. The meeting is typically held between sprints and can be done on the same day as the sprint review and sprint planning meetings. This gives the scrum team a chance to look back at all the aspects of a sprint to adjust before throwing efforts into the next one. You’ll see the development team as well as the scrum master in this meeting. Depending on the team, the product owner is present, as well.

In an average retrospective, the scrum master leads the meeting. They facilitate a meeting model of their choice or one chosen with input from the team. The model helps draw out the perspectives from individual team members to impact the process followed in the next sprint. A shared ‘whiteboard’ collects the information generated by the chosen model. 

I share some useful meeting models later on, but the end goal with each is to address what went well and what went wrong with the process. Was there a particular skill or set of skills that made the sprint go smoothly? Was there knowledge – about the product, user experience, or previous sprints – present among the team that made the process better? Who contributed to the success and how? Should the definition of ‘success’ be adjusted for the next sprint based on what the team accomplished in the previous sprint? Just like products and stakeholders have their own time in the spotlight, the process that underlies the work accomplished deserves special attention. 

Setting up a sprint retrospective for remote teams

ScrumAlliance.org suggests capping sprint retrospectives at three hours. They offer a formula for determining the length based on the duration of the sprint itself. For a one week sprint, 45 minutes should work. For a two-week sprint, an hour and a half should encapsulate the needed improvements. For sprints taking a month or more, three hours may be too short. You can consider a half-day meeting dedicated to looking back.

Depending on the length of the retro as determined by the sprint, it is common to hold the sprint retrospective on the same day as the sprint planning and sprint review meetings. It can be daunting to hold each of these meetings in succession with the team in-person. It can feel even more intimidating to hold every meeting on the same day over a video conference. Even with breaks, you run the risk of Zoom fatigue and lowered participation – especially as the day goes on.

However, some teams prefer a one-day marathon to check off each of these meetings and return focus to regular work. Different projects and sprint lengths can also influence the structure and timing of each meeting. The first thing you can do if you’re a scrum master planning the retrospective is assess the length of the sprint. A shorter sprint may mean that the retrospective can stay under an hour and tack onto the other scrum meetings to fit in one day. Longer sprints may present extended time windows needed to thoroughly review the process and make changes for the next sprint. 

After a cursory look into how much time is likely needed, consult the team. Depending on the team size, you can set up a poll or create a thread in Slack or other messaging platform to take the pulse on meeting preference. Some teams prefer to tackle everything in one day, but it’s okay if a team wants to spread meetings over the course of a few days. 

Choosing your meeting model

Once the scrum master has a plan for when to hold the sprint retrospective, it’s time to choose how to best pool feedback and input from the remote team. With no physical whiteboards and sticky notes, remote teams need to be creative when it comes to maximizing time spent on process refinement. That’s where models come in. While there are many options fit for every sized team and project, here are four sprint retro models that work particularly well for remote teams.

1. Start, Stop, Continue

Simplicity is the name of the game for this model, which makes it perfect for a remote team trying to make sure each member is heard. Either individually, or as a group, the team brainstorms process components they believe the team should start, stop, or continue in the next sprint. 

This model allows team members to share informed opinions about what has been done while brainstorming new ideas for activities to improve the process for the next sprint. Depending on the size of the team, the scrum master can divide up the team into breakout groups using ‘room’ functions in Zoom or similar video conference apps. In these groups – or as a whole team – members share what they feel should be started, stopped, or continued in the next sprint. They can use a team Google doc to record their thoughts simultaneously with other breakout groups. After brainstorming, the team returns to the main ‘room’ to clean up the lists. Similar ideas can be grouped together and actions outside the scope of the sprint are set aside. 

The team then votes on each idea. The scrum master collects these votes either through Google Docs with each team member adding their name under the idea they’re voting on or through chat responses in Zoom when presenting each idea one at a time. After the meeting, the scrum master cleans up the document and ensures everyone from the meeting receives the final document. 

2. The 4 L’s

Similar to ‘start, stop, continue,’ the 4 L’s model divides each team member’s assessment of the sprint into four sections: liked, learned, lacked, longed for. In this model, team members pinpoint what they liked about the elements of the last sprint, what they learned from the sprint, what they lacked, and what they found themselves longing for. Taken together, the team can paint a picture of what should change – and stay the same – for the next sprint. 

With this model, the scrum master can build a two-column, two-row chart using tools like Miro or Microsoft Whiteboard ahead of the meeting. At the start, the scrum master sets a timer for 10 to 15 minutes allowing team members to add their thoughts to the shared ‘whiteboard.’ With an open format for participation, individual team members can contribute what they can where they can. The scrum master can engage the team with narration during the allotted brainstorming time to affirm participation and spark new contributions by posing follow-up questions to posted ideas. This can help avoid long periods of awkward silence and gives the option for team members to mute their sound to focus on brainstorming.

3. KALM

The ‘KALM’ model, or ‘keep, add, less, more’ stops short of defining pieces of process as all good or all bad. Instead, it encourages team members to think incrementally about the activities and components of a sprint. Rather than doing away with a complete piece of a process, a team may decide to dial it down. For this model, members select one component of the process to keep, add, lessen, or increase. 

Stormboard offers similar collaboration tools to Miro and Microsoft Whiteboard. They even have a KALM template to make setting up the model easy for the scrum master. The scrum master sets up the board through screen share on a video conferencing app of choice. With team members shared on the board, ideas start flowing as individuals share their opinion. This model can be especially helpful for newer teams who may not have established strong rapport. With gentler identifiers – keep, add, less, more – it stands in contrast to say, the more direct and final ‘start, stop, continue’ model which can elicit a more permanent connotation for thoughts shared. With all ideas on the board, the scrum master can begin grouping similar notes before identifying the most common patterns. The team can then discuss the recurring themes – with a timebox in place – before voting on each theme. With everyone shared on the board, team members can check-in anytime to see the guide map for the upcoming sprint.

4. Tell a Story

This particular model can be used in part with the other models to liven up a sprint retrospective – especially for long-standing teams. The concept relies on each team member composing a story about the completed sprint using a set of words that can be determined by the scrum master. These words could be as simple as ‘start, stop, continue’ or incorporate emotions such as ‘exciting, regretful, promising.’ Through each team member’s story, recurring themes and ideas come together to make meaningful changes to the process for the next sprint. To start, the scrum master defines the terms ahead of the retro and shares them with the team. At the start of the meeting, using a tool like MURAL, the scrum master can post an open board with the chosen words across the top. You can use three, four, or even five words to help guide the stories. With a timer set, the team can begin writing their story – 100 to 150 words max. When completed, each team member takes a turn reading their story. After narration, the scrum master sets a new timer for discussion. Team members weigh in and map common themes on the board, with the help of the scrum master moving stories into visual groupings. A dot vote – another feature in MURAL – brings the best ideas from each story into a list of final improvements to apply in the next sprint.

Going forward

Whatever model a team or scrum master chooses, make sure to communicate it ahead of the sprint. You may use the same model for multiple consecutive retrospectives, but informing the team ahead of time allows each member to record their thoughts, opinions, and observations during the sprint. This prevents low participation and engagement due to lack of feedback collected over the course of the sprint.

With the next sprint retrospective constantly lurking around the corner, planning the time to collaborate as a team can be an afterthought. To help build a better calendar and more certainty for team members, take a look at Clockwise. Specifically, its feature that finds the best meeting times based on every team member’s schedule and its ability to look further out to automatically schedule routine meetings – like a sprint retrospective. 

With other components of a sprint gripping a team at each stage, making time to assess the processes that put a product from point A to point B can fall behind on the priority list. Like anything, a little bit of planning can build a framework that holds up over time requiring minor adjustments to match the team’s current dynamic, the duration of the sprint, and product itself.