How to run a sprint retrospective (step-by-step guide)

To run a sprint retrospective: review last retro's action items, let the team write feedback silently onto a shared board, group the cards into themes, vote on what matters most, discuss the top two or three themes, and close with concrete action items — each with an owner and a due date. For a two-week sprint, 60 minutes is enough. This guide walks through each step with timings, facilitation tactics, and the failure modes to avoid.

Before the retro: a 10-minute prep checklist

A good retro is mostly prepared before anyone joins the call:

• Pick a format. Start, Stop, Continue when you want decisions; Rose, Bud, Thorn when the sprint was rough and reflection should come first. Rotate every few sprints — the template library has options with examples.
• Set up the board in advance. Columns ready, timer configured, invite link in the calendar event. Setup during the meeting burns the team's best minutes.
• Pull up last retro's action items. You will open with them.
• Skim the sprint. Note anything the team might avoid mentioning — the missed goal, the hotfix weekend. You may need to name the elephant.
• Protect the invite list. The retro belongs to the people who did the work. Stakeholders and skip-level managers change what gets said.

The 60-minute agenda

Sixty minutes suits a two-week sprint and a team of about five. If yours is bigger or your sprint is longer, the retrospective timebox calculator rescales the phases below and tells you the discussion airtime each person gets — the number that decides whether silent writing is optional. Timing-wise, the retro is the last of the four scrum ceremonies: it follows the sprint review directly, closing the sprint before the next planning opens one.

Step 1: Set the stage (5 minutes)

Start with 60 seconds of human warm-up — a one-word check-in ("one word for this sprint") or a quick icebreaker question. This isn't fluff: people who speak in the first two minutes of a meeting are far more likely to speak again.

Then review the previous retro's action items, out loud, one by one. Done? Celebrate briefly. Not done? Ask whether it still matters, and either re-commit or consciously drop it. This single habit separates retros that change things from retros that generate notes.

Step 2: Gather data (10 minutes)

Everyone writes cards against the format's prompts — silently, with cards hidden. Silence matters because open brainstorming anchors: the first opinion spoken becomes the gravity well for every card after it. Hidden cards (a feature worth insisting on when choosing a retro tool) mean the quiet engineer's observation lands with the same weight as the tech lead's.

Facilitator's job here: hold the silence. It will feel long at minute four. It is working.

Step 3: Generate insights (15 minutes)

Reveal all cards at once. Read them aloud or have authors give a one-sentence gloss — no debates yet. Group duplicates and related cards into themes; five to eight themes is typical for a team of six.

Then vote. Give everyone 3–5 votes to distribute however they like, and use blind voting — votes revealed only after everyone has voted — so nobody votes tactically after watching the pile-on. The vote count is the agenda for the rest of the meeting.

Step 4: Decide what to do (20 minutes)

Take the top-voted theme and work it: what's actually causing this? What's the smallest change worth trying next sprint? Push past the first answer — "communication was bad" is a symptom; "we found out about the API change from a failing build" is a cause you can act on.

Convert each conclusion into an action item with three properties: specific behavior, one owner, a due date. "Improve code review" fails all three. "Sam adds a 24-hour review SLA to the team agreement by Friday" passes.

Hard limit: two or three action items per retro. A team that commits to eight changes makes zero. Park everything else — it will resurface next retro if it still matters.

Step 5: Close (5 minutes)

Read the action items back with owners and dates. Ask one closing question — "was this retro worth the hour?" or a quick 1–5 fist of fives — and note one thing to tweak about the retro itself next time. Some teams add a 30-second ritual here: naming the next sprint after what just happened (a sprint name generator supplies the options). End on time. Always end on time.

Facilitation tactics that change the outcome

• Timebox visibly. A countdown timer everyone can see turns "wrapping up" from a nag into a shared fact. Extend deliberately when a conversation deserves it — one click, not a drift.
• Round-robin when discussion lopsides. If two people have said 80% of the words, go around the room: everyone gets 30 seconds on the current theme, no interruptions.
• Anonymous cards in low-trust rooms. New teams, recent conflict, or a manager in the room: switch input to anonymous and read cards aloud yourself. Honesty follows safety, not exhortation.
• Name the elephant. If the sprint's defining event isn't on the board, say so: "Nobody wrote about the rollback. Should we?" Silence about the obvious thing costs more than the awkward moment.
• Separate controllable from escalatable. Recurring themes the team can't fix (org-level dependencies, staffing) get a different verb: escalate, with a named recipient. Venting about the same uncontrollable every sprint is how retros die.

Running it remote or async

For distributed teams, the same agenda works with two adjustments. First, collect cards asynchronously before the meeting — open the board a day or two early and let people add cards across time zones — then spend a shorter live session (30 minutes) on grouping, voting, and decisions only. Second, lean harder on the tool: hidden cards, phase locks, and timers replace the social cues of a shared room. A dedicated online retro board beats a screen-shared document precisely because it enforces the phases instead of relying on discipline. The complete distributed playbook — time-zone windows, async voting, and the practices that keep it honest — is in the remote and async retrospectives guide.

Common failure modes (and the fix)

Sample: what a good outcome looks like

A concrete end state for a two-week sprint retro, team of seven:

• 23 cards written, grouped into 6 themes
• Top votes: "PR reviews sit for days" (9), "mid-sprint scope changes" (7)
• Action items: (1) Sam adds a 24h review SLA to the team agreement — by Friday. (2) Priya moves scope-change requests to a form the PM triages before they reach the sprint — by next planning.
• Both items reviewed aloud at the next retro's opening.

That's it. Not a manifesto — two owned changes, actually revisited. Twenty-six of those a year is a different team.