Retrospective Meetings: Meaning, the 5 Phases, Methods, and Templates (2026)

Few meetings have a better reputation and a patchier reality than the retrospective. In theory, it is where a team improves the way it works. In practice, it often becomes the obligatory slot at the end of the sprint where the same topics circle around and nothing actually changes.

This guide covers what a retrospective is and where the term comes from, how it differs from a review, lessons learned, and a post-mortem, how the five-phase agenda works, which methods fit which situation (with a comparison table), a template you can copy today, and how to solve the documentation problem that quietly kills most retro practices.

⚠️ This article was independently compiled based on publicly available information and user feedback as of September 2026.

Table of Contents

1. What Is a Retrospective? Meaning and Definition
2. Retrospective vs Review, Lessons Learned, and Post-Mortem
3. The Agenda: The 5 Phases of a Retrospective
4. Retrospective Methods Compared: 8 Formats at a Glance
5. Three Methods in Detail: Sailboat, 4Ls, and Starfish
6. A Retrospective Template You Can Copy
7. Common Retrospective Mistakes and Their Fixes
8. Remote Retrospectives and the Documentation Problem
9. FAQ
10. Conclusion

What Is a Retrospective? Meaning and Definition

The word retrospective comes from the Latin retrospectare, "to look back." In everyday language it simply means a look backward, such as an exhibition covering an artist's whole career. At work, and that is what this guide is about, the term means something more precise:

A retrospective is a recurring team meeting in which the team looks back at a completed period of work and turns what it finds into concrete improvements for the next one. The subject is not the product but the collaboration itself: processes, communication, tools, and team health.

The format became widespread through agile software development. In Scrum, the Sprint Retrospective is one of the framework's fixed events at the end of each sprint; the Scrum Guide caps it at three hours for a one-month sprint, proportionally less for shorter ones. The idea is older and broader, though. Norman Kerth described retrospectives for project teams of every kind in his 2001 book "Project Retrospectives," and his famous ground rule, the Prime Directive, still belongs at the start of every retro: everyone did the best job they could, given what they knew at the time. A retrospective looks for causes in the system, not culprits in the room.

Three traits separate a real retrospective from a general feedback session:

• It recurs. A one-off airing of grievances is not a retro. The value comes from the series: decide, try, and check the result at the next retro.
• It examines a defined period. The last sprint, the last month, a project phase, not "everything that has ever bothered us."
• It ends with decisions. The work product is a short list of concrete, checkable changes with owners, not a page of mood notes.

Retrospective vs Review, Lessons Learned, and Post-Mortem

Four terms that get mixed up constantly. The distinction is worth making because each format answers a different question:

These formats complement rather than replace each other. A team can hold a review and a retrospective every sprint, run a lessons learned workshop at project close, and conduct a post-mortem after a serious incident. The most common mix-up is between review and retro: the review asks what was built, the retro asks how the team worked.

The Agenda: The 5 Phases of a Retrospective

The most widely used agenda comes from Esther Derby and Diana Larsen's book "Agile Retrospectives" (2006). The five phases give the meeting a dramaturgy that leads from observation to decision. For a team of up to eight people looking back at two weeks, 60 to 90 minutes is enough.

Phase 1: Set the stage (about 5 min). The facilitator names the period and focus, restates the Prime Directive, and gets every person to say something once, for example with a one-word check-in: "Describe the sprint in one word." People who speak in the first minutes are far more likely to contribute later.

Phase 2: Gather data (about 15 min). The team collects facts and observations, silently and in writing, before anyone discusses them: What happened? What went well, what slowed us down? Silent writing is the single most important move in the whole retro. Start with open discussion instead, and the loudest voice anchors everyone's interpretation of the period.

Phase 3: Generate insights (about 15 to 20 min). The collected notes are grouped and the most important ones examined: Why did this happen? What was the effect? This is where symptoms get separated from causes. "The release was stressful" is a symptom; "the spec changed twice after implementation started" is a cause you can address.

Phase 4: Decide what to do (about 15 min). The team picks the two or three highest-impact topics and agrees on one concrete change for each, with an owner and a check date. Resolutions like "communicate better" are banned: a good action is a behavior that, at the next retro, has either happened or not.

Phase 5: Close (about 5 min). The actions are repeated out loud, the date of the next retro is confirmed, and a quick meta-check ("What should we improve about this retro format itself?") closes the loop.

The phases can feel formal, but they are why experienced facilitators rarely skip them: without phases 2 and 3, the team jumps from feelings straight to actions, and those actions end up treating symptoms.

Retrospective Methods Compared: 8 Formats at a Glance

Methods like Sailboat or 4Ls are structures for phases 2 and 3: they define the categories the team collects and discusses in. Choosing the right method matters less than applying it consistently, but switching at the right moment keeps the retro alive.

A practice that holds up well: fix one standard format for the regular retro (many teams pick KPT or Start/Stop/Continue) and deviate only deliberately, say a timeline retro at quarter end or Mad/Sad/Glad after a draining stretch. Teams that switch formats every week spend their energy relearning rules instead of improving.

Three Methods in Detail: Sailboat, 4Ls, and Starfish

The Sailboat retrospective works with an image: the team is a boat sailing toward an island (the goal). Wind pushes it forward (what speeds us up), the anchor drags (what holds us back), rocks are risks on the course, and the island is the shared goal. The metaphor lowers the barrier to entry noticeably: people who find "naming process problems" confrontational will happily stick a note on an anchor. That makes it a strong choice for new teams, mixed groups that include stakeholders, or a team's very first retro. Just make sure phase 4 leaves the metaphor behind: an anchor only counts as handled once it has become a concrete action with an owner.

The 4Ls retrospective asks four questions: what did I like, what did I learn, what was lacking, what did I long for. Its strength is the Learned column: it forces the team to say out loud what would otherwise stay implicit, which makes it especially useful after periods with a lot of novelty, such as onboarding, a technology switch, or the first sprint of a new project. Lacked and Longed for, in turn, produce raw material for actions that pure good-versus-bad formats often miss.

The Starfish retrospective refines Start/Stop/Continue with two intermediate steps: more of and less of. That gradation is exactly what makes it valuable for established teams. After two years of working together, there is rarely much to start or stop outright, but there are plenty of practices whose dosage is off: more pair reviews, fewer status meetings. For brand-new teams the Starfish is usually too fine-grained; they do not yet have the established practices to dose.

If you cannot decide, this shortcut helps:

• Your team's very first retro: Sailboat, for the low barrier to entry.
• An established team with a stable process: Starfish, to adjust dosages.
• After a learning-heavy phase: 4Ls, to make the learning explicit.
• Everything else: KPT or Start/Stop/Continue as the dependable default.

A Retrospective Template You Can Copy

This template works for most methods; swap the middle categories to match your format. Paste it into your shared doc or whiteboard tool:

# Retrospective - [Team] - [Date]
Period covered: [YYYY-MM-DD - YYYY-MM-DD]
Method: [KPT / Sailboat / 4Ls / ...]
Participants: [Names]

## Check-in: actions from the last retro
- [ ] [Action] - Result: [done / working / drop]

## What went well? (category depends on method)
- [Observation as a fact, plus: why did it work?]

## What slowed us down? (category depends on method)
- [Facts: when, what, and the consequences]

## Insights
- [The cause behind the most important items]

## Actions (2-3 maximum)
- [ ] [Concrete, checkable behavior] - Owner: [Name] - Check: [next retro]

## Next retro: [Date]

The check-in block sits at the top on purpose: every retro starts by reviewing the last retro's actions. That feedback loop is the difference between a retro series that compounds and a sequence of disconnected conversations.

Common Retrospective Mistakes and Their Fixes

• The retro turns into a complaint session. People talk, nod, and decide nothing. Fix: give phase 4 a fixed time slot in the agenda, and treat "two to three actions maximum, each with a name and a check date" as non-negotiable.
• People instead of processes. "Alex delivers late" is an attack, not an observation. The facilitator translates into facts: "reviews sat for two days on average." The Prime Directive at the start is not a ritual; it is the working agreement.
• The same topics return every retro. Usually a sign that the last action was a resolution ("align better") rather than a system change. Fix: for repeat topics, effort-based actions are banned; only changes to a process or a tool count.
• The retro gets cancelled when things are busy. Which is exactly when it would be most valuable. Teams that drop retros under pressure are signaling that improvement is a fair-weather activity. Shorten it to 30 minutes rather than skipping it.
• Nobody captures anything, so nothing compounds. Whiteboard photos are not searchable, and a designated note-taker loses half the discussion. Without reliable notes, the check-in block dies, and with it the value of the whole series. More on that next.

Remote Retrospectives and the Documentation Problem

Retrospectives work surprisingly well remotely, often better than in a meeting room: silent writing phases translate naturally into shared documents and online whiteboards, and quieter voices get equal weight in writing. What stays the same, remote or in person, is the documentation problem: the discussion is the most valuable part of the retro, and it evaporates.

This is where a real-time AI meeting assistant helps. SuperIntern is a bot-free desktop app (Mac and Windows) that captures audio directly from your device. No bot joins the call, so it works identically whether your retro happens in Zoom, Google Meet, Microsoft Teams, or Webex, and even in an in-person retro where a laptop simply listens along.

For retrospectives specifically:

• Teach AI Canvas your retro format once. Describe it in plain language: "This is a Sailboat retrospective. Sort the discussion into Wind, Anchor, Rocks, and Goal, and record agreed actions with an owner." Every following retro fills itself in live, in that structure.
• The facilitator facilitates instead of typing. Nobody has to drop out of the discussion to keep minutes; the note grows while the team talks.
• The check-in takes seconds. Last retro's actions are in last retro's note. The cross-meeting AI chat can also answer: "Which topics came up repeatedly in the last three retros?"
• Distributed teams stay in sync. Real-time translation across 50+ languages makes a shared retro with an overseas office possible, and everyone gets the summary in their own language.

An honest note on limits: SuperIntern does not replace an online whiteboard for the silent writing phases, and it is not a task manager for tracking actions. What it removes is the documentation burden, and it makes the whole series searchable. There is a free plan, so trying it at your next retro costs nothing.

FAQ

What does retrospective mean?

Literally "a look back" (from the Latin retrospectare). In a work context, a retrospective is a recurring team meeting that examines how the team collaborated over a completed period and decides on concrete improvements for the next one. In art, the same word means an exhibition covering an artist's entire body of work.

What are the 5 phases of a retrospective?

Following Esther Derby and Diana Larsen: Set the Stage, Gather Data, Generate Insights, Decide What to Do, and Close. The phases lead the team from observations through causes to checkable decisions.

How long should a retrospective take, and how often should it happen?

For up to eight people covering two weeks, 60 to 90 minutes is typical. The Scrum Guide sets an upper bound of three hours for a one-month sprint. The rhythm follows your work cycle: once per sprint, or every two to four weeks outside agile teams. Less often than monthly, memories fade and the discussion drifts from facts to impressions.

What is the difference between a review and a retrospective?

The review looks at the work output: what was built, and what do stakeholders think of it? The retrospective looks at the way of working: how did we collaborate, and what do we change about it? In Scrum, both happen at the end of the sprint, the review first.

Does a retrospective work without Scrum?

Yes. The format predates Scrum and works anywhere a team collaborates on a recurring basis: sales teams use it as a monthly review, marketing teams after campaigns, operations teams after project phases. All it needs is a defined period, a recurring slot, and the discipline to end with actions.

Who facilitates the retrospective?

In Scrum teams, often the Scrum Master, but in principle anyone who can hold the structure without being at the center of the discussion. Rotating facilitation inside the team works well once the format is established. For emotionally loaded topics, a neutral facilitator from outside the team is worth it.

What if the team is too big for a retrospective?

Above roughly eight to ten people the dynamic tips over: speaking time per person shrinks and half the room checks out. What works is splitting into small groups of four to six that gather and discuss in parallel, followed by a short joint round where each group presents its most important insight and its actions. Topics that span departments move into their own format with the people actually involved.

Conclusion

A retrospective is the smallest recurring investment a team can make in its own way of working. The success conditions are unspectacular: a regular slot that survives busy weeks, the five phases as a dramaturgy, a method that fits the team, at most two or three checkable actions with owners, and a check-in that opens every retro with a review of the last one's actions.

The record that holds this series together no longer needs to be kept by hand. Hand the documentation to a bot-free AI assistant, and the team gets its full attention back for the retro's actual job: deciding, together, what changes.

Try SuperIntern Free : no bot in the meeting, live notes in your retro format, and every action reliably carried into the next retro.