Sprint review and retrospective: closing the loop

Sprint Review and Sprint Retrospective happen back-to-back at the end of a sprint, which makes it easy to blur them into one event — but they inspect two entirely different things, and collapsing them loses real signal from both:

The single most common way Sprint Review degrades: it becomes an internal show-and-tell for the team and maybe a manager, with no actual stakeholders or users present who could give feedback that changes anything. A demo with no one in the room who can say "actually, that's not quite what we needed" or "oh, that changes what we should build next" isn't a review — it's a status update wearing a review's name. The entire value of the event is the conversation it creates about what to do next, based on what stakeholders now understand having seen real, working software — not the demo itself.

A working Sprint Review:

A retrospective that produces the same generic action items sprint after sprint ("communicate better," "write more tests") without anything actually changing afterward has become theater — the team goes through the motions of reflecting, without the reflection having any real consequence. Two things usually cause this:

Common alternatives to the plain three-question format, chosen based on what actually happened that sprint:

Whichever format, the output that matters is a small number of specific, owned, checkable action items — not a long list nobody's actually accountable for. Two well-defined changes someone commits to trying, checked at the start of the next retro, beat eight vague aspirations that quietly evaporate.

A retrospective only surfaces real information if people feel safe naming what actually went wrong, including their own mistakes, without it being used against them later. A retro where a team member is criticized (even subtly) for admitting a mistake teaches everyone present to stop admitting mistakes — which doesn't make the mistakes stop happening, it just makes them stop being visible to the team, which is strictly worse. The Scrum Master's actual job during a retro is protecting that safety, not driving toward a predetermined list of action items.