Sprint Retrospective Template — 60-Minute Agenda & Free Formats

The retrospective is the meeting held at the end of every sprint where the team inspects how it worked — not what it built. The sprint review shows stakeholders the product; the retrospective is the team-only look at process: individuals, interactions, tools, and the Definition of Done. The Scrum Guide timeboxes it at three hours maximum for a one-month sprint, scaled down proportionally for shorter sprints, and its output is one to three concrete improvement actions carried into the next sprint backlog.

A practical rule of thumb: about 30 minutes of retro per week of sprint — 30 to 45 minutes for a one-week sprint, 60 to 90 for two weeks, around two hours for a month. The Scrum Guide sets a hard ceiling of three hours for a one-month sprint. Teams with strong retro habits often finish in 45 because they move quickly from data to insight to action; if your retro regularly needs its full timebox, that is usually a signal of unresolved recurring issues, not a reason to book more time.

The classic five-phase structure from Esther Derby and Diana Larsen's Agile Retrospectives: set the stage (check-in, ground rules), gather data (silent writing on what happened), generate insights (group items into themes and vote), decide what to do (agree on one to three owned actions), and close (confirm commitments and appreciate contributions). For a two-week sprint this fits comfortably in 60 minutes: 5, 10, 15, 20, and 5 minutes respectively, plus 5 minutes up front to review the previous retro's action items.

There is no single best one — match the format to the moment. Start/Stop/Continue for new teams or a fast, low-friction session. 4Ls (Liked, Learned, Lacked, Longed for) after a milestone or a high-stakes sprint, because the Learned column captures reflection other formats skip. Sailboat for visual teams that need to look forward (wind, anchors, rocks, island). Mad/Sad/Glad after a rough sprint or incident when emotions need naming first. DAKI (Drop, Add, Keep, Improve) for mature, process-focused teams. Strong facilitators rotate formats rather than committing to one forever.

First, check the follow-through, not the format: action items that quietly die between sprints guarantee the same conversation every time. Review last retro's actions in the first five minutes — if they did not happen, ask why before generating new ones. Second, recurring themes are usually systemic, so discuss root causes rather than individual incidents. Third, if actions genuinely get done and the board still repeats, switch formats — a fresh lens like Sailboat or 4Ls can surface what Start/Stop/Continue has stopped revealing.

Three parts: a specific, concrete change (not "communicate better"), one named owner (not "the team"), and a date by which it will be done or reviewed — for example, "add a 15-minute async update to the team channel every Friday, owner Alex, starting Friday." Cap the output at one to three actions per retro so they fit in the next sprint backlog, and read them back before closing. At the start of every retro, spend five minutes reviewing whether the previous items happened — that single habit matters more than any format choice.

The whole Scrum team: developers, the Product Owner, and the Scrum Master. Stakeholders, managers, and observers stay out — psychological safety is the mechanism that makes retros work, and people speak plainly when attendance is team-only. If leadership wants the output, share the themes and action items, not the raw discussion. For the manager equivalent with no team present, that is what skip-level meetings are for.

Norm Kerth's one-sentence framing, read or restated at the start of a retro: "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." It establishes the blameless premise — the retro examines how the system of work failed, not who failed. Facilitators open with it because it gives quieter team members permission to name problems without framing anyone as the problem.

The review looks at the what: the increment is demonstrated to stakeholders and the Product Owner, and the backlog is adjusted. The retrospective looks at the how: the team alone inspects its own process and picks improvements. They close the sprint back-to-back — review first, then retro — and mixing them is the fastest way to lose both: stakeholder demos crowd out process talk, and process talk bores stakeholders.

Yes — and locally, which matters for a meeting whose value depends on candor. VocalFuse transcribes your microphone on your Windows PC with Whisper: no meeting bot joins the call, no audio is uploaded, and it works in Zoom, Teams, Meet, or a physical team room. Pro Note Turning drafts the notes into this template's structure — themes, action items with owners — and you verify and approve before anything is shared.