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.