A retro — short for retrospective — is a recurring meeting where a team looks back at a period of work and asks what went well, what did not, and what to change. The format is simple enough that almost every team claims to run one, and the quality gap between a retro that produces real change and one that produces a stale list of complaints is almost entirely about facilitation, not the specific template used.
What changed in 2026
- Async retro tools have expanded, letting distributed teams submit reflections before the live discussion, which tends to surface more candid input than pure live brainstorming, particularly from quieter team members.
- "Retro fatigue" has become a named, discussed problem as more teams run biweekly or even weekly retros without varying the format, leading to declining participation over time.
- More teams now explicitly track action-item completion rate as a retro health metric, treating a low follow-through rate as a signal the retro process itself needs fixing, not just the team's execution.
Retro formats compared
| Format |
Structure |
Best for |
| Start-Stop-Continue |
Three columns: what to start, stop, keep doing |
General-purpose, easy to run |
| Mad-Sad-Glad |
Emotional categorization of the period |
Teams processing a rough sprint or incident |
| 4 Ls (Liked, Learned, Lacked, Longed for) |
Broader reflective prompts |
Longer retro cycles (monthly, quarterly) |
| Sailboat (wind, anchor, rocks, island) |
Metaphor-based: what helps, hinders, risks, goal |
Teams that respond well to visual framing |
| Plain three-question retro |
What went well / what did not / what will we change |
Time-constrained teams, quick cadence |
No format is inherently superior. Varying the format periodically is itself useful — repeating the identical structure meeting after meeting is one of the more common causes of retro fatigue.
Running the retro well
Start with psychological safety, not the template. If people do not feel safe naming real problems — especially ones involving a manager or a decision that went badly — the format is irrelevant, because the honest input never surfaces. Rotating who facilitates, explicitly separating the retro from performance discussions, and modeling vulnerability by naming your own mistakes first are all more load-bearing than which board layout you use. Psychological safety at work is worth building as a standing practice, not something to invoke only during the retro itself.
Give people time to reflect individually before group discussion — either async submission beforehand or five silent minutes at the start of the meeting. Groups that jump straight into open discussion tend to get dominated by whoever speaks first or loudest, and quieter or more junior voices get lost.
Close every retro with specific, owned action items — not "we should communicate better" but "Priya will set up a shared blocker channel by Friday." Vague intentions do not survive contact with the next sprint's workload.
Handling blame without shutting down honesty
The hardest facilitation skill in a retro is separating "what happened and why" from "whose fault was it." Blame-focused retros make people defensive and guarded, which suppresses exactly the information the retro exists to surface. Framing questions around systems and processes ("what made this mistake possible") rather than individuals ("who caused this") tends to produce more useful, less defensive input — this is the same underlying skill involved in giving feedback well: describing behavior and impact, not judging character.
Common mistakes
- Never reviewing previous action items. Opening each retro with a quick check on what happened to last time's commitments is what makes the exercise feel consequential rather than performative.
- Running it only after failures. Retros that only happen after something goes wrong train the team to associate them with blame. Regular cadence, regardless of outcome, normalizes the practice.
- Letting the same few voices dominate. Without structure (silent writing, round-robin sharing), retros default to whoever is most comfortable speaking up.
- Too many action items. Three focused, owned commitments beat a list of twelve vague ones that nobody actually tracks.
FAQ
How often should a team run a retro?
Common cadences are end-of-sprint (roughly every one to two weeks) or monthly for teams without sprints. More frequent than that risks fatigue; less frequent risks losing the detail needed for a useful discussion.
Who should facilitate a retro?
Rotating facilitation among team members, rather than defaulting to the manager every time, tends to produce more candid input, particularly on topics involving the manager's own decisions.
What if the retro turns into a complaint session with no action items?
That is usually a facilitation gap, not a team problem. Explicitly time-boxing the "what went wrong" discussion and reserving dedicated time for "what will we do differently" keeps the meeting from stalling in venting mode.
Should retros be tied to performance reviews?
No — keeping retros separate from individual performance evaluation is important for maintaining the psychological safety that makes honest input possible in the first place.
Where to go next