If you’re part of a cross-functional digital product team, you may have heard of or already taken part in a sprint retrospective.
If you’re new to product management, this guide will get you up to speed on what a sprint retrospective is and why it’s important. We‘ll also take a look at some best practices to ensure that yours runs smoothly.
Table of contents
- What is a sprint retrospective?
- When is a sprint retrospective meeting held?
- What is the purpose of a sprint retrospective?
- What is discussed in a sprint retrospective?
- Who is involved in a sprint retrospective?
- Sprint review vs. sprint retrospective
- How to run a sprint retrospective meeting
- Basic sprint retrospective meeting agenda
- Alternative sprint retrospective agendas and templates
What is a sprint retrospective?
A sprint retrospective is a scrum meeting (sometimes referred to as a ceremony) that is held once a sprint has ended to reflect on the work that has just taken place.
The sprint retrospective provides a chance for the team to review processes, ways of working, and any key learnings with the aim of improving the team’s performance during subsequent sprints.
Sprint retrospectives can be conducted remotely or in person, although the tools and process may differ slightly.
When is a sprint retrospective meeting held?
A sprint retrospective is typically held as soon as a sprint has ended and before the next sprint begins.
If your sprint is two weeks long, the sprint retrospective meeting might be as short as one hour. If you’re working on a longer sprint cycle or have a larger, cross-functional team, the retrospective might last up to three hours.
What is the purpose of a sprint retrospective?
The purpose of a sprint retrospective is for the cross-functional team to pause and reflect on how things went during the sprint. The key takeaways and learnings from the retrospective should help subsequent sprints run more smoothly.
The goal is to continuously improve how the team works together and optimize the processes and tools the team uses to deliver outstanding products and features.
What lessons might product managers and teams take away from a sprint retrospective? Here’s a quick example.
Let’s say you determined that your team wasted an inordinate amount of development time due to lack of detail on some user stories. At the sprint retrospective, you would present this finding to the team and plan to sure up all user stories before the start of the next sprint.
What is discussed in a sprint retrospective?
A typical sprint retrospective lasts an hour. There are a few distinct components that make up the session.
The introduction to a retrospective involves setting up the scene. This means asking the team to reflect on the period of the sprint.
The facilitator might start by prompting the participants to think of key themes or pieces of work that took place during the sprint. This helps to jog the team’s collective memory for the main part of the session.
If there has been a previous sprint retrospective, the facilitator might also spend five to 10 minutes reviewing any outstanding actions.
The main part of the sprint retrospective typically focuses on the following three areas:
- What went well — Celebrate things that were successful during the the sprint (e.g., designers and developers collaborated well)
- What could be improved — Review things the team felt negatively impacted their ability to get the work done during the sprint (e.g., key decisions necessary to move forward were blocked by busy stakeholders, which slowed down the team’s efforts)
- Key ideas and actions to address what could be improved — Outline ideas and actions to help solve the issues raised in the “What could be improved” section (e.g., ensure that all necessary decisions have been assigned and taken before work is submitted to a sprint)
Following the sprint retrospective session, the facilitator captures and assigns all the actions items and distributes this information to the team following the session. The team (and stakeholders, where applicable) then completes these actions with the aim of improving the next sprint and beyond.
Who is involved in a sprint retrospective?
The sprint retrospective is normally facilitated by a scrum master, but it can also be run by another member of the team, such as a delivery manager, depending on the team setup. That said, it is preferable to have a neutral third party facilitate, so you should also call on a member of another cross-functional team to run your sprint retrospective if you can.
The other members of the cross-functional team — product designers, developers, QAs, product managers, UX designers, etc. — contribute key learnings, ideas, and actions to the sprint retrospective.
Other stakeholders may be involved in the sprint retrospective if they form a core part of the cross-functional team. They may also play a part if there are actions or blockers that they can help to resolve.
Sprint review vs. sprint retrospective
Although they both occur at the end of a sprint cycle, a sprint review is quite different from a sprint retrospective.
A sprint review meeting focuses on examining the actual work (tickets completed, bugs resolved, etc.) that was completed during the sprint with the aim of updating the backlog. A sprint retrospective, meanwhile, is focused on improving the team’s performance and ways of working together.
Below are some key distinctions between the sprint review and sprint retrospective ceremonies.
|Sprint review||Sprint retrospective|
|Scrum team and stakeholders attend||Only the scrum team attends|
|Goal is to present work to stakeholders and gather feedback||Goal is to improve efficiency for the next sprint session|
|Sprint reviews finish items from the product backlog||Sprint retrospectives create tasks to improve workflow|
|Discusses what the team is working on||Discusses how the team is working|
How to run a sprint retrospective meeting
There are several key factors, principles, and best practices to consider when running a retrospective. Below are some tips to help you facilitate a successful sprint retrospective meeting.
Subscribe to our product management newsletter
Get articles like this to your inbox
Principles for running a sprint retrospective session
You can consider the principles as house rules for the session to ensure that things run smoothly. Here are three key things to keep in mind and share with your team during a sprint retrospective:
- The session is a safe space — A sprint retrospective is an opportunity to learn and improve, and that means no blame games or finger-pointing when discussing things that didn’t go well
- Everyone has a chance to speak — Naturally, some members of the team will be less inclined to speak up. As a facilitator, you can gently prompt those folks and make space for them to provide input
- Listen to others and wait your turn — Only one person should be speaking at any given time; no talking over one another
Sprint retrospective best practices
Now let’s outline some best practices to help you run engaging and effective sprint retrospective meetings that lead to successful sprints and, ultimately, outstanding products.
- Consider the best tool for the session. If you’re working remotely, you might use Miro, Mural, or a similar tool that your team is familiar with
- Set the scene by asking participants to think about what they worked on and capture those tasks on sticky notes before starting the main activities
- Make sure you have each activity time-boxed and use a timer to keep everyone on track
- Ensure the team writes one item per sticky note (if you’re running the sprint retrospective in person, try to write these notes in capital letters for ease of reading later)
- Group similar items together and label the themes as you go
- Take a photo of the sprint retrospective board for later reference (if the meeting is held in person)
- Make sure actions are captured clearly, assigned to a member of the team, and in a format that can be easily distributed
- Take a moment to celebrate what went well
Basic sprint retrospective agenda template
If you’re new to running sprint retrospectives, a basic agenda is a great place to start!
What you need to get started:
- If you’re working in person — sticky notes, a whiteboard, sharpies or marker pens
- If you’re working remotely — a digital whiteboard such as Miro, Google Jamboard, or Mural
A basic sprint retrospective lasts about one hour. Here’s how you might break down the agenda:
- Start by reminding the team of the core principles outlined above (5 minutes)
- Ask the team to write down the themes, topics, or features they worked on during the sprint on sticky notes and place these on the whiteboard (5 minutes)
- What was good? Ask the team to write down, one item per sticky note, the things that went well during the sprint and then group similar sticky notes together (5 minutes)
- Discuss the key themes between the notes (5 minutes)
- What was bad? Ask the team to write down, one item per sticky note, the things that didn’t go well during the sprint and then group similar sticky notes together (5 minutes)
- Discuss the key themes (5 minutes)
- For each of the key themes, ask the team to come up with ideas and actions that might help solve the issues (10 minutes)
- Discuss the ideas and assign actions to team members (15 minutes)
- Wrap up (5 minutes)
Following the session, make sure everyone has a copy of the actions and assignees (and a photo of the whiteboard if you ran the retrospective in person).
Alternative sprint retrospective templates
Once you have mastered the basic sprint retrospective agenda, you can think about mixing it up with some other fun templates such as the following from Atlassian:
Glad, Sad, Mad
The aim of the Glad, Sad, Mad template is to spot ways to improve team health and morale post-sprint. It focusses on looking for opportunities to improve job satisfaction by highlighting how people are feeling and the emotions they experienced during the sprint.
Start, Stop, Continue
The Start, Stop, Continue sprint retrospective template is all about decision-making. It’s designed to help the team figure out what they should start doing, stop doing, or continue doing in terms of their ways of working and processes.
The Sailboat retrospective template is great for teams who like to visualize their sprint reflections. It looks at what helped to push the team forward during the sprint as well as what held it back from achieving its goals.
Four Ls (liked, learned, lacked, longed for)
The Four Ls retrospective template, like Sad, Mad, Glad, focusses on the team’s emotional journey during the sprint and takes both positive (“liked” and “lacked”) and negative feelings (“learned” and “longer” for) into consideration.
Holding a sprint retrospective can be a valuable exercise to stop and reflect on how your team is feeling and consider key learnings and actions that you might collectively take to improve ways of working, processes, and use of tooling during your next sprint.
Remember, a sprint retrospective should be safe spaces where everyone has a chance to listen. This diverse range of input will help you on your way to running a successful sprint retrospective session.
We reviewed a number of sprint retrospective templates to try. I would recommend starting with the most basic framework before experimenting with the others as you get more comfortable running retrospectives and discover what works best for you team. Good luck!
LogRocket generates product insights that lead to meaningful action
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.