How do you run a sprint retro that actually changes something?
A useful retrospective produces 2 concrete actions max, with an owner, deadline and "done" criterion — and verifies at the next retro what happened with the previous actions. Without follow-through, a retro is just therapy.
Most sprint retrospectives are dead rituals. The team lists 20 issues, writes "communicate better", everyone leaves, and 2 weeks later the same list reappears. A useful retro produces concrete actions and verifies follow-through — otherwise it is just collective venting hour.
1. Start by checking previous actions
First item on the agenda: what happened to the actions from the previous retro? Each action has a status: Done, In Progress, Dropped (with a reason). That tells you immediately whether the retro produces results or not.
If 80% of previous actions went nowhere, stop the retro and discuss: why did we not deliver? No time? Badly defined actions? No management buy-in? Fix the cause, do not generate more actions.
2. A clear format, not free brainstorm
The classic "Start / Stop / Continue" or "Glad / Sad / Mad" formats work. Free brainstorm ("what bothers you?") without structure fails — either no one speaks, or vocal members dominate, or the discussion tunnels into a single issue.
Change the format every so often to avoid ritualisation. Every 3-4 sprints, try "Sailboat" (wind = what propels us, anchors = what holds us back) or "4Ls" (Liked / Learned / Lacked / Longed for). New format = new perspectives.
3. Maximum 2 concrete actions per retro
A team cannot improve 10 things at once. Pick at most 2 actions, each with: a clear owner (one person, not "the team"), a deadline (an exact date, not "soon"), and a definition of "done" (how do we know it happened).
Bad example: "Communicate better in the sprint." Good example: "Maria writes a daily status in the sprint task comments at 5pm starting Monday; at the next retro we check whether the team feels it helps." Concrete, ownership, deadline, success criterion.
4. Focus on the system, not the people
"X delivered late" is unproductive. "The sprint delivered late because the dependency between tasks A and B was not clear at planning" is actionable. Attack the process, not the individual.
The exception: if patterns of problematic behaviour repeat, the conversation has to happen — but 1-on-1, not in the retro. Retro is not the place for individual evaluation. Use direct feedback or performance reviews for that.
5. Psychological safety — without it the retro is theatre
If the team does not feel safe saying "this scope was unrealistic", the retro produces only harmless items. If the PM or tech lead reacts defensively to criticism, the team quickly learns to swallow feedback.
The retro facilitator (Scrum Master or rotating) has an explicit role: create the space. Anonymous brainstorm in the first 5 min, the "do not interrupt" rule, no management presence at a technical retro — all of these matter. Without safety, the retro is just a ceremony you check off.
Retro with follow-through in 4myprojects
Retro actions become real tasks, with an owner, a priority and a "retro" label, attached to the next sprint — two weeks later you open them filtered by that label and see in black and white what you never closed.