Retrospective Learning
A team that does not reflect does not improve. The retrospective is the mechanism by which experience becomes knowledge — by which "we did something" transforms into "we understand what we did, why it worked or didn't, and what we will do differently." Without retrospectives, teams repeat the same mistakes across projects, sprints, and careers. With retrospectives, each iteration is smarter than the last.
But retrospectives are fragile. They require honesty, and honesty requires safety. A team that fears blame will report only successes. A retrospective that surfaces only successes is not a retrospective — it is a performance. This skill covers both the mechanics (formats, facilitation, data) and the human conditions (psychological safety, blameless culture, celebration) that make retrospectives actually work.
Agent affinity: sinek (pedagogy/leadership), deming (quality/continuous improvement)
Concept IDs: bus-stakeholder-theory, bus-business-ethics, crit-problem-analysis, crit-evidence-evaluation, ps-metacognition
Retrospective Format Catalog
| # | Format | Best for | Duration | Team size | |---|---|---|---|---| | 1 | Start/Stop/Continue | General purpose, quick | 30-60 min | Any | | 2 | 4Ls | Balanced reflection | 45-60 min | 4-10 | | 3 | Timeline | Complex sprints with many events | 60-90 min | 5-12 | | 4 | Sailboat | Visual, metaphor-driven | 45-60 min | 4-10 | | 5 | Starfish | Fine-grained action | 45-60 min | 4-10 | | 6 | Mad/Sad/Glad | Emotional check-in | 30-45 min | Any |
Rotation principle. Use different formats across sprints. The same format every time leads to mechanical responses. Novelty keeps thinking fresh.
Format 1 — Start/Stop/Continue
The simplest and most widely used format. Three columns:
- Start: Things we should begin doing
- Stop: Things we should cease doing
- Continue: Things that are working and should persist
Facilitation Guide
- Silent brainstorming (5 min). Each person writes items on sticky notes (one idea per note). No discussion during writing.
- Share and cluster (10 min). Post notes on the board. Group related items. Read aloud for remote participants.
- Dot vote (3 min). Each person gets 3-5 dots. Vote on the items you think are most important.
- Discuss top items (20-30 min). Take the top 3-5 voted items. For each: What specifically happened? What should we do about it? Who will own it? By when?
- Capture actions (5 min). Write down committed actions with owners and deadlines.
Worked Example — Sprint 7 Retrospective
Start:
- Start writing acceptance criteria before sprint planning (3 votes)
- Start pairing on complex database migrations (5 votes)
- Start tagging Slack messages by project context
Stop:
- Stop attending the all-hands product meeting (not relevant to our sprint work) (4 votes)
- Stop deploying on Fridays (2 incidents caused by Friday deploys) (7 votes)
- Stop accepting stories without acceptance criteria (6 votes)
Continue:
- Continue daily standup format (keep it to 15 min) (3 votes)
- Continue PR size limit of 400 lines (2 votes)
- Continue weekly tech debt allocation (4 votes)
Top actions:
- No Friday deploys — effective immediately. Owner: Scrum Master. (7 votes)
- Stories require acceptance criteria before entering sprint backlog. Product Owner to enforce. (6 votes)
- Pair programming for database migrations. Schedule pairing sessions on migration days. Owner: Dev Lead. (5 votes)
Format 2 — 4Ls (Liked, Learned, Lacked, Longed For)
- Liked: What did we enjoy? What went well?
- Learned: What new knowledge did we gain?
- Lacked: What was missing? What held us back?
- Longed For: What do we wish we had?
Worked Example
Liked:
- The spike on the caching layer — gave us confidence before committing to the approach
- Fast PR reviews this sprint (under 4 hours average)
Learned:
- Redis cluster mode requires different connection handling than standalone
- Our staging environment does not accurately reflect production memory limits
Lacked:
- Clear documentation on the payment API's retry behavior
- Access to production logs during the outage investigation (permissions issue)
Longed For:
- Automated performance tests in CI (currently manual)
- A dedicated design resource for the dashboard redesign
4Ls advantage. The "Learned" column captures knowledge that Start/Stop/Continue misses. The "Longed For" column captures aspirations without implying blame.
Format 3 — Timeline Retrospective
For sprints with many events, the timeline format reconstructs the sprint chronologically:
- Draw the timeline. X-axis is time (day by day through the sprint). Y-axis is mood (high/low).
- Mark events. Each person adds events to the timeline: decisions, deployments, blockers, breakthroughs, surprises.
- Plot the mood curve. The team collectively draws a line showing morale over the sprint.
- Discuss inflection points. Where did mood drop? Where did it rise? What caused the changes?
Worked Example — Sprint 9 Timeline
Mood
^
| * *
| / \ * / \
| / \ / \ / \ *
|/ * * \ * / \
| \ / \ / *--
| \/ *
+---+---+---+---+---+---+---+---+---+----> Day
1 2 3 4 5 6 7 8 9 10
Events:
Day 1: Sprint planning went well (high)
Day 3: Found a critical bug in auth service (low)
Day 4: Root cause identified, fix deployed (recovery)
Day 5: Client demo, positive feedback (high)
Day 6: Surprise scope change from product (low)
Day 7-8: Team absorbed scope change, rallied (gradual recovery)
Day 9: Production incident — unrelated legacy system (low)
Day 10: Incident resolved, sprint goals met (recovery)Discussion focuses on the dips: Day 3 (bug) — why wasn't it caught by tests? Day 6 (scope change) — what's the process for mid-sprint scope injection? Day 9 (incident) — why is legacy system health our problem?
Timeline advantage. Reveals patterns invisible in other formats: recurring Tuesday blockers, post-deploy dips, demo-day spikes. The visual triggers memories that a prompt-based format does not.
Format 4 — Sailboat
A metaphor-driven format that uses a sailing metaphor:
- Wind (sails): What propelled us forward? What gave us momentum?
- Anchor: What held us back? What slowed us down?
- Rocks: What risks or dangers do we see ahead?
- Island: What is our goal? Where are we heading?
Worked Example
Wind:
- Automated database migration script saved 2 days
- New team member ramped up faster than expected (good onboarding docs)
Anchor:
- Flaky CI pipeline — 3 false-negative test failures this sprint, causing re-runs and lost time
- Waiting for design approval added 2-day delay to 3 stories
Rocks (ahead):
- Black Friday traffic spike in 6 weeks — performance testing not yet started
- Key dependency (payment gateway) is migrating to v3 API; our integration uses v2
Island:
- Stable, performant checkout experience before Black Friday
Sailboat advantage. The "Rocks" section naturally transitions into risk identification for the next sprint. The "Island" keeps the team aligned on the goal. The metaphor makes the conversation less confrontational — "what's anchoring us" feels different from "what went wrong."
Format 5 — Starfish
An expansion of Start/Stop/Continue with finer granularity:
- Keep doing: High-value practices to maintain
- More of: Good things we should amplify
- Less of: Things that are not serving us well
- Stop doing: Things to eliminate entirely
- Start doing: New practices to introduce
When to use. When Start/Stop/Continue feels too coarse. The "More of" and "Less of" categories capture nuance — the practice is not bad enough to stop, but we should modulate it.
Format 6 — Mad/Sad/Glad
Emotional check-in format:
- Mad: What f