Sprint retrospective template: a format that produces changes, not feelings

A sprint retrospective template is a fixed structure for the meeting a team holds at the end of an iteration to decide what to change about how it works. The template matters less than the ending: a retrospective that produces discussion and no committed change is a well-attended waste of an hour, and most of them are.

The classic three-column format — what went well, what did not, what to try — is fine as a starting point and is where nearly every team begins. It also degrades in a predictable way, which is worth understanding before you adopt it permanently.

A sprint retrospective template that ends in commitments

• One line of context: the sprint dates, what was planned, what shipped.
• Data before opinion — completed items, carried-over items, incidents, anything measured. Five minutes, no discussion.
• What went well, gathered individually and in silence before anyone speaks.
• What got in the way, gathered the same way.
• Grouping and a quick vote to find the two or three themes worth the remaining time.
• Discussion of those themes only, with a timebox each.
• Actions: at most three, each with a named owner and a date.
• Review of the actions from last time, at the top of the next retrospective.

Collecting items silently before discussion is not a facilitation flourish. It stops the first person who speaks from setting the frame, and it gets the quieter half of the team into the record — which is usually where the specific, actionable observations are.

Why three actions and not fifteen

Retrospectives fail far more often from over-production than from under-production. A team lists eleven improvements, everyone agrees they are all sensible, nobody owns any of them, and two weeks later the same eleven are listed again. The second occurrence is what teaches people the meeting does not matter.

Capping the output at three, with owners and dates, is what converts the meeting into a change mechanism. Anything that does not make the cut is not lost — it will come back next time if it is still hurting, and if it does not come back it was not worth doing.

Rotating the format

The three-column format goes stale after roughly ten uses. People start writing the same cards, and the meeting becomes a ritual with a known script. Rotating the question fixes this cheaply.

1. Run the standard format for the first several sprints, until the team is comfortable with the rhythm.
2. Swap the prompts periodically: start / stop / continue, or glad / sad / mad, or a timeline of the sprint with events marked.
3. Occasionally pick one theme and spend the whole hour on it rather than surveying everything.
4. After an incident, run a blameless review instead — different meeting, different rules.
5. Every few months, retrospect the retrospective: are the actions actually happening?
6. Keep the closing step identical whatever the format — at most three actions, owners, dates.

Psychological safety is the precondition

A retrospective only surfaces the real problems if saying them is safe. Where a manager is present and defensive, or where naming a process failure is heard as naming a person, the meeting produces bland cards about better communication and everyone knows it. Nothing in a template fixes that, and it is worth being honest that the format is the easy part.

The practical signals are simple: does anything uncomfortable ever get raised, do actions ever concern how management works rather than only how the team works, and does anyone ever say they were wrong. If none of those happen for several sprints, the meeting is theatre regardless of how well it is run.

Teams that run no sprints at all still need the work visible. How to set up a kanban board for a small team covers the columns, the limits on each one and who is allowed to move a card.

Keeping the record

The retrospective needs two things to persist: the actions, so they can be checked, and enough of the notes to recognise a recurring theme. Ettex Board suits the first — each action becomes a card with an owner and a due date on the same board as the rest of the work, which is the only reliable way to stop retrospective actions being a separate list nobody looks at.

There is no built-in retrospective mode: no anonymous card collection, no dot-voting widget, no timer. Cards get written in the meeting by whoever is facilitating. For a team that wants anonymity in particular, a dedicated retro tool does that better, and we would rather say so than pretend otherwise.

A retrospective still needs a simple meeting agenda — a timebox per section and a stated purpose — or it drifts into a status update. The actions only survive if they are visible somewhere the team already looks. A retrospective whose commitments live in a document nobody reopens produces the same three problems next month; the same actions on the board next to the sprint work get done or get consciously dropped, which is also an outcome.

Collect silently, look at data before opinions, discuss two or three themes, and leave with three owned actions. Then open the next retrospective by checking them.