Retrospective: Methods, Formats, and Practical Guide for Teams

The retrospective (also retro, sprint retrospective, or team retrospective) is a structured reflection format in which a team reviews its collaboration, processes, and outcomes to derive concrete improvement actions. In the agile context, it typically takes place at the end of each sprint. Its conceptual foundation traces back to Norm Kerth’s Project Retrospectives (2001), while the standard methodological structure was established by Esther Derby and Diana Larsen in Agile Retrospectives: Making Good Teams Great (2006) [1][2].

What distinguishes a retrospective from an ordinary feedback conversation: it enforces a structured learning process. Instead of diffuse opinion exchange, it follows a clear phase model — from data gathering through root cause analysis to concrete actions with owners and deadlines. This generates not just reflection, but actual change. And yet practice paints a sobering picture: in a study by Andriyani et al. (2017), 64% of surveyed agile teams named the retrospective as the ritual most frequently skipped or conducted superficially [3].

Search the web for “retrospective” and you will find dozens of results with the same three formats (Start-Stop-Continue, Mad-Sad-Glad, Sailboat) and a Scrum example. None shows how to run a retrospective beyond software sprints — for instance, after a service innovation project or a failed product launch. None explains the difference between a retrospective and an After Action Review. And none honestly names the conditions under which retrospectives become a farce.

This guide closes those gaps — with 8 formats, a complete facilitation guide, a service innovation example, and an honest analysis of the most common mistakes.

Where the method comes from: From Kerth to Agile

The retrospective as a formalized method has two roots.

Norm Kerth published Project Retrospectives: A Handbook for Team Reviews in 2001 — the first systematic work on structured project reflection [1]. Kerth formulated the Prime Directive, which remains the foundational principle of every retrospective:

“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.”

The Prime Directive is not a nice ritual for the opening. It is a working hypothesis that frees the team from searching for culprits and directs attention toward systemic causes. Without this mindset, every retrospective degenerates into a tribunal — and no one will honestly report what went wrong.

Esther Derby and Diana Larsen published Agile Retrospectives: Making Good Teams Great in 2006 and defined the 5-phase structure that is now standard [2]. Their model integrated Kerth’s principles into the agile sprint cadence and made the retrospective a fixed component of Scrum — described in the Scrum Guide as the final event within a sprint [4].

Jeff Sutherland, co-creator of Scrum, positioned the retrospective as the most important of all Scrum events: “The retrospective is the point where the team owns its own improvement” [4]. The Agile Manifesto (2001) laid the foundation with Principle 12: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” [5]

The 5-phase structure by Derby and Larsen

Most retrospectives fail not because of the format, but because of missing structure. Derby and Larsen defined five phases that ensure a retrospective leads from reflection to action [2]:

Phase 1: Set the Stage — 5-10 minutes

Goal: Help all participants mentally arrive and establish the willingness for honest reflection.

Activities:

• Check-in round: “Describe the last sprint/period in one word.”
• Read the Prime Directive aloud (not only at the first retro — it needs repetition)
• State working agreements: Vegas rule (what is discussed in the retro stays in the retro), no blame, everyone gets to speak

Facilitation tip: Phase 1 feels redundant to experienced teams. It is not. Amy Edmondson’s research shows that psychological safety must be actively established in every meeting — it does not arise automatically from a good team culture [6].

Phase 2: Gather Data — 15-20 minutes

Goal: Collect facts, observations, and emotions about the reviewed period — before interpretations begin.

Activities:

• Draw a timeline of the sprint/project on the whiteboard
• Facts on sticky notes: What happened? Which events were relevant?
• Emotions on sticky notes: Where were you frustrated? Proud? Surprised?

Why emotions matter: Emotions are data. A team that is exhausted after a sprint has a problem, even if all tickets were closed. Gathering only facts misses half the relevant information.

Phase 3: Generate Insights — 15-20 minutes

Goal: Recognize patterns and understand why things went the way they did.

Activities:

• Form clusters: Which sticky notes belong thematically together?
• Ask causal questions: “Why is that so?” (not just once, but 2-3 times)
• Mark the most important patterns

Facilitation tip: This is where the most common mistake occurs: teams jump directly from Phase 2 to solutions. Resist the urge. Understand first, solve later. If the team proposes actions after 5 minutes, say: “That sounds like a good measure — I will park it here. But first: why does this problem exist at all?”

Phase 4: Decide What to Do — 10-15 minutes

Goal: Derive 1-3 concrete, actionable measures from the insights.

Activities:

• Dot-vote on the most important insights
• For the top themes: What exactly do we change? Who is responsible? By when?
• Formulate measures as SMART (specific, measurable, achievable, relevant, time-bound)

Critical: Maximum 3 actions per retrospective. More than 3 leads to none being implemented. Better to execute one action consistently than to write five on a backlog that no one reads.

Phase 5: Close the Retrospective — 5 minutes

Goal: Cleanly end the retrospective and bridge to the next one.

Activities:

• Summary: What do we take away?
• Retro-of-the-retro: “What was good about this retrospective? What do we change next time?”
• Make actions visible on the team board

8 Retrospective formats: When to use which

The choice of format is not cosmetic — different formats promote different modes of thinking. A team that has been doing Start-Stop-Continue for six sprints will eventually write the same sticky notes.

1. Start-Stop-Continue

Duration: 45-60 minutes | Difficulty: Low | Best for: Beginner teams, first retrospectives

Three columns: What should we start doing? What should we stop doing? What should we continue doing?

Strength: Extremely simple, no explanation needed, immediately usable. Weakness: Encourages superficial answers. The “Continue” column is often ignored or filled with the obvious.

2. Mad-Sad-Glad

Duration: 45-60 minutes | Difficulty: Low | Best for: Teams with emotional distance from their daily work

Three columns by emotion: What made me angry? What made me sad? What made me glad?

Strength: Makes emotions explicit — things that otherwise go unsaid. Weakness: Can devolve into a complaint wall if Phase 3 (Insights) is skipped.

3. 4Ls (Liked, Learned, Lacked, Longed For)

Duration: 45-60 minutes | Difficulty: Low | Best for: Teams that want to emphasize the learning aspect

Four columns: What did I like? What did I learn? What was lacking? What did I long for?

Strength: The “Learned” column forces active reflection on learning effects — something Start-Stop-Continue does not. Weakness: The “Lacked” and “Longed For” columns often overlap.

4. Sailboat

Duration: 60-75 minutes | Difficulty: Medium | Best for: Teams looking for causes and obstacles

The team is a sailboat. Wind propels (what moved us forward?). Anchor slows (what held us back?). Rocks/reefs below the waterline are risks (what could endanger us?). Island on the horizon is the goal (where do we want to go?).

Strength: The metaphor makes abstract concepts tangible and enables risk discussions that do not occur in other formats. Weakness: Requires a minimum level of creativity and willingness to engage with the metaphor.

5. Starfish

Duration: 60-75 minutes | Difficulty: Medium | Best for: Experienced teams that want to reflect more differentially

Five arms of the starfish: Keep doing, More of, Less of, Stop doing, Start doing.

Strength: More differentiated than Start-Stop-Continue — “less of” and “more of” capture nuances that binary formats miss. Weakness: Five categories generate more data — prioritization becomes more demanding.

6. Timeline Retrospective

Duration: 75-90 minutes | Difficulty: Medium | Best for: Project retrospectives after multiple weeks or months

The team draws the project timeline on the whiteboard and arranges events, decisions, emotions, and turning points chronologically.

Strength: Shows causal relationships that are lost in categorical formats. “Ah, the conflict in week 4 was the cause of the delay in week 6.” Weakness: Time-consuming. Not suitable for short sprint retrospectives.

7. Dot Voting Retrospective

Duration: 45-60 minutes | Difficulty: Low | Best for: Large teams (10+ people) with limited discussion time

Everyone silently writes sticky notes on an open question (e.g., “What should we change?”). Then everyone places 3 dots on the sticky notes they find most important. The top 3 topics are discussed.

Strength: Scales to large groups, prevents one person from dominating the discussion. Weakness: The silent phase can be frustrating for extroverted team members.

8. Lean Coffee Retrospective

Duration: 60-90 minutes | Difficulty: Medium | Best for: Teams that want to work topic-driven rather than format-driven

Everyone writes topics on sticky notes. Topics are prioritized by dot-voting. Each topic gets 8 minutes — then the team votes: continue discussing or move to next topic?

Strength: Maximum self-organization — the team decides what to discuss. Weakness: Can drift into favorite discussions and neglect strategically important topics.

Format selection: Decision guide

Situation	Recommended format
First retrospective of a new team	Start-Stop-Continue or Mad-Sad-Glad
Sprint retro running for 6+ sprints (routine risk)	Sailboat or Starfish (format change)
After a failed project or launch	Timeline + 4Ls
Large team (10+ people)	Dot Voting or Lean Coffee
Team under emotional strain	Mad-Sad-Glad (make emotions explicit)
Innovation team after a design sprint	4Ls or Timeline

Retrospectives beyond Scrum: Service Design and Innovation

Most descriptions frame retrospectives exclusively in the Scrum context — as a sprint event at the end of an iteration. Yet the underlying principle (structured reflection leading to action) is applicable in any context where teams work iteratively and need to learn.

Retrospective after a Service Design project

In service design projects, cross-functional teams move through phases from research through ideation to prototyping. Each phase carries risks: insights are lost between phases, stakeholders are involved too late, prototypes are built without real user data.

When: At the end of each project phase (not only at the end of the entire project) — after research, after ideation, after prototyping. A team that reflects only after 4 months has wasted 3 months of learning potential.

Format recommendation: Timeline retrospective for cross-phase projects, 4Ls after individual sprints within the project.

Retrospective after a failed launch

A particularly valuable — and often missed — use case: the retrospective after a product launch that fell short of expectations. Here the Prime Directive becomes a survival question for the team. Without it, the blame question dominates, and the actual systemic causes remain invisible.

Retrospective in innovation programs

Organizations that systematically run innovation programs — with multiple parallel innovation projects, stage-gate processes, and portfolio management — benefit from a meta-retrospective: not about individual projects, but about the innovation process itself. Questions like “Why do 80% of our ideas fail at Stage Gate 2?” or “Why does it take 14 months from concept to pilot?” can only be answered at this level.

Practical example: Retrospective after a failed service launch

Context: An insurance company has launched a new digital claims service — a self-service app through which customers can report claims, upload documents, and track processing status. After 8 weeks, the usage rate is 12% instead of the projected 40%. Customer satisfaction (NPS) has dropped by 8 points instead of rising.

A cross-functional team from product management, UX, IT, and customer service conducts a timeline retrospective (90 minutes, facilitated by an external facilitator).

Phase 1 — Set the Stage (10 min): The facilitator reads the Prime Directive and makes clear: “Today we are not looking for culprits, but for patterns. Everything discussed here serves improvement — not evaluation.” Check-in: each person describes their state of mind in one word. Result: “frustrated,” “curious,” “disappointed,” “surprised,” “motivated.”

Phase 2 — Gather Data (20 min): The timeline from the initial idea to the 8th week after launch is drawn on the whiteboard. The team places sticky notes along the timeline:

• Week -16: Product requirements defined (without customer conversations)
• Week -12: UX design started (based on internal assumptions)
• Week -8: First prototypes tested — but only with 5 internal testers
• Week -4: Beta test with 20 customers — feedback was positive, but sample too small
• Week 0: Launch
• Week +2: First complaints: “I can’t find the upload button”
• Week +4: Claims processors report that 60% of app submissions are incomplete
• Week +6: NPS drops by 8 points
• Week +8: Usage rate at 12%

Phase 3 — Generate Insights (25 min): Three central patterns:

1. No real user research before design: Requirements were defined internally, without systematic user research. The 5 internal testers did not represent the actual user group (average age of claims customers: 58 years).
2. Launched too broadly too early: The launch was company-wide instead of as a pilot with one customer segment.
3. No feedback loop between app and claims processing: The app collected data, but claims processors did not know why submissions were incomplete — there was no process for feedback to the product team.

Phase 4 — Decide What to Do (20 min): Three actions:

1. Immediate: Conduct 15 qualitative interviews with customers who tried the app and then abandoned it (Owner: UX lead, Deadline: 2 weeks)
2. Short-term: Introduce weekly feedback sync between claims processors and the product team (Owner: Product manager, Start: next week)
3. Medium-term: Launch the next feature release as a pilot with one customer segment only (Owner: Product manager, for next release cycle)

Phase 5 — Close (10 min): The facilitator summarizes: “The central insight is not that the app was bad — but that we did not validate our assumptions before we scaled.” Retro-of-the-retro: the team rates the timeline format as helpful — “The chronological view showed us where the switches were set wrong.”

Note: This example is illustratively constructed to demonstrate the method in an innovation context.

Retrospective vs. After Action Review vs. Lessons Learned

Three reflection formats that are often confused — but serve different goals and contexts:

Dimension	Retrospective	After Action Review (AAR)	Lessons Learned
Origin	Agile software development (Derby & Larsen, 2006)	U.S. Army (1970s), formalized in Training Doctrine [7]	Project management (PMI, various)
Timing	Regular, in rhythm (sprint end, phase end)	Immediately after an event or mission	At the end of a project or phase
Focus	Team process and collaboration	Plan-vs.-actual comparison: what was planned, what happened, why?	Knowledge transfer for future projects
Typical duration	60-90 minutes	30-60 minutes	2-4 hours
Output	1-3 concrete actions for the next sprint/phase	Insights into causes of deviation	Documented knowledge for the organization
Weakness	Can become routine, actions may fizzle	Requires high discipline and honest error culture	Often too late (insights come after project end), documents rarely read
Best for	Iterative teamwork with regular cadence	Individual, clearly bounded events (launch, incident, workshop)	Knowledge-intensive organizations with recurring project types

Our recommendation: Use retrospectives as a regular team ritual. Supplement with AARs after critical single events (failed launch, major incident). Use Lessons Learned only when a documented knowledge base exists that is actually read — otherwise the effort is wasted.

Comparison with the PDCA cycle: PDCA is an improvement cycle for business processes — systematic, data-driven, iterative. Retrospectives improve the team’s own working process. Both complement each other: PDCA optimizes the service, retrospectives optimize the team that optimizes the service.

5 common mistakes in retrospectives

1. No psychological safety — the retro as tribunal

Symptom: Team members say only positive things in the retro. Critical topics are discussed in one-on-ones after the meeting, not in the group.

Why it hurts: Without honest reflection, the retrospective is a waste of time. Amy Edmondson’s research shows: in teams without psychological safety, errors are systematically concealed — blocking the most valuable learning sources [6].

Fix: Read and live the Prime Directive consistently. Use anonymous formats (sticky notes instead of speaking aloud). The leader should name their own mistakes first. When a team member courageously raises a problem, the leader’s reaction is the decisive moment: appreciation or defensiveness?

2. Actions without follow-up — the filing cabinet retro

Symptom: Every retrospective produces 3-5 actions. In the next retro, it turns out none were implemented. The team stops taking actions seriously.

Why it hurts: A retrospective that produces no change undermines trust in the format. After 3-4 fruitless retros, the team rightfully asks: “Why do we even do this?”

Fix: Start every retro with a review of the previous retro’s actions. Limit actions to a maximum of 3. Formulate each action with an owner and deadline. Transfer actions directly into the sprint backlog — not onto a separate retro board that no one checks.

3. Same format every time — the routine retro

Symptom: The team has been doing Start-Stop-Continue for 12 months. The sticky notes repeat themselves. Energy drops. “Retro is boring.”

Why it hurts: Format repetition breeds thinking repetition. When the team sees the same categories, it activates the same thought patterns — and produces the same insights (or no new ones).

Fix: Switch formats every 3-4 retrospectives. Use the format selection table above. A format change alone — from Start-Stop-Continue to Sailboat — can break through stagnation because the new metaphor activates new perspectives.

4. Skipping the retrospective when things are “on fire”

Symptom: “We don’t have time for a retro right now — we need to deliver.” The retrospective is cancelled when pressure rises.

Why it hurts: Precisely during high-pressure phases, retrospectives are most valuable. When a team is under pressure, process problems accumulate fastest. Cancelling the retro when things are burning is like turning off the smoke detector because it is too loud.

Fix: Shorten the retro to 30 minutes, but never cancel it. A short retro with a single topic (“What is our biggest blocker right now?”) is better than none.

5. Too many participants — the town hall retro

Symptom: 15-20 people sit in the retro. The discussion is dominated by 3-4 people. The rest stays silent.

Why it hurts: Beyond 8-10 people, participation drops exponentially. Silent participants hold the insight, vocal participants hold the floor — and the best insights go unsaid.

Fix: Limit the retrospective to 4-8 people. For larger teams: parallel retros in small groups, followed by a brief sync of the most important insights. Or use Lean Coffee, which works with larger groups through dot-voting.

Facilitation: 7 practical tips for better retrospectives

1. Timeboxing is sacred. Set a visible timer for every phase. Without a timebox, Phase 3 (Insights) expands to 45 minutes, and no time remains for actions.

2. Silence before discussion. Start every gathering phase with 3-5 minutes of silent writing on sticky notes. This gives introverted team members the same voice as extroverted ones.

3. The facilitator does not participate. If you facilitate, you are not a participant. You write no sticky notes, you do not evaluate, you have no opinion. Your job is structure, not content. Ideally, someone outside the core team facilitates.

4. Visualize everything. Every statement is written down — on a sticky note, whiteboard, or digital tool. What is not visualized is lost.

5. Interrupt solution discussions in Phases 2 and 3. Say literally: “That sounds like a good idea — I am parking it here. But first, we want to understand why the problem exists.”

6. Ask about the unsaid. At the end of Phase 2: “Is there anything not yet on the board that is on your mind?” This question opens space for topics too sensitive for the first round.

7. End with concrete action. Every retro ends with 1-3 actions that land as user stories or tasks in the sprint backlog — not on a separate list.

When retrospectives do NOT work

1. Without psychological safety: In organizations that punish mistakes or where leadership treats criticism as an attack, the retrospective is a dangerous format. Team members will learn to say only positive things — or choose silence. The retro becomes a farce and does more harm than good, because it creates the illusion of reflection [6].

2. Without implementation authority: If the team identifies problems but lacks the authority to change anything — because all decisions come from outside the team — the retrospective generates frustration rather than improvement.

3. During acute conflicts: If two team members have an unresolved personal conflict, the retrospective is not the right format. Conflicts require mediation, not group reflection.

4. As a substitute for management decisions: Some problems are not team problems — they are management problems (insufficient resources, unclear strategy, contradictory goals). A retrospective can make these problems visible, but not solve them. If the team repeatedly names the same systemic blockers and nothing happens, the retro undermines trust in the organization.

Frequently asked questions

What is a retrospective?

A retrospective is a structured reflection format in which a team reviews its working methods and derives concrete improvement actions. In the agile context, it typically takes place at the end of each sprint (60-90 minutes). The standard structure comprises 5 phases: set the stage, gather data, generate insights, decide what to do, close [2].

What is the difference between a retrospective and a review?

A retrospective reflects on the team’s working process (How did we work?). A review evaluates the work product (What did we deliver?). In the Scrum context, the sprint review precedes the retrospective: first the team shows the result (review), then it reflects on the path there (retro) [4].

How often should you run a retrospective?

In sprint cadence: after every sprint (typically every 1-4 weeks). In projects: after each phase or milestone. The minimum frequency for effective retrospectives is once per month — less frequently and memory becomes too imprecise and insights too vague.

What is the Prime Directive?

The Prime Directive (Norm Kerth, 2001) is the foundational principle of every retrospective: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could.” It shifts focus from blame to systemic causes and creates the precondition for honest reflection [1].

What retrospective formats are there?

The most common formats are: Start-Stop-Continue (3 columns, simple), Mad-Sad-Glad (emotion-focused), 4Ls (Liked-Learned-Lacked-Longed For), Sailboat (metaphor with wind, anchor, rocks, island), Starfish (5-part, differentiated), Timeline (chronological, for projects), Dot Voting (for large groups), and Lean Coffee (topic-driven). The format choice should match the team context and be varied regularly.

How many actions should a retrospective produce?

Maximum 3 per retrospective. More than 3 leads to none being implemented. A single consistently executed action is worth more than 5 actions on a list that no one reads. Every action needs an owner and a deadline.

Related methods

• PDCA Cycle: When you want to systematically improve not the team process but a business process — PDCA is the improvement cycle, the retrospective is the team reflection format
• Service Design: Retrospectives as a reflection format within service design projects
• Design Thinking: Retrospectives after each design thinking phase to improve the creative process
• Service Design Methods Overview: Positioning the retrospective within the overall methodological landscape
• Service Innovation: Culture and Organization: The retrospective as a building block of a learning innovation culture

---

Research methodology

This article synthesizes insights from the foundational works of Kerth (2001) and Derby/Larsen (2006), research on psychological safety (Edmondson 1999), the Scrum Guide, and the analysis of 12 German-language publications on retrospectives. Sources were selected by methodological rigor, practical relevance, and currency.

Limitations: The academic literature on the effectiveness of retrospectives originates predominantly from software development. Empirical studies on application in service design and service innovation are limited. The practical example (service launch retrospective) is illustratively constructed, not a documented case study.

Disclosure

SI Labs provides consulting services in the area of service innovation and uses retrospectives as a reflection format in all phases of the Integrated Service Development Process (iSEP) — particularly at phase transitions and after pilot implementations. This practical experience informs the positioning of the method in this article. Readers should be aware of the potential perspective bias.

References

[1] Kerth, Norman L. Project Retrospectives: A Handbook for Team Reviews. New York: Dorset House, 2001. ISBN: 978-0932633446 [Foundational Work | Prime Directive | Citations: 800+ | Quality: 88/100]

[2] Derby, Esther, and Diana Larsen. Agile Retrospectives: Making Good Teams Great. Raleigh: Pragmatic Bookshelf, 2006. ISBN: 978-0977616640 [Practitioner Guide | 5-Phase Model | Citations: 2,500+ | Quality: 85/100]

[3] Andriyani, Yuli, Rose Alinda Alias, and Feras Arabi Khamees. “A systematic literature review on agile retrospective.” Journal of Theoretical and Applied Information Technology 95, No. 21 (2017): 5894-5907. [Systematic Review | Agile Practices | Quality: 70/100]

[4] Schwaber, Ken, and Jeff Sutherland. The Scrum Guide. Scrum.org, 2020. https://scrumguides.org/ [Normative | Scrum Framework | Citations: 15,000+ | Quality: 90/100]

[5] Beck, Kent, et al. Manifesto for Agile Software Development. 2001. https://agilemanifesto.org/ [Foundational Work | Agile Principles | Citations: 20,000+ | Quality: 95/100]

[6] Edmondson, Amy C. “Psychological Safety and Learning Behavior in Work Teams.” Administrative Science Quarterly 44, No. 2 (1999): 350-383. DOI: 10.2307/2666999 [Empirical Study | N=51 Teams | Citations: 12,000+ | Quality: 92/100]

[7] U.S. Army. “A Leader’s Guide to After-Action Reviews.” Training Circular 25-20, 1993. [Military Doctrine | AAR Standard Reference | Quality: 80/100]