What is a Sprint Retrospective?

A sprint retrospective (or just "retro") is a recurring team meeting — usually held at the end of each sprint — where the team inspects how they worked together and agrees on concrete improvements for the next iteration. Where sprint planning looks forward at the work, the retro looks back at the process: what helped, what hurt, and what the team wants to change. Retrospectives are one of the original practices of agile software development — the twelfth principle of the Agile Manifesto is literally "at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." A team that ships every sprint but never reflects tends to repeat the same friction sprint after sprint.

Good retros run on psychological safety, and most facilitators anchor that with Norm Kerth's "prime directive": regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. That isn't naïve optimism — it's a working agreement. The retro examines the system the team works in, not the people. The moment a retro turns into blame, people stop writing honest cards, and the meeting loses its value.

1. Write cards privately. Each person adds their observations to the board — typically sorted into "went well", "didn't go well", and "to improve". Cards stay hidden from teammates at this stage for the same reason planning poker reveals estimates simultaneously: seeing other people's cards first anchors your own thinking. 2. Reveal. The facilitator flips the board and everyone reads the cards together. Duplicate observations are a signal, not noise — three people writing the same card independently tells you where the real friction is. 3. Dot vote. Each person gets a small budget of votes (three is typical) to spend on the cards they most want to discuss. Voting before discussing keeps the conversation on what the team cares about rather than whoever speaks first or loudest. 4. Discuss and agree actions. Work through the top-voted cards and turn the discussion into specific action items with a single owner each. End the retro by reading the actions back.

Went well 😊 Not padding — knowing why something worked lets you do it on purpose next sprint instead of by accident. If the new deploy script saved the team a day, say so, and keep it. Didn't go well 😕 Events and friction from the sprint: the flaky test suite, the surprise scope change, the three days lost to an environment problem. Describe the problem, not the person. To improve 💡 Proposals — things the team could try next sprint. The best cards here describe recurring patterns rather than one-off incidents: one bad deploy is an event, the third in a month is a system worth fixing.

• Review last retro's actions first — nothing kills retros faster than actions that vanish. Opening with a check on the previous actions proves the meeting has teeth. • Timebox each phase — five minutes of focused card-writing beats twenty of drifting. A visible countdown keeps things moving without the facilitator nagging. • Keep actions small and owned — "improve communication" never happens; "Alex sets up a shared deploy channel by Friday" does. One owner and one deadline per action. • Limit the action list — two or three actions that actually happen beat ten that don't. Anything more belongs in the backlog. • Include everyone — QA, design, and ops see friction developers don't. A retro of only developers fixes only developer problems. • Rotate the format occasionally — the three-column board is the workhorse, but an occasional change of framing (start/stop/continue, sailboat) surfaces different observations.

• The blame retro — cards name people instead of problems. Re-anchor on the prime directive and rewrite the card as a description of the system. • The venting retro — an hour of complaints, zero actions. Venting has value, but cap it; the deliverable is the action list. • The manager-dominated retro — if the loudest voice in the room controls the discussion, dot voting and hidden card-writing are your structural defences. • The groundhog-day retro — the same three complaints every sprint with no follow-through. That is not a retro problem; it is an action-item problem. Make actions smaller until they start happening. • Skipping it when busy — the sprints where the team is too busy for a retro are exactly the sprints that most need one.

Distributed teams need a shared board more than co-located ones — you can't cluster sticky notes on a wall over a video call. An online retro board gives everyone the same view: private card-writing, a simultaneous reveal, dot voting, and a shared action list, with a timer to keep each phase honest. Scrum Points includes a free retro board that does exactly this — no accounts, no setup, just a room code to share.

A retro that surfaces twenty observations and tries to address all of them addresses none. Dot voting is the cheapest way to narrow the list without the loudest voice deciding: each participant gets a fixed number of votes — three is the usual default — and spends them on the cards they most want the team to act on. A few details make it work better in practice. Let people stack multiple votes on one card if they feel strongly, so intensity shows up alongside breadth. Vote after the cards have been read and clarified but before discussion, so the conversation is spent on what the team actually cares about. And resist the urge to discuss the top item at length before checking the second and third — the ranking is more informative as a whole. Two or three topics is a realistic ceiling for a one-hour retro. Anything below the cut is not lost; it stays in the record and usually reappears if it genuinely matters.

The most common way a retrospective fails is not a bad discussion — it is a good discussion that produces nothing. Teams generate a list of well-meant intentions, nobody owns them, and the same items reappear three sprints later. What separates an action item that happens from one that does not: • One named owner. Shared ownership reliably means nobody. • Small enough to finish inside the next sprint. "Improve our testing culture" is a wish; "add a smoke test to the deploy pipeline" is an action. • Visible where the work is. An action item that lives only in the retro notes competes with the backlog and loses. • Reviewed at the start of the next retro. Five minutes checking what happened does more for follow-through than any amount of enthusiasm at the time. • Capped at two or three. A team that commits to eight improvements delivers none of them and learns that retro commitments are theatre. If an item has carried over twice, that is information in itself — either it is not actually important, or something is blocking it that the team has not named.

Went well / did not go well / to improve is the sensible default and works indefinitely. But a team running the same format every two weeks for a year will start producing the same cards out of habit, and varying the prompt is a cheap way to shake loose things the usual columns miss. • Start / Stop / Continue — sharpens the focus onto behaviour changes rather than observations. • Mad / Sad / Glad — surfaces how people felt about the sprint, which the neutral framings tend to flatten out. • Sailboat — wind, anchors, rocks, destination. Good for a team that needs to talk about direction rather than process. • Timeline — plot the sprint chronologically and mark the highs and lows. Effective after a sprint that went badly, because it separates what happened from how it felt afterwards. • Four Ls — liked, learned, lacked, longed for. Useful at the end of a project or a quarter. Whatever the prompt, the mechanics that matter are the same: write privately first so nobody anchors, reveal together, prioritise, and leave with owned actions.

Every technique on this page assumes people will say what they actually think, and none of them work if they will not. A retrospective in a team where candour has a cost produces bland cards about tooling and process, while the real problems go unmentioned. The structural fixes help — writing privately before revealing means the first card is not the safe one, and it lets someone raise an uncomfortable observation without being the person who broke the silence. But the larger part is what happens afterwards. If raising a problem reliably leads to it being examined rather than defended, people raise more of them. If it leads to someone being blamed, the team learns quickly and the retro becomes a status meeting. This is also the main argument for keeping line managers out of the room, or at least for being deliberate about it. The prime directive is not a platitude; it is a standing agreement that the discussion is about the system rather than the people in it.