Guide
What is a sprint retrospective?
A sprint retrospective is the meeting at the end of each sprint where the team looks at how the sprint actually went — what helped, what hurt, what to change — and commits to specific improvements before the next one starts. In Scrum it's the last event of the sprint, after the review and before the next planning.
A working agenda (45–60 minutes)
-
1
Set the stage (5 min). Revisit the last retro's action items first — out loud, with statuses. If this step embarrasses the team every sprint, that's the signal worth discussing.
-
2
Gather what happened (15 min). Collect cards in whatever format fits — Start / Stop / Continue is the default for a reason. Ground claims in what the sprint actually produced: merged work, threads, incidents.
-
3
Group and vote (10 min). Cluster cards into themes and dot-vote. Discuss the top two or three — not everything.
-
4
Decide and own (15 min). Each theme discussed becomes at most one or two actions — each with a named owner and a check-in point. An action nobody owns is a wish.
The cadence is the point — and the trap
Because sprint retrospectives happen every one or two weeks, they compound: small process fixes stack up sprint over sprint. But the same cadence is why they decay — when retro #14 feels like retro #13, teams go through the motions. The fix isn't a novel format. It's continuity: knowing what was decided last time, whether it happened, and whether the same theme is back again. (For the practice beyond the sprint cadence, see the agile retrospective guide ; for fresh formats, the templates library .)
Turn sprint retrospectives into continuous team improvement
SmartRetro runs the agenda above and owns the parts humans forget: last sprint's action items open the retro with live statuses, discussion starts from evidence gathered between sprints, and repeat themes arrive labeled with their history. It's a retrospective tool built so the loop — not the meeting — is the unit of improvement. See how the AI side keeps it evidence-first.