Sprint Retrospective Template: 5 Formats That Actually Work

Your first retro was great. People were honest. The team identified real problems. Two action items came out of it. Someone even said "we should do this more often."

By sprint 3, the retro is a ghost town. Same three people talk. Same issues come up. Nobody remembers what the action items were from last time. Half the team is on Slack during the meeting. The facilitator asks "anything else?" and gets silence.

This is the retro death spiral, and nearly every engineering team hits it. The problem is not the retrospective itself. It's that teams use the same format every time, never follow through on action items, and eventually stop believing the retro changes anything.

The fix is two things: rotate formats so the conversation stays fresh, and ruthlessly track action items so the retro produces results. Here are five retro templates that cover every team situation, plus a framework for actually running them well. Whether you run Scrum, Kanban, or a custom agile process, these agile retrospective templates adapt to any workflow.

Why most retros stop working after 3 sprints

Retros die for three reasons, and format fatigue is only one of them.

Reason 1: Same format, every sprint. Start/Stop/Continue is a great format for your first five retros. After that, the same prompts produce the same answers. People stop thinking because the structure has become a fill-in-the-blank exercise. Rotating formats forces new angles on old problems.

Reason 2: No follow-through. This is the real killer. If the team identifies "code review bottleneck" in sprint 4, agrees on a fix, and then raises the exact same issue in sprint 6 because nobody acted, the retro has lost credibility. People stop participating when they realize nothing changes. One study from Scrum.org found that teams who consistently act on retrospective items improve their velocity by 10-15% per quarter, while teams that don't see no measurable improvement.

Reason 3: It doesn't feel safe. In teams with low trust, retros surface symptoms instead of root causes. People say "communication could be better" instead of "the PM keeps changing scope mid-sprint and it's killing us." Anonymity helps. So does using emotion-based formats (like Mad/Sad/Glad) that give people permission to be honest.

If your retro has become a meeting that drains people instead of energizing them, the format is probably the first thing to change.

5 sprint retrospective templates

1. Start / Stop / Continue

The classic. Three columns, one question each. This is the retro template most teams learn first, and for good reason: it's dead simple.

Best for: New teams, first retro ever, teams that have never done a structured retro before.

Time: 30-40 minutes.

Retrospective — Sprint [Number] — [Date]

Start (things we should begin doing)

• Write acceptance criteria before sprint starts
• Pair programming on complex features
• Sharing demos async via Loom

Stop (things that aren't working)

• Changing sprint scope after day 2
• Skipping code review to hit deadlines
• 1-hour estimation meetings for 1-point stories

Continue (things that are working well)

• Daily standup at 9:15, keeps it short
• Documenting decisions in ADRs
• Rotating on-call schedule

Action items:

• [Owner] PM to freeze scope after sprint planning, permanent
• [Owner] Alice to create ADR template for new services, by next Friday

The trap with Start/Stop/Continue: the "Continue" column tends to be a feel-good list that produces no action. Focus your discussion time on Start and Stop, those are where changes happen.

2. What Went Well / What Didn't / Action Items

A stripped-down variant that cuts straight to outcomes. No third "feel-good" column. Just what worked, what didn't, and what you're going to do about it.

Best for: Short sprints, small teams (3-5 people), teams that want speed over depth.

Time: 20-30 minutes.

Retrospective — Sprint [Number] — [Date]

What went well

• Deployment pipeline worked flawlessly
• Cross-team handoff with design was smooth
• Bug count dropped 30% from last sprint

What didn't go well

• Two incidents caused by untested edge cases
• Unplanned work from sales ate 2 days
• Code review bottleneck on Thursday/Friday

Action items:

• Add edge case coverage to PR checklist. Dave, permanent
• Raise scope intrusion issue with Product in planning. Alice, next sprint
• Implement review rotation: max 4-hour turnaround. Bob, by Monday

This format works when your team is disciplined. The risk: without a reflection prompt, the conversation stays surface-level. If your retros feel shallow, switch to 4Ls or Mad/Sad/Glad for a few sprints.

3. 4Ls: Liked / Learned / Lacked / Longed For

Four prompts that go deeper than the typical retro. "Learned" surfaces growth. "Longed For" surfaces unmet needs that people might not voice otherwise.

Best for: Teams that want personal growth alongside process improvement. Teams that have done Start/Stop/Continue for too long and need a reset.

Time: 35-45 minutes.

Retrospective — Sprint [Number] — [Date]

Liked (what you enjoyed)

• Collaborating on the search feature with the backend team
• The new CI pipeline is noticeably faster
• Friday demo: good energy, real feedback from stakeholders

Learned (new skills, insights, realizations)

• React Server Components are trickier than expected for dynamic forms
• Our monitoring gaps only show up under load, need canary deployments
• Writing the RFC first actually saved time during implementation

Lacked (what was missing)

• Clear priorities when two projects competed for the same person
• Staging environment was down for 3 days with no ETA
• Feedback on the design before we started building

Longed For (what you wish existed)

• A dedicated time slot for tech debt, even 20% of the sprint
• Better async updates so we don't need the Wednesday status meeting
• Access to production logs without going through the ops team

Action items:

• Propose 20% tech debt allocation to PM. Carol, before next planning
• Replace Wednesday status with async update in Slack. Dave, this week

4. Sailboat

A visual metaphor that works especially well for remote teams using Miro, FigJam, or a whiteboard. The team is a boat sailing toward a destination. Four forces act on it.

Best for: Creative teams, remote teams using visual collaboration tools, teams tired of text-based formats.

Time: 40-50 minutes (the visual element takes slightly longer).

Retrospective — Sprint [Number] — [Date]

Island (our destination / sprint goal)

• Ship the checkout redesign with 50% abandonment reduction

Wind (what pushed us forward)

• Clear requirements from product
• Senior dev mentoring junior on payment integrations
• Good test coverage caught two regressions early

Anchor (what held us back)

• Flaky test suite caused 3 failed deploys
• Waiting on legal review for new payment provider TOS
• Context switching between checkout and the urgent security fix

Rocks (risks ahead)

• Payment provider API migration happening mid-sprint
• Carol on PTO next sprint, she owns the frontend
• No load testing done yet and launch is in 3 weeks

Action items:

• Fix top 5 flaky tests before next sprint starts. Eve, by Friday
• Carol to document checkout frontend patterns before PTO. Carol, by Wednesday
• Schedule load test with DevOps. Bob, this week

The Sailboat format naturally surfaces risks (the rocks), which other formats miss. If your team tends to focus on past problems and ignore future ones, try this format.

5. Mad / Sad / Glad

Emotion-first. This format gives people permission to express how they feel, not just what they think. It's the best format for teams where frustration is building but nobody is saying it directly.

Best for: Teams with trust issues, unspoken tension, post-incident retros, teams where the same problems keep recurring because the real cause isn't being named.

Time: 35-45 minutes.

Retrospective — Sprint [Number] — [Date]

Mad (frustrated, angry)

• Scope changed AGAIN after we committed. Third sprint in a row.
• Nobody reads the async updates, then asks the same questions in meetings
• On-call escalation process is broken. Got paged at 2am for a non-critical alert

Sad (disappointed, let down)

• We missed the deadline and the demo was embarrassing
• Lost a team member to another team. Didn't see it coming
• Tech debt keeps growing and we never get time to address it

Glad (happy, grateful)

• New hire is ramping up faster than expected
• The refactor we fought for actually reduced bugs by half
• Team lunch on Thursday was a good reset

Action items:

• Escalate scope change pattern to director. Tech Lead, this week
• Fix on-call alert thresholds. Dave, by Wednesday
• Propose sprint-level tech debt budget to PM. Alice, before next planning

How to run a retro that doesn't suck

The format is 20% of the equation. How you run it is the other 80%.

Time-box to 45 minutes. Retros that drag past an hour lose energy. If you can't cover everything in 45 minutes, you have too many topics. Vote on the top 3 and drop the rest.

Start with silent brainstorming (5 minutes). Don't let the loudest person dominate. Give everyone 5 minutes to write their sticky notes or type their items in silence. This levels the playing field and produces 2-3x more input than open discussion. A meeting agenda template shared before the session helps people come prepared.

Group and vote (10 minutes). Cluster similar items into themes. Then dot-vote: each person gets 3 votes. Discuss only the top 2-3 themes. Everything else goes to a parking lot for next time.

One action item per theme, max. The retro should produce 2-3 action items, not 10. Each one has a single owner and a deadline. "The team will improve code reviews" is not an action item. "Bob will implement a 4-hour review SLA starting Monday" is. Use meeting minutes to capture these so nothing gets lost between sprints.

Follow up at the start of the next retro. First 5 minutes: review last sprint's action items. Did they happen? If not, why? This is the accountability loop. Skip it and the retro becomes a recurring meeting nobody believes in.

The facilitator should rotate. Same person running every retro leads to same patterns. Rotating the facilitator brings fresh energy and distributes ownership. It also makes the retro feel like the team's meeting, not the scrum master's meeting.

Consider async pre-work. Have the team submit their items before the meeting using a shared doc or tool. The retro meeting itself focuses on discussion and action items, not brainstorming. This cuts meeting time by a third and produces more thoughtful input. For teams already using async communication for standups, extending it to retro pre-work is a natural next step.

---

Retros are one of the most valuable meetings on your calendar, when they work. But "when they work" is doing a lot of heavy lifting. The format matters. The follow-through matters more.

And here's an uncomfortable question: what does your team actually think about the retro itself? Most facilitators assume the retro is valuable because they find it valuable. But if you asked the team anonymously, you might get a different answer. Kill One Meeting collects anonymous ratings on every recurring meeting, including your retro. If the team rates it 2 out of 5, maybe it's time to switch formats. Or maybe it's time to pause and fix the action item loop first. Free for 30 days.