Most retrospective guides tell you to "create psychological safety" and "follow the Prime Directive." That's not wrong, but it's also not enough. If you've ever walked out of a retro feeling like it was a waste of 60 minutes, the problem isn't the concept — it's the execution.
This guide is for facilitators who want retros that produce real change, not just a Confluence page that nobody reads.
What a retrospective actually is
A sprint retrospective is a meeting at the end of each sprint where the team answers three questions:
- What worked?
- What didn't?
- What are we going to do differently?
That's it. Everything else — templates, voting, icebreakers — is scaffolding to help you answer those three questions better.
Duration: 45-60 minutes for a 2-week sprint. Shorter sprints get shorter retros.
Frequency: End of every sprint, after the review, before planning.
Attendees: Everyone who worked during the sprint. Not stakeholders, not managers (unless the team genuinely wants them there).
The 5 phases (and how long each should take)
For a 60-minute retro:
| Phase | Time | What happens |
|---|---|---|
| Set the stage | 5 min | Quick check-in, remind people this is a safe space |
| Gather data | 15 min | Silent card writing — everyone adds cards independently |
| Group & discuss | 15 min | Cluster similar cards, identify patterns, talk through themes |
| Vote & decide | 15 min | Dot vote on priorities, create 2-3 action items with owners |
| Close | 10 min | Recap actions, ask "how was this retro?", export results |
If your retros regularly run over 60 minutes, you're not being disciplined enough with timeboxing. Cut content, don't extend time.
Phase by phase
1. Set the stage (5 minutes)
Don't skip this. A cold start leads to a cold retro.
What to do:
- Acknowledge the team's time: "I know we're all busy, so let's make this count"
- Briefly review action items from last retro: Were they done? Did they help?
- Run a quick check-in (pick one):
- "Rate your sprint from 1 to 10"
- "One word to describe this sprint"
- "What's one thing that happened outside of work this week?"
The check-in serves two purposes: it gets everyone's voice in the room early (studies show people who speak in the first 5 minutes are more likely to contribute throughout), and it gives you a read on the room's energy.
2. Gather data (15 minutes)
This is where most retros go wrong. Teams default to verbal brainstorming, which means the first person to speak sets the tone, loud voices dominate, and introverts check out.
The fix: silent card writing.
Set a timer for 7 minutes. Everyone writes cards independently, silently, on the retro board. No talking. The facilitator should mute themselves (if remote) or stay quiet.
Then give 2 minutes for everyone to silently read the cards.
Why this works:
- Equal voice for everyone, regardless of personality type
- People think more deeply when they're writing, not reacting
- You get more diverse perspectives because there's no anchoring effect
- It's faster than going around the room verbally
Template options (pick one):
- Went Well / To Improve / Action Items — best for new teams or general retros
- Start / Stop / Continue — best when the team needs to change behaviors
- Mad / Sad / Glad — best after a rough sprint when emotions need processing
- Sailboat (Wind / Anchors / Rocks) — best for identifying blockers and risks
- 4Ls (Liked / Learned / Lacked / Longed For) — best after major milestones
Don't use the same template every sprint. Rotate every 4-6 retros.
Writing better cards:
- Bad: "Communication could be better"
- Good: "We found out about the API change 2 days after it shipped, which broke our frontend integration"
- Bad: "Great sprint!"
- Good: "Pair programming on the auth module helped us catch 3 edge cases before they hit production"
If your team writes vague cards, give them specific prompts: "Think about a moment this sprint that frustrated you. What happened? Why?"
3. Group & discuss (15 minutes)
After silent reading, start grouping similar cards. You'll usually see 3-5 natural themes emerge.
Facilitator moves:
- "I see four cards about code review delays. Can someone summarize the pattern?"
- "Are these two issues related or separate?"
- "Has anyone else experienced this?"
What not to do:
- Don't start solving problems yet. This phase is about understanding, not fixing.
- Don't dismiss anyone's experience. Even if you disagree, the card represents how someone felt.
- Don't let one person talk for 5 minutes. Interrupt politely: "Good point — let's hear other perspectives."
4. Vote & decide (15 minutes)
Give everyone 3 votes. Let them vote silently. Then reveal all votes at once.
Focus your remaining time on the top 2-3 voted items. For each one, ask:
- What specifically will we do?
- Who owns it? (A name, not "the team")
- By when?
- How will we know it worked?
Good action items have four properties:
- Specific enough that you could verify completion
- Owned by a single person
- Completable within one sprint
- Connected to a pain point the team actually cares about
Examples:
| Bad action item | Good action item |
|---|---|
| "Improve communication" | "Alex will post API changes to #engineering 24 hours before deployment, starting Monday" |
| "Write more tests" | "Jordan will add the 3 missing integration tests for the payment flow by Thursday" |
| "Fix code review delays" | "Team agrees: all PRs under 300 lines get first review within 24 hours. We'll track this for 2 weeks." |
Limit to 2-3 action items. Teams that commit to 8+ action items complete almost none of them. Two completed improvements are worth more than ten abandoned ones.
5. Close (10 minutes)
- Recap action items out loud. Confirm owners acknowledge them.
- Ask: "How was this retro? Should we try a different format next time?"
- Export the board (PDF or Markdown) and share it in Slack or wherever your team communicates.
- Add action items to your sprint backlog immediately. If they're not in Jira/Linear/whatever you use, they won't get done.
Common problems and what to do
"The same issues come up every retro"
This means action items aren't getting done. Start every retro by reviewing previous actions. If something has been raised three sprints in a row, either it needs to be escalated to management, or the action items aren't specific enough.
"Nobody speaks up"
Use anonymous mode for card writing. If that doesn't help, the problem is psychological safety, not the tool. Have a private conversation with the team: "What would make it safer to share honest feedback?"
"One person dominates"
Use silent card writing (prevents verbal domination) and explicitly invite quiet people: "Let's hear from someone we haven't heard from — Sam, what's your take?"
"Retros feel like a waste of time"
This is almost always a follow-through problem. When retros don't lead to change, people stop engaging. The fix is completing your action items and celebrating the wins: "Remember when code reviews took 3 days? Our SLA action item brought that down to 18 hours."
"We don't have time for retros"
A 45-minute retro that prevents one recurring problem from wasting team time next sprint is a net positive investment. If your retros genuinely don't produce useful outcomes, the answer is to run better retros, not to skip them.
One more thing
The most important thing about retrospectives isn't the template, the tool, or the facilitation technique. It's follow-through.
A retro where the team raises real issues, commits to one concrete change, and actually implements it — that retro was worth an hour. A retro with perfect facilitation, beautiful templates, and 10 action items that nobody completes — that was a waste of everyone's time.
Focus on follow-through. Everything else is secondary.
Try NextRetro free — built-in voting, anonymous mode, and phase management to keep your retros focused.
Last Updated: February 2026
Reading Time: 8 minutes
