How to Run a Sprint Retrospective: Agenda, Examples & Facilitation Tips

A sprint retrospective brings together Scrum teams to reflect on the previous sprint and discuss what to improve next. But when the meeting lacks the right format and facilitation strategy, a sprint retrospective can turn into a ritual that leads to nowhere. To help you run engaging and insightful retrospectives, we tapped expert Scrum Masters for their techniques and real-world experiences.

Expert contributors

These expert Scrum Masters and Agile coaches bring years of facilitation experience and share their proven techniques and formats to help your team get the most out of every retro.

What is a Sprint retrospective?

A sprint retrospective is a meeting held at the end of each sprint where the Scrum team reflects on how they worked together and agreed on specific changes to make. The goal is to walk away with at least one action item the team commits to trying next sprint.

A sprint is a one to four week working session used by software and product teams following the Scrum framework. The retrospective takes place at the end of the sprint, after the team reviewed what they accomplished.

Who attends a Sprint retrospective?

The sprint retrospective is a Scrum team meeting, which means it is kept internal. The following breaks down the key participants and the role they play.

• Scrum Master: Facilitates the session and is in charge of creating an environment where the team can speak honestly. 
• Development team: The core participants of the retrospective. These are the team members who completed the sprint work, so they have direct insight into what supported their progress and what created challenges during the iteration.
• Product owner: Encouraged to attend to help the team address conflicts around priorities or expectations, but participates as a team member rather than as a stakeholder representative.

Stakeholders, managers, and external parties are not invited. The retrospective only works when the people in the room feel safe enough to raise real issues, and outside presence can change that dynamic.

When to hold a Sprint retrospective

The retrospective is one of the five Scrum ceremonies and typically runs between 45 and 90 minutes, depending on the length of the sprint. It takes place after the sprint review and before sprint planning for the next cycle. For a two-week sprint, it runs up to 90 minutes. For a one-week sprint, 45 minutes is typically enough.

Why the Sprint retrospective is important

The sprint retrospective is the only Scrum ceremony focused entirely on how the team works together. It gives Scrum teams a dedicated space to reflect on what went well and what didn’t, preventing the same issues from carrying into the next sprint.

Here is what a sprint retrospective helps your team accomplish:

• Promotes psychological safety: Retrospectives give every team member an opportunity to share observations about the sprint, and when facilitated well, it creates a safe space for honest discussion about challenges and frustrations. This makes it easier for team members to work through conflict and communicate more openly.
• Builds team ownership over the work process: The sprint retrospective encourages the team to decide how to improve their own work process. Over time, this practice helps the team adopt better ways of collaborating and address issues that are often overlooked during the sprint. 
• Develops a habit of continuous learning: Teams that regularly reflect on how they work build a habit of learning from experience. They gain a better understanding of what affects performance and handle change more effectively. They are also likely to innovate better as they agree on actions to try in the next sprint.

How to run a Sprint retrospective 

A sprint retrospective follows a five-step meeting agenda that takes the team from collecting individual reflections to discussing findings and agreeing on action items before the sprint ends.

Step 1: Set the stage (5 minutes) 

The Scrum Master opens the meeting by reminding the team of the purpose of the retrospective and establishing a few ground rules. This is also a good moment for a brief check-in activity to gauge how people are feeling and ease the team into honest conversation.

Step 2: Gather data (10 to 15 minutes) 

The team reflects on the sprint individually before discussing it as a group. Sprint retrospective templates can help team members organize their reflections and think through their experience. Preparing these a few days before the meeting gives everyone enough time to come in ready to contribute.

These are the sprint retrospective questions team members typically reflect on before the discussion:

What went well • What did the team do particularly well this sprint? • What processes or practices helped us move faster? • What should we make sure to repeat in the next sprint? • Which collaboration moments stood out this sprint?	What did not go well • What slowed the team down this sprint? • What caused the most friction or frustration? • What took longer than expected and why? • Were there any miscommunications that affected the sprint? • What did we underestimate going into this sprint?
What can we improve • What is one thing we could do differently next sprint? • What process would benefit from a second look? • Are there any tools or workflows that are not working for us? • What would have made this sprint run more smoothly?	Action and commitment • What is one change we are committing to in the next sprint? • Who owns each action item and how will we follow up? • Are there any blockers we need to escalate before the next sprint?

Step 3: Generate insights (10 to 15 minutes) 

Once the team has submitted their reflections, the Scrum Master leads the group in organizing similar observations and identifying the issues that had the most impact on the sprint. Having team members read their own notes aloud and sharing a screen during this step helps everyone follow along and feel that their feedback is being considered.

Step 4: Decide on action items (10 minutes) 

The team votes on one or two specific changes to make in the next sprint. Each action item should have a specific owner and a way to track whether it was completed by the next retrospective.

Step 5: Close the retrospective (5 minutes) 

The Scrum Master closes the meeting by summarizing the action items and thanking the team for their participation. Acknowledging the lessons the team identified reinforces that the conversation was worthwhile. It is also best to end on a positive note so everyone leaves feeling energized and ready to take on the next sprint.

Sprint retrospective formats & templates

Start/Stop/Continue, the Sailboat, and the 4Ls are some of the most widely used sprint retrospective formats among Agile teams. The right format depends on the team dynamics and what needs to be addressed.

1. Start/Stop/Continue: The team identifies what they should start doing, stop doing, and continue doing based on the previous sprint.
2. Mad/Sad/Glad: Team members share what frustrated them, what disappointed them, and what they felt good about during the sprint.
3. The 4Ls (Liked, Learned, Lacked, Longed For): The team reflects on what they enjoyed, what they picked up, what was missing, and what they wished had been different.
4. Sailboat: The team uses a sailboat metaphor where the wind represents what is pushing them forward and the anchors represent what is slowing them down.
5. The 5 Whys: The team picks a problem from the sprint and asks “why” five times in succession to get to the root cause rather than addressing surface-level symptoms.
6. DAKI (Drop, Add, Keep, Improve): The team evaluates their current practices and decides what to eliminate, introduce, maintain, and improve going forward.

Sprint retrospective examples

Seeing how other teams run their Agile retrospectives can help you identify what might work for your own. Here are two real-world examples of how Agile teams have approached theirs.

Example 1: A remote software development team using Start/Stop/Continue

A remote software development team at a mid-sized SaaS company was struggling with miscommunication between developers and the Product Owner during sprints. Their Scrum Master introduced the Start/Stop/Continue format to organize their feedback.

Before the meeting, team members submitted their reflections asynchronously using an online template. During the session, the Scrum Master grouped the responses into themes on a shared screen. The team quickly identified that daily stand-ups were running too long and cutting into focused work time. They agreed to stop using stand-ups for problem-solving discussions and to start scheduling separate sessions for those conversations instead.

By the following sprint, stand-ups were consistently under 15 minutes and the team reported feeling less interrupted during their work blocks.

Example 2: A product team using the Sailboat format

A product team at a retail company had been running retrospectives for several months but felt the conversations were becoming repetitive. Their Scrum Master switched to the Sailboat format to shift the team’s perspective and bring more energy into the meeting.

The team mapped out the wind, which represented a recently improved deployment process that reduced release time significantly, and the anchors, which represented unclear acceptance criteria that kept causing rework late in the sprint. 

Rather than venting about the problem, the Sailboat framing pushed the team to discuss what was dragging them and what they could do to cut the anchor loose. They committed to involving the Product Owner earlier in writing acceptance criteria before sprint planning.

Two sprints later, the rate of rework had dropped noticeably and the team felt more aligned going into each sprint.

Common Sprint retrospective mistakes

“Retrospectives usually fail for a few predictable reasons: teams don’t feel safe being candid, the conversation turns into blame or venting, and, most often, nothing changes afterward,” Federspiel puts it plainly. Even teams that run retrospectives consistently can fall into habits that make the meeting less effective over time. Here are some of the reasons: 

1. Turning the retrospective into a blame session

Blame is one of the most common ways a retrospective breaks down, particularly when there are unresolved conflicts within the development team. “Blame [games are] quite common, especially when there are deeper interpersonal issues going on between developers,” observes Demeny.

When the meeting becomes about pointing fingers rather than solving problems, it shuts down honest conversation and makes it harder for the team to move forward.

2. Holding back instead of speaking up

Taylor explains that team members stay quiet not out of malice but for self-protection. “They have concerns that saying it could get them into trouble, make them look bad, get someone else in trouble, [or] make someone else look bad…” 

Even in teams that consider themselves high-trust, people routinely hold back information they feel they cannot safely share. The result is a retrospective where the most important issues never make it into the conversation.

3. Low participation going unaddressed

As Demeny points out, “It is okay if someone does not have much to share, but if it becomes a pattern, then it is a problem that must be dealt with. If a team member is not putting anything on the board sprint after sprint, there is almost always something they are not saying. 

4. Failing to give everyone a voice

A retrospective where the same people do most of the talking is a facilitation problem. As Fenton observes, “Many Scrum Masters don’t even notice when someone isn’t getting an opportunity to speak, or they over-correct by calling out a quiet person who doesn’t want to speak.” Good facilitation means creating space for everyone to contribute without putting anyone on the spot.

5. Walking away without any changes

The most common retrospective mistake is also the most damaging: nothing changes afterward. Federspiel identifies this as one of the primary reasons retrospectives lose their value. When the team leaves the meeting without committing to a specific action, the retrospective becomes a routine rather than a tool for improvement, and participation drops with every sprint that follows.

Tips for running effective Sprint retrospectives

To help your team make better use of every retrospective, here is what our expert Scrum Masters recommend.

1. Create psychological safety before anything else

No format or facilitation technique will work if team members do not feel safe speaking up. Fenton is direct about this: “Retrospectives only work under conditions of psychological safety. If there are any repercussions for honest participation, there’s no point even attempting to run one.”

Before focusing on format or questions, the Scrum Master needs to establish an environment where people feel comfortable sharing without fear or consequence.

2. Leave with one or two owned action items

Federspiel advises teams to “Keep the discussion specific and leave with one or two small, owned action items you’ll review at the start of the next retro.” Keeping action items narrow in scope and assigned to specific people makes it far more likely the team will act on them before the next sprint begins.

3. Handle anonymous input with genuine intent

Anonymous input can help surface what people are reluctant to say out loud, but it only works under the right conditions. As Taylor explains, “Anonymous input requires genuine personal safety and privacy, a genuine intent to learn, not blame. One whiff of blame and people shut down, even if the content submission is anonymous.” The way the Scrum Master responds to what is shared matters just as much as how it was collected.

4. Keep the session focused and cut distractions short

It is easy for a retrospective to get derailed by personal arguments or highly technical discussions that belong in a different meeting. 

Demeny advises that “It is important to keep the session relevant, which means cutting personal arguments and technical discussions very short. That does not mean ignoring issues — it means listening to both sides and asking for more input.” Knowing when to redirect the conversation and when to dig deeper is one of the most important skills a Scrum Master should have. 

FAQs