Sprint retrospectives are not always an easy practice—especially for newer teams—but they’re critical to making continuous improvements and, ultimately, delivering better products to customers. 

In this guide, we cover the basics of sprint retrospectives, types of retrospectives, and tips for running retrospectives effectively. 

Let’s dive in!

A sprint retrospective, one of the five Scrum events, is a meeting where a Scrum team reflects on the previous sprint. It provides a moment for learning. 

The purpose of a sprint retrospective is to foster a culture of continuous improvement by identifying what worked well in a sprint and what could be changed. By engaging in open and honest dialogue, teams can uncover insights, address issues, and implement actionable improvements to their processes and collaboration. Retrospectives empower teams to adapt, grow, and deliver greater value with each iteration.

Keep in mind, while sprint retrospectives are used by Scrum teams, any team can benefit from making retrospectives a regular practice—especially teams that work on large, cross-functional projects. Many of the tips shared in this guide can be applied by any team conducting a retrospective. 

A sprint retrospective is held at the end of every sprint. 

More generally, retrospectives can be applied to other circumstances to support continuous improvement and team learning, such as:

• A multi-team retrospective scheduled once a month or quarter.
• A mini-retrospective held for a few minutes at the end of a sprint review.
• An ad-hoc retrospective organized to address a major issue, such as a process failure that led to a bug being released.

Both sprint reviews and retrospectives take place at the end of a sprint, but they serve different purposes. A sprint review is the public end of a sprint—stakeholders are looped into what occurred during the sprint and have the chance to give feedback on deliverables. 

A sprint retrospective is the private end of a sprint where just the Scrum team gets together to focus on internal relationships and processes and discuss how to improve the way they work together. 

According to the Scrum Alliance, a sprint retrospective is “timeboxed to three hours for a one-month sprint, with shorter sprints having a shorter retrospective timebox.”

For two-week sprints, 90-minute retrospectives are typical.

Since a sprint retrospective is typically a longer meeting, most Agile teams structure the meeting into the five phases suggested in the book “Agile Retrospectives” by Esther Derby, Diana Larsen, and David Horowitz.

The five phases are:

• Set the stage: Clarify the goal of the retrospective by looking back at the last sprint and identifying the positives, negatives, and areas for improvement. Set a tone of collaboration and open communication.
• Gather data: Reflect on what happened during the sprint cycle. Review metrics, processes, and value delivered, and surface conflicts that may have negatively affected outcomes.
• Generate insights: Look critically at why things happened the way they did and discuss the factors that helped the team succeed vs. what caused friction.
• Decide what to do: Decide what to do differently for future sprints. Zero in on one or two new approaches and create concrete action plans for trying them out.
• Close the retrospective: Clarify your plan of action, so everyone knows what needs to be done, when, and by whom. Invite suggestions for improving future retrospectives and end with appreciations. 

Sprint retrospectives should encourage equality and not have a hierarchy. They are for the Scrum team and can be facilitated by the Scrum master or someone outside of the team to ensure each participant has an equal voice. Previously, product owners were not included in retrospectives, but now they often are. It’s the team’s decision who gets invited to a team-level retrospective. For example, the team may choose to invite a stakeholder from another team to help improve cross-functional processes.

Sprint retrospectives are not a place for managers—this is to create a sense of safety for the Scrum team and encourage open and transparent communication.

If there’s a bottleneck between teams, more than one team may be invited to a retrospective. Additionally, if the retrospective is for a large project or program, and the topics to be covered aren’t sensitive, everyone involved in the project or program may be invited. 

Ultimately, the purpose of the retrospective dictates the topics that should be covered, but some common topics you may cover during a retrospective include:

• Achievement (or not) of the sprint goal
• Impediments and blockers
• Quality of the work
• Team morale and satisfaction
• State of team collaboration and communication
• Pace with which the team is delivering value

Some topics that are not appropriate to discuss include:

• Gossip or rumors about other teams or individuals
• Personal attacks or blame
• Issues the team can’t do anything about
• Evaluations of a single team member’s performance

Keep in mind, everything discussed during the retrospective should stay among retrospective attendees—nothing should be shared outside of the retrospective unless agreed upon. 

There are many different types of retrospectives so a team can get a full view from different perspectives to holistically and iteratively improve their ways of working.

Varying the type of retrospective can also help keep the meeting more engaging. 

DAKI retrospective

A DAKI retrospective prompts teams to discuss what practices to drop, add, keep, and improve. DAKI retrospectives help teams think deeply about processes and identify what’s serving them well and what isn’t.

DAKI retrospective template (click to use template)

Mad, sad, glad retrospective 

A mad, sad, glad retrospective is a type of retrospective that can help teams discover tensions in their work. It will help locate where team members' stress is creating rough patches in processes.

Mad, sad, glad retrospective template (click to use template)

Start, stop, continue retrospective

A start, stop, and continue retrospective has a straightforward format. Team members discuss what the team should start, stop, and continue in the next sprint or project.

Start, stop, continue retrospective template (click to use template)

4 Ls retrospective

The 4 Ls retrospective helps teams discover what they liked, learned, lacked, and longed for during a sprint or project. Unlike the resolute language of a start, stop, continue retrospective, the 4Ls allow for more nuance. Its format is less about immediate solutions and more about fact-finding, leading to broader changes or subtle tweaks for the next iteration.

4 L's retrospective template (click to use template)

Rose, thorn, bud retrospective

The rose, thorn, bud retrospective is simple yet powerful. The team highlights wins and successes (roses), challenges (thorns), and new ideas (buds).

Rose, thorn, bud retrospective template (click to use template)

Now that you have a good foundation for what a sprint retrospective is, here are tips for both facilitators and participants to make retrospectives more effective. These tips come from experienced Agile coaches Bryan Stallings and Jessica Guistolise and are especially helpful for teams that are still becoming more familiar with retrospectives.

For facilitators

It’s important for facilitators to remember: Retrospectives are dear to the heart of Scrum masters, but when they’re not done well, many developers don’t like them because they feel like they’re talking about problems instead of coding and taking action on problems. Let’s take a look at some things you can do as a facilitator to ensure team members are getting the most out of retrospectives.

Set the right tone

To set the right tone with the group from the get-go, facilitators can: 

• Share a visual of the circle of influence. The circle of influence shows what topics the team can affect vs. the topics the team can’t affect and therefore won’t spend time discussing. 
• Set norms collectively before entering into a retrospective.
• Set the agenda and working agreements at the beginning.     

You may be thinking: What if I set the tone from the beginning and the retrospective still gets off track? 

In that case, consider addressing the situation at hand. Whether there’s an elephant in the room, distrust in management, or something else going on, name the problem and allow it to sit rather than avoid it. You may use “I” phrases so that no one in the group feels called out. 

For example, a facilitator may use this framework: “I would feel [X] in [Y situation]. Is anyone else feeling that way in the room?”

It’s critical that facilitators hold neutrality throughout the meeting.

A good facilitator keeps a mental log of what point the team needs to reach in order to uplevel, and experienced facilitators take the time to peel back the layers of conflict on the team.  

Use an object to represent a problem

For in-person retrospectives, the facilitator can place an object representing the problem in the middle of a table and have team members sit shoulder to shoulder facing the problem. Then, as team members talk about the problem, they can point at the object, not at each other.

Reiterate the value of continuous improvement

Continuous improvement is the name of the game for Agile product development, and being reminded of that can help team members realize the importance of the sprint retrospective. 

Sharing stories like the British cycling team improving their performance by just 1% to achieve an Olympic gold medal can really motivate the team and help illustrate your point. 

Make room for emotional topics

Sometimes Scrum teams don’t spend time on emotional topics like appreciation or conflict during the retrospective because they feel uncomfortable. Facilitators can provide a structure for expressing both appreciation and conflict comfortably. 

For example, facilitators can have team members write down the conflict and then read it aloud for them. They might also encourage the group to give each other shout-outs since bragging about others’ accomplishments can often feel less awkward. Or, the facilitator can use a digital template for the meeting, like the sprint retrospective template below, and have participants add sticky notes with their thoughts. 

Sprint retrospective template (click to use template with your team)

Don’t make the retrospective too short 

While it may be tempting for the sake of time, don’t shorten a sprint retrospective to 30 or 45 minutes. Often the important and meaningful discussion doesn’t come up right away, so you want to be sure to have enough time to get to what is really going on under the surface. Plus, if the important topics are only talked about for five minutes at the end of the meeting, the team will leave feeling uncomfortable. 

Leave with action items 

A retrospective shouldn’t just cover what happened in a sprint; it should also cover what’s next for the team to try. If nothing ever changes, the team isn’t going to have high morale around retrospectives in the future.

Since sprint retrospectives are for the Scrum team, it’s not just up to the facilitator to make retrospectives effective—participants have an important role to play as well. 

Keep in mind the retrospective prime directive 

The retrospective prime directive, written by Norman Kerth in the book “Project Retrospectives: A Handbook for Team Reviews” states, “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

When attending a retrospective, keeping this prime directive in mind sets up an attitude of collective ownership rather than a blame game.

Give effective feedback

To give effective feedback, especially when the feedback is more critical, make an “I” statement instead of a “you” statement following this framework: “When [X] happened, [Y] was the result, and my response was [Z].” 

Effective feedback focuses on the situation, behavior, and impact.

Lucid makes it easy to run sprint retrospectives with hybrid, remote, and in-person teams—or any other Agile event! With ready-to-use templates, Facilitator Tools, and a canvas built for collaboration, you don’t have to be a retrospective expert to run an effective retrospective.