How to Run a Sprint Retrospective (Templates + Examples)
A sprint retrospective is the most underutilized ceremony in agile product development. Most teams run them on autopilot — same format every time, same people saying the same things, and the action items forgotten by the next sprint. Then they wonder why the same problems keep coming up.
Done well, a retrospective is the most powerful tool a product team has for getting better. It’s dedicated time, protected from the sprint’s execution pressure, to reflect on how the team works and to make a concrete change. Below is how to run a sprint retrospective that actually produces that change, with formats, templates, and facilitation tips that go beyond the basics.
What Is a Sprint Retrospective?
A sprint retrospective is a regular ceremony in agile product development, held at the end of each sprint, in which the team reflects on how they worked together and identifies one or two concrete improvements. The official Scrum Guide defines it as the last event of the sprint, existing specifically to inspect and adapt the team’s process.
It is different from a sprint review (which is about what was built) and different from a post-mortem (which is typically reserved for incidents or failures). The retrospective is about the team’s process and collaboration: how work flows, where friction lives, and what the team can do to remove it.
In Scrum, the sprint retrospective is formally defined as the last event of the sprint. For most two-week sprints, it runs 60–90 minutes. For one-week sprints, 45–60 minutes is usually sufficient.
Why Retrospectives Fail (And How to Fix It)
Most retrospectives fail for one of three reasons:
1. Same format every time. The classic “What went well / What didn’t / What to improve” format is useful, but running it identically every sprint produces diminishing returns. Teams start to disengage.
2. No follow-through on action items. The team generates a list of improvements but never checks whether they were implemented. Without accountability, the retrospective becomes theater.
3. Psychological safety problems. If team members don’t feel safe raising real problems, they’ll say what’s comfortable rather than what’s true. Retrospectives in low-trust environments surface-level observations and miss the real issues.
These three failure modes are usually the same underlying problem wearing different masks: nobody outside the room has any stake in whether the retro produces anything. Teams that start sharing their action items publicly, in the same channel where engineering leadership posts sprint goals, tend to see a shift almost immediately — people start raising things they’d clearly been sitting on for a while, once there’s visible accountability attached to the outcome.
The fix for all three is intentionality: vary the format, own the action items publicly enough that skipping them is visible, and explicitly build psychological safety into how you run the meeting rather than assuming it exists because everyone’s polite.
How to Run a Sprint Retrospective, Step by Step
A well-run retrospective follows this structure, regardless of which specific format you use:
1. Set the Stage (5 minutes)
Open with a quick warm-up activity that helps people shift out of execution mode and into reflection mode. A simple check-in question works well: “On a scale of 1–5, how do you feel about the sprint that just finished?” or “In one word, describe the sprint.”
This also resets the social contract. Remind the team that this is a space for honest reflection, not blame, not defensiveness.
2. Gather Data (15–20 minutes)
This is the core of the retrospective. Depending on your format, you’re asking the team to surface observations about the sprint: what happened, what felt good, what felt hard, what surprised them.
The key facilitation principle here is to separate data gathering from discussion. Let people put their observations up (on sticky notes, on a digital board, in a shared doc) before the team reacts to any of them. This prevents loud voices from dominating and ensures quieter team members contribute.
3. Generate Insights (15–20 minutes)
Now the team discusses what they’ve gathered. Look for patterns: multiple cards on similar themes, recurring complaints, moments of success worth repeating. Cluster related items.
The goal is not to discuss every single item, but to identify 2–3 themes that are most worth the team’s attention. Take a concrete case: a nine-person mobile team surfacing “the release was stressful” almost every sprint. It can take several retrospectives of just nodding along before someone pushes on why, specifically, only to find that QA was getting the build 90 minutes before the release window — a scheduling problem masquerading as a vague stress complaint.
4. Decide on Actions (10–15 minutes)
The retrospective produces 1–3 specific, actionable commitments. Not vague aspirations (“communicate better”) but concrete steps with owners and a timeline (“by next sprint, the PM will send a written sprint summary before sprint planning so engineers have context before the meeting”).
The most common retrospective failure point is here: teams generate too many action items and follow through on none. Limit yourself to 1–3 per retrospective, and check at the start of the next sprint whether they were done.
5. Close (5 minutes)
End with a quick retro on the retro: “What was useful about today’s session? What would you change?” This closes the loop and builds the team’s capacity to improve the improvement process itself.
5 Retrospective Formats That Actually Work
Format 1: Start / Stop / Continue
The simplest and most versatile format. Ask the team:
- Start: What should we start doing that we’re not doing now?
- Stop: What should we stop doing because it’s not working?
- Continue: What’s working well that we should keep doing?
This format works for any team, at any stage. It’s direct and produces actionable output. The risk is it becomes rote; use it as your default, but rotate in other formats regularly.
Format 2: 4Ls — Liked / Learned / Lacked / Longed For
A richer variant that produces more nuance:
- Liked: What did you appreciate about this sprint?
- Learned: What did you learn?
- Lacked: What was missing or insufficient?
- Longed For: What do you wish you’d had?
The “Longed For” category often surfaces aspirational improvements that the team hasn’t had the courage to raise directly, making this format particularly good for teams going through a period of change or stress.
Format 3: Mad / Sad / Glad
An emotionally direct format that’s particularly effective for teams dealing with interpersonal tension or morale issues:
- Mad: What frustrated or angered you this sprint?
- Sad: What disappointed you or made you feel let down?
- Glad: What made you happy or proud?
This format surfaces emotional content that Start/Stop/Continue can miss. Use it when the team’s energy feels off, or when you sense unspoken tension in the group.
Format 4: The Sailboat (or Speedboat)
A visual metaphor-based format. Draw a sailboat (or speedboat):
- Wind (in the sails): What’s driving us forward?
- Anchors: What’s slowing us down or holding us back?
- Optional: Rocks ahead: What risks do we see coming?
- Optional: Sun: What are we excited about?
This format works especially well for teams that respond well to visual thinking, or for retrospectives that need to surface deeper systemic issues rather than sprint-level observations.
Format 5: The Lean Coffee
A self-organizing format where the team sets the agenda:
- Everyone writes down topics they want to discuss (2 minutes)
- The team votes on topics
- Topics are discussed in priority order, with a timer for each item
This format is valuable when the team has strong opinions about what needs to be discussed. It respects everyone’s input and prevents a single facilitator from controlling the agenda.
Here’s how the five compare at a glance:
| Format | Time Needed | Best For |
|---|---|---|
| Start / Stop / Continue | 45–60 min | Default choice; teams new to retros |
| 4Ls | 60 min | Teams that need positive framing to open up |
| Mad / Sad / Glad | 45 min | Morale issues or interpersonal tension |
| Sailboat | 60–75 min | Teams stuck on recurring, systemic obstacles |
| Lean Coffee | 60–90 min | Teams with strong opinions on what to discuss |
Retrospective Templates
Basic Start / Stop / Continue Template
SPRINT RETROSPECTIVE — Sprint [#] — [Date]
START
- [Item 1]
- [Item 2]
STOP
- [Item 1]
- [Item 2]
CONTINUE
- [Item 1]
- [Item 2]
ACTION ITEMS
| Action | Owner | By When |
|--------|-------|---------|
| [Action 1] | [Name] | [Date] |
| [Action 2] | [Name] | [Date] |
LAST SPRINT ACTION ITEMS — STATUS CHECK
| Action | Owner | Status |
|--------|-------|--------|
| [Previous action] | [Name] | Done / Not done / Rolled over |Full Retrospective Template
SPRINT RETROSPECTIVE — Sprint [#] — [Date]
Facilitator: [Name]
Attendees: [List]
CHECK-IN
Sprint health (1–5): [Score]
One word for this sprint: [Words from team]
OBSERVATIONS
Format used: [Start/Stop/Continue | 4Ls | Mad/Sad/Glad | Other]
[Observations organized by theme]
KEY THEMES
1. [Theme]
2. [Theme]
3. [Theme]
ACTION ITEMS (max 3)
| Action | Owner | By When |
|--------|-------|---------|
| | | |
RETRO ON THE RETRO
What was useful: [Notes]
What to change next time: [Notes]The PM’s Role in a Retrospective
In most agile teams, the Scrum Master or an Engineering Manager facilitates the retrospective. But product managers have a specific role to play, even when they’re not facilitating.
As a participant: Be honest. If sprint planning was unclear, say so. If the PRD had gaps, own it. Retrospectives where the PM is defensive or deflects feedback onto engineering produce teams that stop raising real problems. This is a common early-career trap: a PM gets defensive when a retro surfaces that specs kept changing mid-sprint, and the defensiveness itself is often what buries the topic for a sprint or two before someone works up the nerve to raise it again.
As a facilitator (when asked): Focus on drawing out quiet voices, preventing the same 2–3 people from dominating, and driving the group toward actionable outcomes rather than venting sessions.
On action items: Many retrospective action items belong to the PM: tighter requirements, earlier sharing of context, better prioritization before planning. Own those items explicitly and follow through on them by the next sprint.
Connecting Retrospectives to Agile Product Management
The sprint retrospective is one of five Scrum ceremonies, and it’s the one most directly connected to team health and long-term velocity. It complements sprint planning, daily standup, sprint review, and backlog refinement, and Atlassian’s team playbook on retrospectives is a solid reference if you want more facilitation exercises beyond what’s here.
For a full overview of how retrospectives fit into the agile PM workflow, see our guide to agile product management. For the backlog prioritization decisions that inform what the team works on each sprint, see how to run a prioritization workshop.
The retrospective is also the right place to address issues that surface during product discovery: if the team’s discovery process is generating poor signal, that’s a process problem worth raising here.
Tools for Running Retrospectives
In-person: Physical sticky notes on a whiteboard remain popular for engagement; the tactile act of writing and placing cards tends to produce good participation without anyone needing to learn a new tool mid-meeting.
Remote/async: A range of digital tools are purpose-built for retrospectives: FunRetrospectives.com, Retrium, EasyRetro (FunRetro), and Miro. Most have built-in timer, voting, and clustering features that replicate the in-person experience reasonably well.
Whichever tool you use, the principle is the same: separate writing from discussion, limit action items, and always check back on the previous sprint’s commitments.
If Your Retros Still Aren’t Changing Anything
A sprint retrospective is only as good as what the team does with it. The format matters less than the follow-through: pick a format, facilitate honestly, generate 1–3 specific action items with owners, and check them at the start of the next sprint.
If you’re doing all of that and the same issues still keep resurfacing sprint after sprint, the format isn’t the problem anymore: the diagnosis underneath it probably is. That’s usually a sign the retro is surfacing symptoms (a stressful release, a missed deadline) without ever tracing them back to their root cause, which is a facilitation skill worth deliberately building into how the team runs the “Generate Insights” step above.
References
- Derby, Esther, and Diana Larsen. Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf, 2006.
- Atlassian. Sprint Retrospective — Team Playbook. atlassian.com/agile/scrum/retrospectives.
- Scrum.org. The Scrum Guide. scrumguides.org.
- FunRetrospectives.com. Retrospective Formats and Activities.
