Start/Stop/Continue is a fine format. The problem is running it forty times in a row: the team learns the shape of the answers, produces the same three comments, and the retrospective becomes a ritual that generates nothing.
Changing format isn't about novelty. Each structure asks the team to look at their work from a different angle, and different angles surface different problems. Below are seven, each matched to the situation it's actually good at.
All of them fit inside the same underlying five-stage structure from Esther Derby and Diana Larsen's Agile Retrospectives: set the stage, gather data, generate insight, decide what to do, close. The format changes the middle; the bones stay the same.
1. Start / Stop / Continue
Use when: the team is new to retrospectives, or you have 30 minutes.
Three columns. What should we start doing, stop doing, keep doing. It is the default for good reason — it needs no explanation and produces actionable items immediately.
Its weakness: it jumps straight to solutions. The team proposes actions before diagnosing causes, so you get treatments for symptoms. Fine occasionally, corrosive as a permanent diet.
2. The Sailboat
Use when: the team feels stuck and can't say why.
Draw a boat. Four elements:
- Wind — what's pushing us forward
- Anchors — what's holding us back
- Rocks — risks ahead
- Island — where we're trying to get to
The metaphor does real work here. "Anchor" gives people permission to name a drag factor without accusing anyone, and the island prompt frequently reveals that team members have different ideas about where they're going — which is often the actual problem.
Watch for: teams that fill anchors and leave rocks empty. Forward-looking risk is harder than backward-looking complaint, and it's usually the more valuable column. Ask directly: "what is going to hurt us in three sprints?"
3. The 4Ls
Use when: you want balance, and after a big release.
- Liked — what went well
- Learned — what we now know that we didn't
- Lacked — what was missing
- Longed for — what we wished we had
The Learned column is the reason to use this one. Most formats have no place for knowledge gained, so it goes unrecorded and gets re-learned by the next person. Teams that run 4Ls quarterly build a genuinely useful history.
The distinction between Lacked and Longed for is worth preserving: lacked is a gap in what should have been there, longed for is a wish. Different responses.
4. Lean Coffee
Use when: the team has lots to say and previous retros have run over.
A structured, agenda-less discussion. Everyone writes topics on cards. The group dot-votes. You discuss the top topic for five minutes, then take a thumbs vote: continue or move on. Repeat until time is up.
This is the best format for a team that talks a lot, because it makes the time cost of each topic visible and democratic. It also self-corrects — a topic only one person cares about doesn't get twenty minutes.
Its weakness: it favours whatever is loudest right now. Chronic, quiet problems never get voted up. Don't use it every Sprint.
Whatever the format, have people write before anyone speaks. Five minutes of silence produces more and more honest input than any amount of facilitation — and it stops the first speaker from framing the entire conversation.
5. Timeline
Use when: something specific went wrong, or after an incident.
Draw the Sprint as a horizontal line. Everyone adds events where they happened — above the line for positive, below for negative, height indicating intensity. Then look at the shape together.
Timeline is the best diagnostic format on this list. Patterns become visible that nobody would have described from memory: everything dipping on the day of the all-hands, the same stumble every Wednesday, a cluster of negatives right after a dependency handoff.
It also handles emotional content well without making it personal, because the line is the subject rather than any individual.
Needs: more time — 60 to 90 minutes. Worth it after a difficult Sprint.
6. Mad / Sad / Glad
Use when: you suspect morale is the issue, not process.
Three columns, all emotional rather than procedural. It's the only common format that asks directly how people feel, which sounds soft and is frequently the highest-signal question available.
Use it when velocity looks fine but something is off. Teams often deliver perfectly well for months while quietly burning out, and no process-focused format will detect that.
Requires: genuine psychological safety. In a low-trust team you'll get three "glad" notes and nothing else, which is itself informative — but the format won't do the trust-building for you.
7. Five Whys
Use when: the same problem keeps reappearing.
Not a whole-retrospective format so much as a technique to drop into one. Take a single recurring problem and ask "why" five times, each answer becoming the next question.
We missed the Sprint Goal. Why? — The integration took three days longer than expected.
Why? — We found the API contract had changed.
Why? — The other team shipped a breaking change without telling us.
Why? — There's no shared release calendar.
Why? — Nobody owns cross-team coordination for this platform.
The first answer would have produced "estimate integration work better", which fixes nothing. The fifth is a real, addressable organisational gap.
Caution: five is a guideline, not a target — stop when you reach something actionable. And keep the chain on systems rather than people. If your fourth "why" is a person's name, back up and reframe; the useful question is what made that outcome likely, not who was standing there.
Choosing quickly
| Situation | Format |
|---|---|
| New team, first retro | Start / Stop / Continue |
| Stuck, can't articulate why | Sailboat |
| Just shipped something big | 4Ls |
| Too many topics, retro overruns | Lean Coffee |
| A bad Sprint or an incident | Timeline |
| Delivery fine, atmosphere off | Mad / Sad / Glad |
| Same problem for the third time | Five Whys |
| Team is disengaged with retros entirely | See below — format isn't the problem |
Why teams disengage (and it isn't the format)
If your team is visibly bored of retrospectives, changing the format buys you about two Sprints. The underlying cause is almost always one of three things:
- Nothing ever changes. Twelve retrospectives, twelve action items, none completed. The team has correctly concluded the meeting has no consequences.
- Every problem is someone else's. If all output is impediments for management, the team has learned it has no agency over its own work.
- It isn't safe to be honest. The real issue is a person, a relationship, or a manager who attends. Nobody will say it in the room, and everyone says it afterwards in a DM.
One action. One named owner. One Sprint. Then open the next retrospective by reviewing it: did it happen, did it help? Teams that do this stop needing novel formats, because the meeting visibly produces change. Teams that carry five actions forward every Sprint have effectively taught themselves the event is decorative.
On making actions real
- Put the action in the Sprint Backlog, not in a retrospective document nobody opens
- Make it small enough to finish in one Sprint — "improve documentation" won't happen; "write a README for the deploy script" will
- Name a person, not the team. Everyone's responsibility is nobody's
- If an action rolls over twice, kill it and ask why it isn't happening. That question is usually more interesting than the action was
On safety
If the honest conversation is happening in private messages rather than the retrospective, no format will fix it. What helps:
- Line managers don't attend their reports' retrospectives
- Anonymous input collection when trust is low — a shared board people fill before the session
- Norms stated out loud, including the prime directive: everyone did the best they could with what they knew at the time
- Whoever is facilitating modelling it by naming their own mistakes first
That last one does more than the other three combined. A facilitator who says "I should have escalated the environment issue on day two and I didn't" makes the room safe faster than any stated norm.
For how the retrospective fits with the other events, see the five Scrum events from the product manager's seat.