Sprint review vs retrospective is one of the most commonly confused distinctions in Scrum — not because the ceremonies are similar in format or purpose, but because they occur in close temporal proximity at the end of each sprint and are both labelled as “reflective” activities. In reality, the sprint review and sprint retrospective serve completely different purposes, involve different participants, produce different outputs, and fail in completely different ways when poorly facilitated. Confusing or conflating them — running a sprint review that turns into a retrospective, or a retrospective that reviews product decisions rather than team process — is one of the most frequent Scrum implementation problems, producing ceremonies that neither inspect the product effectively nor improve the team process systematically. This guide provides the definitive distinction and the best practices for making each ceremony genuinely valuable.
The Sprint Review: Inspecting the Product
The sprint review is a Scrum event held at the end of each sprint in which the Scrum Team and key stakeholders inspect the work completed during the sprint and adapt the product backlog based on what was learned. It is a working session — not a one-way presentation or status report — in which the team demonstrates the increment (the working software, delivered content, or other tangible product of the sprint), stakeholders provide feedback on what they see, and the Product Owner synthesises that feedback into backlog adjustments for the next sprint.
The sprint review has a specific participant list: the entire Scrum Team (developers, Scrum Master, and Product Owner) plus invited stakeholders whose feedback is relevant to the product direction. This stakeholder-inclusive character is one of the sprint review’s most important features — it creates the direct feedback loop between product development and product consumers that enables genuine empirical product management. Sprint reviews attended only by the team, without real stakeholder participation, are team demonstrations to themselves — missing the external feedback that makes the event valuable.
What the Sprint Review Covers
The sprint review typically covers: what was planned for the sprint and what was actually completed (and why any planned items were not completed); a demonstration of the completed increment against the Definition of Done; stakeholder questions and feedback on the demonstrated work; discussion of the product backlog in light of current business conditions, market feedback, and stakeholder input; and updated thinking on the product roadmap and upcoming sprint priorities based on what was learned. Critically, the sprint review does not address how the team worked — process, collaboration, and team health are the retrospective’s domain. Mixing the two produces an unfocused session that serves neither purpose well.
The Sprint Retrospective: Inspecting the Process
The sprint retrospective is a Scrum event held after the sprint review in which the Scrum Team inspects how the last sprint went with regard to individuals, interactions, processes, tools, and the Definition of Done — and identifies actionable improvements for the next sprint. Unlike the sprint review, the retrospective is a closed meeting: only the Scrum Team (developers and Scrum Master, and typically the Product Owner) participates. Stakeholders, managers, and external parties are excluded because their presence changes the team dynamics in ways that inhibit the candour and psychological safety that effective retrospectives require.
The retrospective’s purpose is not emotional expression or team bonding — though both can occur — but continuous process improvement. The Scrum Guide is explicit: the most important output of a retrospective is at least one actionable improvement that the team commits to implementing in the next sprint. Retrospectives that produce no committed actions are feel-good conversations masquerading as process improvement activities.
“The sprint review asks ‘did we build the right things?’ The retrospective asks ‘did we build things the right way?’ Both questions are essential for a team that wants to improve both what it delivers and how it delivers it.” — Ken Schwaber, co-creator of Scrum
Retrospective Formats and Techniques
Effective retrospectives use structured formats that guide the team through a progression from data gathering to insight to action. The most widely used formats include:
- Start/Stop/Continue: What should we start doing? What should we stop doing? What should we continue doing? Simple, fast, and appropriate for teams new to retrospectives.
- 4Ls (Liked/Learned/Lacked/Longed For): A slightly richer framework that captures both positive and developmental feedback in four distinct categories.
- Mad/Sad/Glad: An emotion-based format that surfaces team feelings about the sprint before moving to analytical discussion — valuable for teams where emotional context is affecting team dynamics.
- Sailboat: A visual metaphor where the team identifies winds (what’s helping), anchors (what’s slowing them down), rocks ahead (risks), and the destination island (the sprint goal). Effective for visual thinkers.
- 5 Whys on a specific issue: When a specific recurring problem is identified, applying the 5 Whys technique within the retrospective produces the root cause analysis that prevents superficial action items.
Common Failure Modes
Sprint reviews fail most commonly by becoming passive presentations without genuine stakeholder engagement, by running without real stakeholder attendance, and by drifting into retrospective discussion (process and team dynamics) that displaces product feedback. Sprint retrospectives fail most commonly by producing vague actions without owners or timescales, by becoming complaint sessions without the root cause analysis that generates actionable insights, and by failing to follow up on previous sprint’s retrospective actions — the single most demoralising retrospective failure mode, signalling that retrospective outputs are performative rather than genuine.
Sprint Review vs Retrospective Quick Reference
| Dimension | Sprint Review | Sprint Retrospective |
|---|---|---|
| Focus | Product increment quality and direction | Team process and collaboration quality |
| Participants | Scrum Team + stakeholders | Scrum Team only |
| Output | Updated product backlog | Committed process improvement actions |
| Timebox | 1 hr per sprint week | 45 min per sprint week |
| Failure mode | Demo without stakeholder engagement | Actions without owners or follow-up |
Key Takeaways
- The sprint review inspects the product — it involves stakeholders, demonstrates the increment, and produces backlog updates based on stakeholder feedback.
- The sprint retrospective inspects the team process — it is a closed Scrum Team session that produces committed improvement actions for the next sprint.
- Both are inspection and adaptation events, but they adapt different things: the review adapts the product direction; the retrospective adapts the delivery process.
- The sprint review’s most common failure is running without real stakeholder participation; the retrospective’s most common failure is producing actions without owners, timescales, or follow-up.
- Retrospective actions from the previous sprint must be reviewed at the start of the next retrospective — failing to follow up on committed actions is the single most demoralising retrospective failure pattern.
- Mix retrospective formats across sprints to maintain engagement — Start/Stop/Continue for new teams, 5 Whys for deep dives on recurring problems, Sailboat for visual teams, and 4Ls for richer categorised reflection.
