How to Run a Sprint Retrospective

A retrospective is the most underused ceremony in Scrum. Done well, it compounds improvement over time. Done badly, it becomes a complaint session that changes nothing.

The Goal

The goal of a retrospective is one thing: identify one or two specific improvements and commit to making them next sprint. Not to vent. Not to celebrate. Not to review tickets. To improve how the team works.

Before the Retro

• Book 60–90 minutes for a two-week sprint (shorter sprints = shorter retros)
• Send a pre-retro prompt the day before so people can gather thoughts without pressure of the room: "What's one thing you want to discuss tomorrow?"
• Use a shared board — Miro, FigJam, or even a Notion page works fine
• The Scrum Master facilitates — they don't drive the agenda, they ensure everyone speaks and the session stays on track

Classic Format: Start / Stop / Continue

The simplest format that works for most teams:

| Column | Question | |---|---| | What went well | What should we keep doing? | | What didn't go well | What caused friction or pain? | | Action items | What will we specifically change next sprint? |

Run it like this:

1. Silent writing (5 min) — everyone writes sticky notes independently, no discussion yet
2. Group & read out (10 min) — cluster similar themes, the facilitator reads each one
3. Dot vote (5 min) — everyone gets 3 votes to prioritise what to discuss
4. Discuss top themes (30 min) — dig into the highest-voted items only
5. Define action items (10 min) — specific, owned, time-boxed

What Good Action Items Look Like

Bad: "We should communicate better."
Good: "From next sprint, we use a #blocked Slack channel and anyone blocked for >2 hours posts there."

Every action item needs:

• A specific behaviour change
• An owner (one person, not "the team")
• A way to measure it next retro

Other Formats Worth Trying

4Ls (Liked, Learned, Lacked, Longed For) — good for teams that find Start/Stop/Continue too negative.

Mad/Sad/Glad — useful when team morale is the main issue to surface.

Sailboat — wind (things moving us forward), anchors (things slowing us down), rocks (risks ahead). Good for teams that are stuck in cycles.

Common Mistakes

No action items. The most common failure. If you end a retro without at least one concrete commitment, it was a venting session.

Rehashing the same issues every sprint. If the same problem keeps appearing, the previous action items weren't specific enough.

The same person talks the most. Use silent writing and dot voting to equalise voices.

Skipping the retro when things are going well. That's exactly when you can have the most productive conversation — without pressure.

Reviewing the Previous Retro

Start every retro by reviewing last sprint's action items: were they done? Did they help? This single habit is what separates teams that improve from teams that just talk about improving.