What is a sprint retrospective in agile?

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.

Table of contents

• Introduction to sprint retrospectives
• The meaning and purpose of a sprint retrospective
• What is discussed in a sprint retrospective?
• The key players in a sprint retrospective
• Sprint review vs. sprint retrospective: Understanding the difference
• How to run a sprint retrospective: A step-by-step guide
• Sprint retrospective template
• Alternative sprint retrospective approaches and templates
• Common challenges and solutions to running sprint retrospectives

Introduction to sprint retrospectives

“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.

The meaning and purpose of a sprint retrospective

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.

---

Over 200k developers and product managers use LogRocket to create better digital experiences

Learn more →

---

What is discussed in a sprint retrospective?

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:

1. What went well — Celebrate things that were successful during the the sprint (e.g., designers and developers collaborated well)
2. 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)
3. 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.

The key players in a sprint retrospective

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.

Sprint review vs. sprint retrospective: Understanding the difference

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:

How to run a sprint retrospective: A step-by-step guide

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.

1. Choose the right tool — Begin by selecting the most appropriate tool for the retrospective. If you’re operating remotely, digital collaborative platforms like Miro or Mural could be suitable. Choose a tool that your team is already familiar with to facilitate smooth collaboration
2. Set the stage — Before jumping into the main activities of the retrospective, ask team members to reflect on their tasks during the sprint. Encourage them to capture these tasks on sticky notes to help with visual representation
3. Time-box activities — To keep the retrospective efficient and focused, ensure that each activity is time-boxed. Using a timer helps maintain this structure and keeps everyone on track
4. Single item sticky notes — Whether you’re conducting the retrospective remotely or in person, ask the team to write one item per sticky note. If the retrospective is in person, using capital letters on these notes can improve readability later on
5. Group and label — As the team starts filling the board with sticky notes, group similar items together. This helps identify common themes and areas of focus in your retrospective
6. Document the board — If the retrospective is held in person, take a photo of the board for future reference. This allows the team to revisit the insights gathered during the retrospective. Trust me, it’s always good to keep photos
7. Define clear actions — One of the primary outcomes of a retrospective should be a list of action items. Ensure these actions are captured clearly, assigned to a team member, and presented in a format that can be easily shared and tracked
8. Celebrate successes — Lastly, but importantly, take a moment to celebrate the team’s accomplishments. Recognizing what went well is not just a morale booster, it also underlines positive practices that can be replicated in future sprints

Sprint retrospective 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:

1. Start by reminding the team of the core principles outlined above (5 minutes)
2. 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)
3. 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)
4. Discuss the key themes between the notes (5 minutes)
5. 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)
6. Discuss the key themes (5 minutes)
7. For each of the key themes, ask the team to come up with ideas and actions that might help solve the issues (10 minutes)
8. Discuss the ideas and assign actions to team members (15 minutes)
9. 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 approaches and templates

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:

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:

Sailboat

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:

Starfish retrospective

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:

Common challenges and solutions to running sprint retrospectives

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:

• Dominating personalities — Sometimes, one or two individuals might dominate the conversation. To mitigate this, the facilitator can ensure that every team member has equal time to speak and actively invite quieter individuals to share their thoughts. Using round-robin techniques or “talking tokens” can ensure equal opportunities for speaking
• Dwelling on negatives — Sprint retrospectives can become gripe sessions if not managed well, focusing only on problems without seeking solutions. To overcome this, use techniques that balance the discussion between positive and negative aspects. Encourage the team to celebrate successes alongside discussing areas for improvement
• Lack of follow-through — A common pitfall of sprint retrospectives is when the action items identified during the meeting are not implemented. Assign ownership and track these actions in a shared location, reviewing progress in the next retrospective
• Time constraints — Retrospectives can sometimes feel rushed or, on the contrary, may drag on without focus. Time-boxing each activity in the retrospective and using a timer can keep the meeting on track. It’s crucial for the facilitator to guide the team to respect these time limits and keep the meeting focused on its goals
• Meeting fatigue — We’ve all felt this before after being in back-to-back meetings. Schedule regular short breaks during the retrospective. Encourage the use of various communication tools (e.g., virtual whiteboards, text-based discussions, etc.) and consider asynchronous activities that allow team members to contribute at their own pace

Conclusion

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 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.

Share this:

• Twitter
• Reddit
• LinkedIn
• Facebook