What Is a Sprint Retrospective and How to Run One?
A sprint retrospective is a recurring meeting, held at the end of each sprint, where the team reflects honestly on how the sprint went and identifies specific, actionable changes to improve how they work going forward — distinct from a sprint review, which focuses on the product itself rather than the team's process.
Quick facts
- A retrospective focuses on team process and collaboration, not the product's features or backlog.
- The most valuable retrospectives produce a small number of specific, actionable improvements, not just a general discussion.
- See related: What Is Definition of Done in Agile, a concept teams often revisit and refine during retrospectives.
Sprint retrospective vs sprint review
| Sprint Retrospective | Sprint Review | |
|---|---|---|
| Focus | The team's process and how they worked together | The product increment that was built |
| Attendees | The Scrum team (developers, PO, Scrum Master) | The Scrum team plus stakeholders |
| Typical questions | What went well? What didn't? What should we change? | Does this meet expectations? What feedback do we have? |
| Outcome | Specific process improvements for the next sprint | Feedback that may adjust the product backlog |
How to run an effective sprint retrospective
- Set a safe, blame-free tone at the start. A retrospective only surfaces honest input if people feel safe raising real issues without fear of blame — the facilitator should explicitly establish this early.
- Use a structured format, such as "What went well / What didn't go well / What should we change," or a variation like "Start, Stop, Continue," to give the discussion clear structure rather than an open-ended conversation.
- Gather input from everyone, not just the most vocal team members. Techniques like silent brainstorming (everyone writes ideas individually before discussing) help surface quieter perspectives.
- Group similar themes together once individual input is collected, to avoid a scattered list of many small, disconnected points.
- Prioritize and select a small number of specific action items. Trying to address everything raised usually means nothing gets meaningfully improved — picking one or two focused, actionable changes is more effective.
- Assign clear ownership for each action item. An improvement without a specific owner tends not to actually happen.
- Review previous action items at the start of the next retrospective. This closes the loop, showing the team that retrospectives lead to genuine change, not just repeated discussion of the same recurring issues.
Why retrospectives matter
Without a dedicated, recurring space to reflect on process, teams tend to keep repeating the same friction points sprint after sprint — a recurring blocker, a consistently underestimated type of work, or a communication gap that never gets explicitly addressed. A well-run retrospective creates a structured opportunity to name these patterns and commit to specific changes, which is what actually drives continuous improvement over time, rather than hoping things naturally get better.
A worked example
A team's retrospective surfaces a recurring theme: several sprints in a row have included stories that turned out to be much larger than estimated, because they depended on an external team's API that wasn't well understood upfront. Rather than a vague action item like "estimate better," the team commits to a specific change: any story involving an external dependency will include a technical spike to investigate the dependency during backlog refinement, before it's estimated for a sprint. This specific, ownable change is reviewed at the start of the next retrospective to confirm it's actually being followed and helping.
Common mistakes when running retrospectives
- Skipping retrospectives when the team feels busy, losing the opportunity to catch and address recurring friction early.
- Letting the discussion turn into blame rather than a focus on process and system issues.
- Generating a long list of action items without prioritizing, resulting in none of them actually being followed through on.
- Never revisiting past action items, making retrospectives feel like a repeated exercise rather than a genuine driver of change.
FAQ
How long should a sprint retrospective last? Typically 45-90 minutes for a two-week sprint, scaled roughly proportional to sprint length — long enough for genuine reflection, short enough to stay focused and not become a drain on the team's time.
Who should attend a sprint retrospective? The core Scrum team — developers, the Product Owner, and the Scrum Master — since it's focused on how the team works together, rather than broader stakeholder input, which belongs in the sprint review.
What if the same issues keep coming up in every retrospective? This is a signal that past action items aren't being followed through on, or that the issue requires a bigger, more structural change than what's been attempted so far — worth escalating or addressing more directly rather than repeating the same surface-level discussion.
Can retrospectives be skipped if a sprint went well? It's better not to skip them even after a good sprint — retrospectives are also valuable for reinforcing what worked well and should be continued, not just for addressing problems.