How to run a sprint retrospective that actually changes something

Sprint retrospectives fail the same way. Twelve people in a call, three sticky-note columns ("what went well / what went badly / what to try"), forty minutes of venting, one action item that nobody owns, and back to work. Six weeks later the same complaints resurface. The format is not the problem. The wiring around the format is.

The format

We run a 45-minute retro at the end of every two-week cycle. It has four blocks:

1. Silent write — 8 minutes. Everyone drops observations into a shared Notes doc, tagged as fact / feeling / question.
2. Cluster — 5 minutes. The facilitator groups observations into three themes. No discussion yet.
3. Discuss — 20 minutes, capped. Themes get talked through in order of upvotes. Time is enforced.
4. Commit — 12 minutes. We pick exactly two changes for the next cycle, each with a named owner and an exit criterion.

The questions we ask

The prompt drives the quality of the input. We rotate through three prompt sets across quarters to keep it fresh:

• Went well / went badly / try next — the classic. Good for teams new to retros.
• Continue / stop / start — sharper. Forces a decision instead of a list.
• Where did we lose time? Where did we save time? — most useful for engineering teams past the first year.

The commit block is the whole point

Every action item needs three things or it does not exist: a named owner, an exit criterion, and a review checkpoint in the next retro. If the team cannot name those three things in the 12-minute commit block, the item is not ready — park it, and either sharpen it before the next retro or drop it. Vague action items are how retros become theater.

Wiring it into Plan

Every action item becomes a Plan issue in the next cycle. The retro doc auto-links to those issues. At the next retro, the first slide is "how did last cycle’s two changes land?" — accountability by design, not by memory.