Sprint Retrospective: Complete Guide — 24 Retro Activities & Games + Agenda Template

A Sprint Retrospective is the review meeting a Scrum team holds at the end of every sprint to inspect how the work got done — what went well, what didn't, and which one thing to improve next sprint. It reviews "how we work"; the Sprint Review reviews "what we built."

The 30-Second Version

Frequency: once at the end of each sprint, right after the Sprint Review;

Duration: two-week sprint → 60–90 minutes; one-week sprint → 45 minutes;

Output: 1–2 improvement actions with a named owner and a verifiable completion test (not a pile of "let's be more careful next time");

Health signal: if the actions from three consecutive retrospectives actually landed, the process is genuinely improving.

Standard Agenda (60-minute version)

Time	Segment	Purpose
0:00–0:05	Open and warm up	Set the tone: safe, about the process, not about people
0:05–0:15	Gather data	Everyone writes down facts and feelings from the sprint (use the activity frames below)
0:15–0:30	Generate insights	Cluster and vote; surface the 1–3 most important themes
0:30–0:50	Decide actions	Turn themes into concrete actions: who does what, and what counts as done
0:50–0:60	Close	Review last meeting's actions, confirm this meeting's go onto the board

The retrospective's biggest failure mode isn't awkward silence — it's "great discussion, nobody tracks the actions." Actions must go onto the sprint board and get treated like any other work item.

24 Retro Activities & Games

A. Classic frameworks (enough for everyday rotation)

Start / Stop / Continue: what to start doing, stop doing, keep doing. The simplest and most universal, fits any team;

4Ls: Liked, Learned, Lacked, Longed for;

Mad / Sad / Glad: emotion-driven, good at surfacing morale problems;

Sailboat: wind = tailwinds, anchor = drag, rocks = risks, island = goal. Highly visual; fits project milestones;

KPT: Keep / Problem / Try; popular with Japanese-style teams, crisp structure.

B. Quality-focused activities

Defect map: cluster this sprint's defects by module on a wall and eyeball the disaster zones; discuss whether it's a design problem or a process problem;

Rework timeline: list every task that was interrupted or redone, and chase the root cause (unclear requirements? unstable environment? reports missing context?);

One memorable bug: each person tells the most absurd defect of the sprint and its root cause — far more effective than abstract discussion.

C. Icebreakers to liven things up (the "retro games" category)

Two truths and a lie: each person states three things that happened this sprint, one of them false; everyone else guesses;

Emoji weather report: use emojis to sum up your sprint;

Roulette speaker: pick the next speaker at random, so it isn't always the same few voices;

Time machine: imagine looking back on today's project a year from now, and write a letter to the current team.

D. Root-cause diggers

5 Whys: chain five "whys" onto the top-voted problem;

Fishbone diagram: attribute causes across people, process, tools and environment;

Pre-mortem: assume next sprint failed; write the "failure report" in advance and work backwards to what to prevent.

E. For remote teams

Online whiteboard stickies: the classic three-column board (FunRetro / EasyRetro / Miro), anonymous notes + voting;

Silent writing, then discuss: everyone writes alone for 3 minutes first, then walk the items — avoids being anchored by the first speaker;

Heat voting: everyone gets 3 votes for the stickies they most want to discuss; only the top 2 enter discussion;

Split time, split groups: large teams break out into small-group discussions first, then merge and report back.

F. Variations to keep it fresh

Grade the sprint: score this sprint 1–10 and explain why it isn't a higher number;

Goal check: pin up the Sprint Goal and discuss each piece of work's actual contribution to it;

Role swap: developers speak for the PO, the PO speaks for QA — two minutes each;

Appreciation circle: each person publicly thanks a colleague for a specific favor; good closer, repairs morale;

Micro-experiments: package actions as experiments: "try X this sprint, check the data at the next retro to decide if it stays." Lower commitment pressure, easier to land.

How to Write Actions Nobody Forgets

Bad	Good
"Strengthen testing"	"Run the release checklist before every release, executed by this week's on-call QA; check the compliance rate at the next two retros"
"Reduce pointless communication"	"Bug reports go through the shared ledger only; in chat, post the link without describing the problem; spot-check next Wednesday"
"Improve code quality"	"Add a pre-commit lint hook, configured by the backend lead by this Friday"

Common thread: a named owner, a deadline, and a verifiable completion criterion.

Back the Retro with Data, Not Impressions

"This sprint's quality was bad" — impressionistic conclusions like that only trigger defensiveness. Let quantified data speak:

Total defects this sprint, by module and severity;

Average fix time per defect, number of back-and-forth follow-ups;

Where the defects came from (internal testing / beta user reports / production user reports).

These numbers need a single defect ledger — not archaeology through chat logs. BugCapturer reports arrive with screenshot annotations and Console/Network errors attached (see the diagnostics feature), and are pushed automatically into a Slack / Microsoft Teams channel as one follow-up entry point; pivot by module/severity/status and the numbers above fall out — export one table before the retro, and the raw material for the defect map (activity 6) and the rework timeline (activity 7) is ready.

FAQ

Q: What is the purpose of a Sprint Retrospective? A: Continuously improving how the team works. The Scrum Guide is explicit: the output is an executable improvement plan, not just an emotional release. Q: Retro vs Review — what's the difference? A: The Review presents the product increment to stakeholders; the Retrospective inspects the collaboration process (team only). Both are needed; don't merge them. Q: With only 3 people, is a retro still worth it? A: Yes — shorten it to 30 minutes: 5 minutes gathering, 10 voting, 15 deciding actions. Small teams can change process faster, so the payoff is actually bigger. Q: The same problems keep coming back. What do we do? A: It means actions aren't landing or have no owner. Next retro, start by publicly inspecting the completion rate of the last actions; if necessary, fold "improvement actions landed" into the Definition of Done. Q: Too many complaints, mood is heavy — how to handle it? A: Always close with something positive: an appreciation circle or a sprint grade. And make sure every retro produces at least one "keep doing" conclusion — a retro is not a blame session.

Browser Extension

Web SDK Embed

Share Links

Auto Context

Teams & Members

Projects & Domains