The real reason retros fail

I've talked to probably fifty PMs and engineering managers about retros in the last year. The sentiment is almost uniform: "We do retros, but I'm not sure they change anything."

Here's what I think is actually happening.

### What retros are supposed to do

A sprint retro — done right — produces three things:

1. A diagnosis of what went well and what didn't in the last sprint.
2. A hypothesis about what to try differently.
3. A commitment — usually 1–3 specific behavioral changes to try in the next sprint.

Most retros do a good job on #1. Teams can identify problems. The facilitation format (Start/Stop/Continue, 4Ls, Mad/Sad/Glad) helps generate the raw material.

Most retros do an okay job on #2. They cluster the problems and surface patterns. "We keep getting interrupted by urgent requests" is a real hypothesis about a real problem.

Most retros fail completely on #3.

### Why #3 fails

The commitment problem comes in two forms.

Form 1: The commitment is vague. "Improve our communication" is not a commitment. It's an aspiration. You can't check off "improved communication" in the next sprint retrospective. Nobody knows what done looks like. The commitment evaporates the moment the room empties.

Form 2: The commitment is specific but disconnected. The retro produces a specific commitment: "Limit unplanned work to 20% of the sprint." Good! Specific, measurable. But then the meeting ends, and the commitment lives only on the whiteboard. The sprint planning session happens the next morning, and nobody references the retro output. The commitment doesn't make it into the sprint plan because it's in marker on a board in a room that's been rebooked.

Both failures have the same root: the output of the retro is locked on the whiteboard. It doesn't flow into the work.

### The format gap

This is the same output gap I write about everywhere, but it's especially acute for retros because the retro's job is explicitly to change behavior in the next sprint. If the output doesn't connect to the next sprint, the retro is literally producing nothing durable.

The typical retro output: a photo of a whiteboard, sent to Slack, seen briefly, never opened again.

The typical next sprint: starts fresh, with no reference to what was decided in the retro.

Two weeks later, the same problems appear. The team runs the same retro. The cycle repeats.

### What actually breaks the cycle

Three things:

1. Capture the output immediately. Don't let the board die in the room. Snap it before you leave. BoardSnap turns the whiteboard into a clean list of action items — including the commitments — within ten seconds.

2. Connect the retro output to sprint planning. This is the hand-off that most teams skip. The retro ends. Sprint planning starts the next morning (or Monday). Someone — the PM, the scrum master, whoever — needs to bring the retro output into that planning session. Not the photo. The extracted commitments, in a format the room can reference.

3. Make commitments explicit and owned. "Limit unplanned work to 20%" is better with an owner: "Sarah is tracking unplanned work requests during the sprint and flagging anything that would push us over 20%." Now it's a task, not an aspiration.

BoardSnap helps with steps 1 and 2. Step 3 is still a facilitation skill. But you can't fix a facilitation problem if the output of the facilitation never makes it out of the room.

### The metric that tells you if retros are working

The simplest leading indicator: are the commitments from last retro referenced at all in the next retro?

If yes — if the team can actually say "we tried X, here's what happened" — the retro is working. Even if X failed, the feedback loop is intact.

If no — if the next retro starts fresh with zero reference to what was decided two weeks ago — the retro is theater. The discussion is real, but nothing is changing.

Start there. Snap the board. Bring the commitments into the next sprint. Repeat until the loop closes.