Sprint Retrospective Template (5 Formats + Examples)

A sprint retrospective template gives your team a fixed structure for the meeting that closes every sprint. Not the meeting after an outage, that's a post-mortem template. Not the live war-room meeting either, that's the incident response template. The retro is the recurring 60-minute reflection at the end of each sprint where the team looks at what happened, decides what to change, and writes down owners and dates.

Most retros fail in the same place. The team talks for an hour, generates good observations, and then the action items vanish into a Slack thread or a Confluence page nobody opens. Six sprints later the same complaint shows up again. The fix is structure plus a paper trail. Below is a sprint retrospective template you can copy into Markdown, Notion, or Confluence today, plus five named formats to rotate through so the meeting stays useful.

What a sprint retrospective is (and isn't)

A sprint retrospective is the recurring meeting that ends every sprint in Scrum. The Scrum Guide defines it as a 45-minute to 3-hour reflection where the team inspects how the last sprint went across people, processes, and tools, then commits to improvements for the next one. It's owned by the Scrum Master, attended by the whole development team plus the product owner, and timeboxed to the sprint length (15 minutes per week of sprint is a common rule of thumb).

It is not a status meeting. It is not a sprint review (where you demo work to stakeholders). It is not a post-mortem (which fires after a specific incident). The retro is internal, recurring, and forward-looking. The output is always a small list of action items with owners and dates, not a transcript.

The 5-phase sprint retrospective format

Esther Derby and Diana Larsen's book Agile Retrospectives codified the five-phase structure that almost every modern retro follows. Atlassian, Scrum.org, and most retro tools all map to it.

1. Set the stage (5 min): frame the meeting, restate the prime directive, get a quick mood check
2. Gather data (15 min): surface what happened in the sprint using a chosen format (4Ls, Sailboat, etc.)
3. Generate insights (15 min): group themes, find root causes, vote on what matters most
4. Decide what to do (15 min): pick 1 to 3 action items with named owners and target dates
5. Close (5 min): recap the action items, do a brief plus/delta on the retro itself, end on time

Stick to 60 minutes for two-week sprints. The hour cap forces the team to be selective. A retro that runs long usually means the gather-data phase swallowed the meeting and the team never got to action items.

The sprint retrospective template (copy this)

Drop this directly into your team workspace. It's structured so the whole document is one shared artifact: agenda at the top, raw notes in the middle, action items at the bottom where they're searchable later.

# Sprint [N] Retrospective: [Team Name]

**Date:** YYYY-MM-DD
**Sprint dates:** YYYY-MM-DD to YYYY-MM-DD
**Facilitator:** [Scrum Master]
**Attendees:** [list]
**Format used:** [Start/Stop/Continue | 4Ls | Sailboat | Mad/Sad/Glad | KALM]

## Prime directive

> 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.
> Norm Kerth, Project Retrospectives

## 1. Set the stage (5 min)

- Mood check (1 to 5):
- One word for the sprint:

## 2. Gather data (15 min)

[Format-specific columns go here. See examples below.]

### Start
-

### Stop
-

### Continue
-

## 3. Generate insights (15 min)

**Themes that emerged:**
-

**Root causes (5 whys on the top theme):**
-

**Top 3 by dot vote:**
1.
2.
3.

## 4. Action items (15 min)

| # | Action | Owner | Due | Status |
|---|--------|-------|-----|--------|
| 1 |        |       |     | Open   |
| 2 |        |       |     | Open   |
| 3 |        |       |     | Open   |

## 5. Close (5 min)

**Plus / Delta on the retro itself:**
- Plus:
- Delta:

## Carryover from last retro

| Action | Owner | Status | Notes |
|--------|-------|--------|-------|
|        |       |        |       |

The carryover table at the bottom is the unglamorous part that makes the whole thing work. Every retro starts by checking last sprint's action items. If the same item carries over three sprints in a row, the team is choosing not to fix it, and that itself is a discussion.

5 sprint retrospective formats and when to use each

The five-phase structure stays constant. What changes is how you run the gather-data phase. Rotate formats so the team doesn't autopilot. Here are the five most common ones, when each fits, and the prompts to use.

Start, Stop, Continue

The simplest format and the right default for new teams. Three columns. Each person writes silently for 3 to 5 minutes, then everyone shares. Use this when you want speed and clarity, or when the team is new to retros and needs guardrails. Watch the failure mode: every sprint the same items show up under "Continue" with no "Start" or "Stop" entries, which usually means the team is being polite rather than honest.

Mad, Sad, Glad

This format surfaces emotional signal that the others mute. Use it after a hard sprint, after an incident, or when standups have felt off. The Mad column is where the real material usually shows up. Pair this format with anonymous submissions (a shared doc with no names, or a tool like Parabol or Retrium) when the team is small enough that attribution is obvious.

4Ls (Liked, Learned, Lacked, Longed for)

Liked, Learned, Lacked, Longed for. This is the most balanced gather-data format because it pulls in both wins and gaps without forcing emotional language. The Longed-for column tends to surface aspirations the team rarely says out loud, the unrequested mentor, the missing test environment, the tooling that would unblock four people. Use 4Ls every third or fourth retro to keep things fresh.

Sailboat (or Speedboat)

A visual format. Draw a sailboat on a whiteboard. Wind in the sails (what's pushing us forward), anchor (what's slowing us down), rocks (risks ahead), island (the goal we're sailing to). Use Sailboat when the team feels stuck on the same blockers retro after retro and you need to surface bigger structural issues, not weekly friction. The metaphor pulls people out of the last two weeks and into the bigger picture.

KALM (Keep, Add, Less, More)

Keep, Add, do Less, do More. KALM works best for mature teams with a working system that needs tuning, not overhaul. The Less column is the secret weapon. Most retros generate ideas about what to add or start. KALM forces the team to also name something they're going to consciously do less of, which is the only way to keep retros from creating an ever-growing pile of new processes.

Running the meeting: a facilitator script

The facilitator (usually the Scrum Master) runs the clock and the format. Here's a 60-minute script for a two-week sprint retro using the 4Ls format. Copy it, change the format, and you have a fill-in script for any retro.

0:00 to 0:05, Set the stage

"Welcome back. We're using 4Ls today: Liked, Learned, Lacked, Longed for. Reminder of the prime directive: everyone did the best job they could with what they had. Quick mood check, drop a 1 to 5 in chat. One word for the sprint?"

0:05 to 0:20, Gather data

"Five minutes of silent writing. One sticky per item, one item per sticky. Don't comment on others' notes yet. Go."

"Two minutes of silent reading. Pull related stickies near each other if you spot a duplicate."

"Walk through Liked first. Author reads, two sentences max, no debate yet. Same for Learned, Lacked, Longed for."

0:20 to 0:35, Generate insights

"Themes I'm seeing: [name 2 to 3]. Three dots each, vote on the items you most want to discuss. We'll take the top three."

"On the top item: 5 whys. Why did this happen? Why did that happen? Keep going."

0:35 to 0:50, Decide what to do

"We pick 3 actions max. For each one: what's the change, who owns it, when's it done by? Add it to the table now."

0:50 to 1:00, Close

"Recap actions: [read them out]. Plus and delta on the retro itself: one thing that worked, one thing we'd change. Thanks everyone, see you Monday."

The two parts that get skipped most often are the silent-writing portion (which a strong facilitator protects from people who jump in early) and the explicit owner-and-date assignment (which everyone agrees to and then nobody does). If your retros generate themes but no commitments, that's the part to tighten.

Remote vs in-person retros

In-person retros run on sticky notes and a whiteboard. Remote retros run on a shared digital board (Miro, Mural, FigJam) or a purpose-built tool (Parabol, Retrium, EasyRetro, TeamRetro). The format and phases stay identical. The differences are mechanical.

For remote retros, three things matter more than they do in person. First, silent writing has to be enforced explicitly because it's easy for someone to start narrating before others finish. Second, anonymous submission is a real option, where a shared board lets people add cards without their name attached, which surfaces signal that face-to-face groups suppress. Third, breakout rooms become useful for groups larger than six. Split into pairs to write, regroup to share.

For in-person retros, watch the dominant-voice problem. The two loudest people drive the conversation while three quieter people contribute one sticky each and then leave underrepresented. Dot voting and round-robin reading are the cheap fixes that work in both modes.

Common pitfalls (and how to avoid them)

Action items disappear. The biggest failure mode. Written down, never tracked. Fix: every retro starts by reviewing last sprint's action items. If three retros in a row carry the same item over, escalate or kill it. According to the 16th State of Agile Report, only about 27% of teams say their retros consistently lead to follow-through on improvements, which is roughly the inverse of what teams report wanting.

Same format every sprint. After four retros, Start/Stop/Continue stops generating new material. The team writes the same things on autopilot. Rotate formats every two or three sprints.

Blame instead of system. The prime directive exists because retros sliding into "who fired the bad deploy" produce defensive contributions, not learning. Facilitators should redirect blame language to systems language: not "Sam pushed broken code," but "our pre-merge checks didn't catch this class of bug."

Skipping the retro. The fastest way to lose retro value is to cancel one because the team is busy. Busy sprints generate the most retro material. The 60-minute retro is the cheapest way to find the 4 hours your team is wasting per sprint.

No archive. Retros that live in private notes in someone's Notion produce no organizational learning. Publishing retros to a searchable internal docs site lets you spot themes across quarters: which complaints recur, which experiments succeeded, which decisions you made and why. Tools like Docsio let you generate an internal docs hub from existing materials in minutes, so retro outcomes, architecture decision records, and design docs live in the same searchable place rather than scattered across Slack and Confluence pages nobody can find. Retro themes are signal. They're worth keeping.

Connecting the retro to the rest of the sprint

The retro doesn't stand alone. It closes a loop that started with the user story template at sprint planning, ran through standups, and ended with the sprint review. Action items from the retro should feed back into the next sprint as either backlog items (if they need engineering work), SOP updates (if they're process changes), or runbook updates (if they're operational fixes). When retro outputs flow back into the team's working documents instead of dying in a meeting note, the retro stops being a ritual and starts being the engine that compounds team improvement.

Teams that treat retros as the source of truth for "how we work now" usually publish them to an internal documentation site so anyone can search past retros, find the action item that introduced a process, and see why it exists. That archive is what separates teams that learn from teams that just meet.

Sprint retrospective template FAQ

What are the 5 phases of a sprint retrospective?

Set the stage, gather data, generate insights, decide what to do, and close. The five-phase structure comes from Esther Derby and Diana Larsen's book Agile Retrospectives. Most retro tools and templates map directly to it. Each phase has a clear purpose, and skipping any of them (especially decide-what-to-do) is the single biggest reason retros fail to produce change.

How long should a sprint retrospective be?

A common rule of thumb is 15 minutes per week of sprint length. Two-week sprints get a 60-minute retro, four-week sprints get up to 2 hours. The Scrum Guide caps it at 3 hours for monthly sprints. Going shorter than 45 minutes usually means cutting either the insights phase or the action-items phase, which guts the value of the meeting.

What's the difference between a retrospective and a post-mortem?

A retrospective is recurring, scheduled at the end of every sprint, and forward-looking across the whole sprint. A post-mortem is one-off, triggered by a specific incident or outage, and focused on the root cause of that one event. Retros use formats like 4Ls and Start/Stop/Continue. Post-mortems use timelines and contributing-factor analysis.

Who should attend a sprint retrospective?

The development team, the product owner, and the Scrum Master. Stakeholders from outside the team usually don't attend because their presence chills honest discussion of internal team issues. If senior leaders want visibility, share the action items afterward, not a seat at the meeting.

What's the best sprint retrospective format for remote teams?

Any of the five formats works remotely as long as you use a shared digital board for the gather-data phase. 4Ls and Mad/Sad/Glad work especially well remote because the columns translate cleanly to digital sticky notes. The format matters less than enforcing silent writing time and using anonymous submission for tense topics.

Wrapping up

Pick one format from the five above, drop the template into your team workspace, and run it at the end of your next sprint. The first retro using the template will feel slightly stiff. By the third one, the carryover table will be telling you something honest about whether the team is actually following through on what it decides. That feedback loop is the whole point of the retro, and it's worth more than any specific format you pick.

When you want a counterpart for the post-incident version, the post-mortem template covers what to do after a specific outage. Together they make up the two reflection meetings every engineering team should have on the calendar.