Editor’s note: This article was updated 22 June 2023 to update the content and add new information, including a section for common challenges to sprint retrospectives and their solutions.
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.
“Retrospective” means looking back on or dealing with past events or situations. A sprint retrospective is the same idea — it’s a scrum meeting (aka an event or 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.
A sprint retrospective is typically held as soon as a sprint has ended and before the next sprint begins. This helps ensure that recent experiences are fresh in the team members’ minds, enabling them to accurately reflect on their work.
The entire sprint retrospective is time-boxed to a max of three hours, but it can be less depending on the length of the sprint. 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 that three hour limit.
The retrospective can be held in various settings, depending on how the team works best. It can be conducted in person or held remotely. Since scrum is a framework that you can adapt based on the needs of your organization, it’s really up to you to decide how to conduct the sprint retrospective.
Nonetheless, 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.
So 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.
Though they can go up to three hours, 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:
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.
The sprint retrospective is primarily participated in by the scrum team. The central players of this meeting are usually the scrum master, who often facilitates the session, along with the product owner and the development team members. The purpose of having all of these members in the sprint retrospective is to perform a well-rounded analysis of the sprint.
The facilitation of a retrospective, while usually led by a scrum master, can also be handled by other members depending on the team’s structure. A delivery manager or a team leader, for example, could take this on instead. The facilitator’s role is to guide the meeting smoothly and ensure the conversation doesn’t get too sidetracked and that it stays constructive rather than critical.
Despite the scrum team being the primary attendees, it’s not uncommon for other cross-functional team members to participate in the sprint retrospective. This might include roles like product designers, developers, QAs, product managers, and UX designers. Their participation allows for a broader perspective on the work and a holistic review of the sprint.
In certain cases, other stakeholders may also be invited to attend the retrospective. This usually happens when these individuals form an integral part of the cross-functional team or when their input can aid in resolving actions or blockers.
It’s important to note that while the sprint retrospective’s core participants are the scrum team, the flexibility to include other roles and stakeholders emphasizes the retrospective’s mission — to reflect, learn, and improve as a cohesive unit.
Although they both occur at the end of a sprint cycle, a sprint review is quite different from a sprint retrospective.
The primary objective of a sprint review is to improve the product, whereas the goal of a sprint retrospective is to improve the process. Skipping either of these events would drastically hinder improvement, learning, and growth opportunities.
More specifically, 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 |
To run a successful sprint retrospective, it’s crucial to understand some main principles first. You can consider these principles as house rules for the session to ensure that things run smoothly.
First and foremost, remember that 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. Next, ensure everyone has a chance to speak. Naturally, some members of the team will be less inclined to speak up. And finally, listen to others and wait your turn. Only one person should be speaking at any given time; no talking over one another.
Now that those basic principles are out of the way, 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.
If you’re new to running sprint retrospectives, a basic agenda is a great place to start!
What you need to get started:
A basic sprint retrospective lasts about one hour. Here’s how you might break down the agenda:
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):
Once you have mastered the basic sprint retrospective agenda, you can think about mixing it up with some other fun approaches such as the following ideas inspired by Atlassian:
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:
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:
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:
The starfish retrospective is named after its five sections, mirroring the shape of a starfish: keep doing, less of, more of, stop doing, and start doing.
The template prompts team members to reflect on their practices in the last sprint and categorize them into these five areas. “Keep doing” refers to practices that are working well and should be continued. “Less of” and “More of” are for practices that need to be scaled down or amplified, respectively. “Stop doing” calls out practices that aren’t beneficial and need to be discontinued, while “Start doing” suggests new practices that could enhance team performance:
Running successful sprint retrospectives doesn’t happen overnight. Sometimes it takes a few iterations for trial and error, and it’s not uncommon for teams often encounter a few common obstacles. Let’s look at some common challenges in retrospective meetings along with best practices to mitigate them:
Holding a sprint retrospective can be a valuable exercise to stop and reflect on how your team is feeling. It will help you consider key learnings and actions that you might collectively take to improve ways of working, processes, tools 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!
Featured image source: IconScout
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, Product, UX, 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.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.