Retrospectives That Actually Change Something
The Sprint Retrospective is the last event in the Sprint and, according to the Scrum Guide, exists for one purpose: to plan ways to increase quality and effectiveness. The whole Scrum Team inspects how the last Sprint went — people, interactions, process, tools, Definition of Done — and decides what to improve. It is not a complaint session and it is not a status update. It is where a team gets better on purpose.
Yet many teams run retrospectives that feel pleasant and change nothing. People share, nod, and the next Sprint looks exactly like the last. With so many teams working remotely in early 2021, that drift is easy: a video call can produce agreement without producing action. The fix is not a fancier format — it is treating the outcome, not the conversation, as the point.
Why good retrospectives fail to stick
Too many improvements at once. A team leaves with eight action items, owns none of them, and carries all eight into the next retrospective unchanged.
No owner and no due date. 'We should improve our testing' is a wish, not a commitment.
The same loud voices set the agenda while quieter members — often the ones closest to the problem — stay silent, a real risk over video.
Actions live in someone's notebook instead of the Sprint Backlog, so they never compete for real capacity.
A simple structure that works
Set the stage. Remind everyone the goal is improvement, not blame, and that what's said stays constructive. Two minutes of psychological safety pays for itself.
Gather the data. Surface what actually happened this Sprint — facts, events, feelings — before anyone interprets. Silent written input first helps quieter and remote members contribute equally.
Generate insight. Look for patterns and root causes. Don't stop at 'the build broke'; ask why it broke and why nobody noticed for a day.
Decide what to do. Pick one or two changes the team genuinely commits to, each with an owner. Fewer, real changes beat a long wish list.
Close. Briefly confirm the commitments and, occasionally, reflect on the retrospective itself — is the format still serving you?
Make the improvement real
The most important habit a new team can build is to put each chosen improvement into the Sprint Backlog for the upcoming Sprint, the same way you'd treat any other work the team has committed to. That single move forces the team to allocate capacity to it rather than hoping it happens in the cracks. The Scrum Guide explicitly encourages tackling improvements as soon as the next Sprint.
Keep retrospectives short, regular, and honest. Limit yourself to changes the team controls — improving your own handoffs, not waiting on a reorganization. And revisit last Sprint's commitments at the start: did we do what we said? Nothing builds trust in the event faster than seeing a past decision actually take effect, and nothing kills it faster than the same problem appearing for the fourth Sprint running.
If your delivery teams hold retrospectives that never quite turn into change, XNM's program & project delivery advisory can help you turn reflection into measurable improvement.