What is a sprint retrospective — and what it should actually produce.
Short answer
A sprint retrospective is a meeting held at the end of each sprint where the team reflects on how they worked together and identifies specific improvements to make in the next sprint. It is one of the four Scrum ceremonies, runs 30–60 minutes for a 2-week sprint, and should end with 1–3 concrete action items with named owners — not a general discussion with no follow-through.
The sprint retrospective (often shortened to "retro") is defined in the Scrum Guide as a time-boxed meeting that occurs after the sprint review and before the next sprint begins. The Scrum Guide allows up to 3 hours for a 1-month sprint; most 2-week sprint teams run 45–60 minutes.
Purpose. The retro has one job: improve how the team works. Not what they built (that's the sprint review). Not what went wrong with the product (that's product management). How the team collaborated, communicated, and executed — and what they'd do differently.
The Scrum definition. The sprint retrospective inspects the last sprint regarding people, relationships, process, and tools. It identifies improvements that the team can put into practice in the next sprint. The Scrum Master encourages improvement within the Scrum process framework.
Common formats.
- Start/Stop/Continue — three columns, 5 min silent writing, cluster, discuss, action items. The most common format for Scrum teams.
- 4Ls (Liked, Learned, Lacked, Longed For) — adds depth for teams in a knowledge-heavy sprint.
- Mad/Sad/Glad — emotional framing, useful after a difficult sprint.
- DAKI (Drop, Add, Keep, Improve) — preferred by engineering-heavy teams.
What a retro is not. A retrospective is not a complaint session (no action items = no retro). Not a planning meeting (that's sprint planning). Not a performance review. The Scrum Master's job is to keep it focused on process and team dynamics, not individuals.
The most important output. 1–3 action items. Each action item must be: specific, owner-assigned, and testable in the next sprint. "Improve communication" is not an action item. "Add a 10-minute async status update to Slack by 9am each day, starting Monday" is. Teams that leave retros with vague agreements see no improvement; teams that leave with specific behavior changes do.
Frequency. Every sprint. The most common mistake is skipping retros when the sprint goes badly — that's exactly when they're most needed. Teams that run consistent retros, even short ones, improve measurably faster than teams that run them sporadically.
Sprint retros happen at whiteboards. Snap the board with BoardSnap when you're done — the AI reads the sticky note clusters, vote dots, and action items and produces a clean retro summary with a tri-state action list.
Frequently asked
Is a sprint retrospective the same as a sprint review?
No. The sprint review is a meeting where the team demos completed work to stakeholders and collects feedback on the product. The sprint retrospective is internal — the team inspects how they worked together, not what they built. Both happen at the end of the sprint, typically on the same day: sprint review first, then retrospective.
Who attends the sprint retrospective?
The Scrum team: developers, the Scrum Master, and the Product Owner. External stakeholders typically do not attend — the retro is an internal team conversation about process. The Scrum Master facilitates; the Product Owner participates as a team member, not a manager.
How long should a sprint retrospective be?
The Scrum Guide caps it at 3 hours for a 1-month sprint. For 2-week sprints, 45–60 minutes is standard. For 1-week sprints, 30 minutes. Don't let it run long by default — a focused 45-minute retro with 3 action items beats a 2-hour discussion with none.
See it work in ten seconds.
BoardSnap is free on the App Store. Snap a board — get a summary and action plan.