Retrospective Template: Five Sections and Action Items That Close

The fourth time I watched the same action item get written on the same board, somebody finally said it out loud: we have agreed to fix this in every retro since March. Nobody could say who owned it, whether anyone had started, or what had happened to the two previous versions of the same commitment. The team was running a disciplined ceremony every two weeks and improving at roughly the rate of a team that held no retros at all.

A retrospective template does not fix that by itself. What it does is force the meeting to start where the evidence is, which is the list of things the team already promised itself, before anyone gets to enjoy the part where they talk about the new sprint. This guide gives you the five sections, a set of retrospective questions that produce real answers, three formats and when each one fits, a sixty-minute agenda, a worked example, and a copy-paste template at the bottom.

What a Retrospective Template Actually Has to Do

A retrospective is the recurring moment when the people who did the work change something about how the next round of it will run. It is about the process, not the product. The output is a small number of written changes that somebody owns.

That is the whole job. Three things it is not, and each confusion produces a different useless meeting:

• It is not a sprint review

  A sprint review shows the work to stakeholders and asks whether it was the right work. A retrospective asks the team how the work went and what to change about the doing of it. Teams that merge them end up with a demo followed by ten rushed minutes of process talk, and the process talk is always the part that gets cut when the demo runs long. Keep them separate even when that means two shorter meetings.

• It is not a blame session

  The moment a retro becomes a search for who caused the problem, everyone in the room starts optimizing for not being named, and the interesting failures stop being reported. This is not a soft concern about feelings. It is the mechanism by which a team loses access to its own information. Describe events and systems rather than people, and note that a facilitator who lets one person be cornered has cost the team more than one meeting.

• It is not a feelings check with no output

  The opposite failure is just as common. Everyone shares, the mood improves, the board fills with sticky notes, and nothing is different next sprint. A retro that consistently produces no change is a recurring hour that the team eventually starts protecting itself from. If the last three retros produced no completed action, the meeting has become theater and the honest move is to say so in the fourth one.

The Sprint Retrospective Template: Five Sections

Five sections, in this order. The order carries most of the value. Last retro's commitments sit above everything else because a team that reviews its own follow-through behaves differently from one that does not, and the action items sit at the bottom because they should be shaped by what the middle three sections actually surfaced rather than decided in advance.

1. 1

   1. Header, and last retro's action items with their real status

   The sprint, the dates, who is present, and who is facilitating. Then the previous retro's action items, each marked done, dropped, or still open, read out loud. Dropped is a legitimate answer and it should be said rather than quietly allowed to expire. This section takes five minutes and it is the single highest-leverage part of the template, because it is the only mechanism that makes the rest of the meeting consequential.

2. 2

   2. What went well

   Not a morale exercise. The purpose is to identify what to deliberately keep doing, because practices that work tend to erode silently when nobody names them. Push for specifics: pairing on the migration saved a day is useful, good teamwork is not. Two or three items is plenty, and a sprint where the team genuinely cannot name one is itself a finding worth writing down.

3. 3

   3. What did not go well

   The friction, the waiting, the rework, the thing everyone worked around. Capture events rather than judgments, and resist solving anything yet, because the first proposed solution in a retro is usually a fix for the first symptom mentioned rather than the largest one. The facilitator's job in this section is to keep collecting until the room runs out, not to start triaging on item two.

4. 4

   4. What surprised us

   The section most teams skip and the one that pays best. Anything that turned out differently than expected: an estimate that was wildly off, a dependency nobody knew existed, a bug that had been reported months earlier by a customer and only surfaced now. Surprises are where the team's model of its own work is wrong, and a wrong model produces bad estimates and bad promises for as long as it goes uncorrected.

5. 5

   5. Action items: three at most, each with an owner and a date

   Pick from what the middle sections surfaced, cap it at three, and give each one a named person rather than a team. Vague verbs are the tell of an action item that will not happen. Improve our documentation is not an action item. Ana adds a setup section to the payments README by Friday is. Anything the team wants to fix that does not make the top three goes on a visible parking list rather than into the void.

Retrospective Questions That Surface Something Real

The quality of a retro is mostly set by the quality of its questions. Ask how the sprint went and six people will say fine. Ask something specific enough that answering requires describing an actual event, and the room fills up.

Use four or five, and keep the same set for several sprints so patterns become visible across meetings rather than getting lost in a new format each time.

• Questions about friction

  What was the most frustrating thing you touched this sprint? Where did you wait on something, and how long? What did you have to do by hand more than twice? What did you work around instead of fixing? The waiting question is the highest-yield one in this whole list, because queue time is invisible in every tracker and enormous in most teams.

• Questions about surprises

  What turned out to be much harder than expected, and when did you find out? What did we learn this sprint that we wish we had known at planning? Was there anything in this sprint that had been reported before and nobody knew? The last one tends to be uncomfortable and it is usually the most valuable question on this list.

• Questions about the boundary with other teams

  What did we hand off, and do we know what happened to it? What arrived from support or sales without enough information to act on? What are we waiting on from another team right now? Cross-boundary work is where retro action items go to die, so it is worth surfacing deliberately rather than hoping it comes up.

• Questions about customers

  What did we ship this sprint that a customer had actually reported? Did anyone tell them? Which of the things we fixed had been sitting in someone's queue for months? Most engineering retros never ask these, and the answer is often that nobody in the room can find out, which is itself the finding.

• Questions for a team that has gone quiet

  If you could change one rule about how we work, what would it be? What did you not say in the last retro? What would make next sprint noticeably better than this one? Use these sparingly. They work when a team has settled into polite agreement and stopped producing anything, and they lose their effect fast if they become the standing set.

A retro built from what people remember produces the loudest problems. A retro built from what the team promised itself last time produces the ones that are actually costing you.

Retrospective Formats: Start Stop Continue, 4Ls, and Mad Sad Glad

The five-section template above is the structure. A format is the prompt set you use to fill sections two through four, and rotating it occasionally keeps a team from answering on autopilot. The three below cover nearly every situation.

The format matters less than people think. A team that runs Start Stop Continue every sprint and genuinely closes its action items will outperform a team that rotates through six creative formats and closes none of them.

The Retro Agenda: Sixty Minutes

Sixty minutes for a two-week sprint. The times below assume a facilitator who is actually keeping time, which is the difference between a retro that ends and one that gets cut off.

1. 1

   0 to 5: last retro's action items

   Read them out with their real status. No discussion yet beyond the status itself. Anything still open goes into the pile for the rest of the meeting to reconsider rather than getting automatically rolled forward, because an item that has survived three sprints untouched is telling you it is not going to happen in its current form.

2. 2

   5 to 15: gather, silently and in writing

   Everyone writes their own items before anyone speaks. Silent writing first is not a ceremony preference, it is what stops the first speaker from setting the frame for the whole room, and it is the single easiest upgrade available to a team whose retros are dominated by two voices.

3. 3

   15 to 30: group and read out

   Cluster the duplicates, then have each person speak briefly to their own items. Duplicates carry information, so note where five people wrote the same thing rather than collapsing it silently to one card. That count is usually a better priority signal than the discussion that follows.

4. 4

   30 to 50: dig into the top two or three

   Vote, then go deep on only the top items. This is where the team is allowed to ask why more than once, and where a recurring theme should be recognized as needing a proper root cause session rather than a twenty-minute guess. Depth on two beats coverage of nine every time.

5. 5

   50 to 60: write the action items

   Owners, dates, and wording specific enough that the person could start tomorrow. Write them in the document while everyone is present. Action items assigned afterward by message have a much lower survival rate than ones somebody agreed to out loud in front of the team.

Retrospective Example: A Sprint With a Bad Week In It

Structure advice is easy to agree with, so here is the shape filled in. Compressed, but the proportions are right. Section one and section five take more room than the went-well column does.

Header. Sprint 34, July 21 to August 1. Present: five engineers, product manager, designer. Facilitator: Priya. Last retro's actions: (1) Ana adds a setup section to the payments README by July 25. Done. (2) Split the deploy check into its own job so it stops blocking the test suite. Still open, third sprint running, owner was written as "platform" rather than a person. (3) Ask support to include the account tier on escalations. Dropped, because nobody followed up and the person who suggested it has left the team.

What went well. Pairing on the webhook rewrite finished it two days early and left two people who understand it instead of one. The new staging data set caught the timezone bug before release rather than after. Both worth keeping, and the pairing one is worth repeating deliberately on the next risky piece rather than hoping it recurs.

What did not go well. The deploy pipeline blocked merges for most of Wednesday. Two tickets came over from support with a screenshot and no reproduction steps, which cost about half a day of back and forth. A bug that shipped on July 29 turned out to have been reported by a customer in April, and nobody in the room knew that until the release notes were being written.

What surprised us. That April report. Three people had touched adjacent code since then without ever seeing it. The support ticket had been closed in April with a note saying it was sent to engineering, and the engineering issue that came out of it was filed without any reference back to the ticket or the customer, so it sat in the backlog as an anonymous low-priority item rather than as something a paying account was waiting on.

Action items. (1) Deploy check moved into its own job. Owner: Marc, by August 12. Note that this is the same item as last retro's number two, now with a person's name on it instead of a team's. (2) Escalations from support must carry reproduction steps and the reporting account, and the linked ticket has to be attached to the issue rather than pasted into a comment. Owner: Priya, with the support lead, by August 8. (3) Before release, check which shipped fixes came from customer reports and tell those customers. Owner: Dan, first run at the next release.

Notice item two of the previous retro. It did not fail because the team lacked discipline. It failed because it was assigned to a word rather than a person, which is a template problem, and this template fixes it in section five.

The Retro Preparation Checklist

Run this before the meeting. It takes about ten minutes and it prevents most of the ways a retro quietly stops being useful.

The sixth item is the one that fails, and it fails for a structural reason rather than a discipline one.

Why Retro Action Items Do Not Close

Sort a year of retro action items by whether they closed and a pattern falls out immediately. The ones that closed were almost entirely inside the team's own control: a script, a checklist, a config change, a rule about pull requests. The ones that appeared three sprints running all crossed a boundary to somewhere the team could not see.

The most common one in a product company is the customer boundary. A team decides it wants to know which of the bugs it fixed had been reported by real customers, and whether anyone told them afterward. Everyone agrees. It is written down. And then it does not happen, because answering it means searching the help desk for closed tickets, reading them, and asking someone whether each one was ever fixed. Half of those tickets end with a note saying the issue was sent to engineering, and that is where the trail stops.

So the engineering issue exists, it shipped in week three, and nothing connects the two records. The action item survives to the next retro as a commitment nobody has the means to keep. That same broken trail is what makes closing the customer feedback loop the step teams skip, and it is why the what shipped section of a QBR is rebuilt by hand every quarter.

The version that works is mechanical, and it depends on a link being recorded at the moment of escalation rather than reconstructed later:

• Attach the reporting account when the issue is filed

  When a support ticket becomes an engineering issue, record the requesting account on that issue right then. It costs nothing in the moment and it converts the retro question from an investigation into a filter. Linear's customer requests model is built on exactly this, and its value only becomes visible a sprint or two later.

• Keep the reporter's own wording

  Export drops the last row on files above ten thousand records is a sentence somebody already wrote. Export bug is what arrives in the tracker after a paraphrase. The specifics are what let a team recognize in a retro that the thing they just fixed had been sitting in the queue since April, and paraphrasing on the way in is what removes them.

• Make the handoff carry reproduction steps

  Two tickets with a screenshot and no steps cost the team in the example above half a day. That is a retro action item with a real fix, and the fix belongs in the triage step rather than in a request for people to try harder. Structure the handoff and the problem stops recurring on the board.

• Close the loop when the fix ships

  A fix that shipped in week three and reached the customer in week twenty was worth a fraction of what it should have been. If the issue carries its reporters, then writing the release notes and telling the affected accounts become the same short job, and next retro's customer question answers itself from work already done.

That table is not really about retrospectives. It is about whether the handoff from support to engineering left a durable trail behind it, and the retro is simply the recurring moment when a team discovers that it did not. The same gap turns up when someone tries to write the problem section of a PRD and cannot reconstruct who asked, and it is why managing feature requests from support to engineering is a process problem before it is a tooling one.

For teams where support runs on HubSpot Service Hub and engineering runs on Linear, IssueLinker is what keeps that trail intact. A ticket becomes a linked Linear issue in one click with the customer's own wording carried over, the requesting account travels with it, and the two stay in sync both ways, so when the fix ships the ticket already knows. The Linear HubSpot integration guide covers how the two-way sync works, and how to get bugs fixed faster covers the handoff itself.

Mistakes That Make a Retrospective Not Worth Attending

Four patterns account for most retros that become fortnightly, then monthly, then quietly cancelled.

• Never revisiting the previous action items

  The fastest way to teach a team that the meeting does not matter. If commitments are made and never inspected, people learn within about three sprints to make agreeable-sounding ones and move on. Reading the list out at the start costs five minutes and it is the entire difference between a ceremony and a feedback loop.

• Nine action items

  A long list feels productive in the room and produces nothing, because nobody can hold nine improvements alongside a sprint of actual work. Three is the ceiling and two is often better. The rest go on a parking list where they stay visible, and the ones that genuinely matter will come back on their own next sprint.

• Owners that are teams rather than people

  Assigning something to platform, or to support, or to us is how an item survives three retros. A team is not a person and cannot be asked on Thursday how it is going. Every action item needs one name, even when the work will obviously be shared, because the name is who notices when it stops moving.

• Solving the first problem mentioned

  The first item raised is the freshest, not the largest, and a room that starts fixing it immediately never gets to the thing that has been costing a day a sprint since March. Collect everything before discussing anything, then vote. The gap between the loudest problem and the most expensive one is where most of the available improvement lives.

The thread through all four is that a retrospective is a commitment device and gets judged as one. The measure is not whether the discussion was good. It is whether anything is measurably different two sprints later, and a team can usually tell you the answer without looking it up.

Copy-Paste Retrospective Template

Here is the template in plain text. Paste it into a doc, a wiki page, your tracker, or wherever your team keeps these. Keep one document per sprint rather than one rolling page, because the carry-over section only works when last time's version is a stable thing you can point at.

SPRINT RETROSPECTIVE: [ sprint number or name ]

Dates:        [ start ] to [ end ]
Present:      [ names ]
Facilitator:  [ name, rotate this ]
Format:       [ start stop continue | 4Ls | mad sad glad ]


1. LAST RETRO'S ACTION ITEMS
- [ Action, verbatim from last time ]  -> [ done | dropped | still open ]
  [ One sentence. If still open, why, and is it still worth doing? ]
- [ ... ]


2. WHAT WENT WELL
- [ Specific practice or event, and what it saved ]
- [ ... ]


3. WHAT DID NOT GO WELL
- [ Event, not a judgment ]  | raised by [ how many people ]
- [ ... ]

Where we waited: [ what sat blocked, on whom, for how long ]


4. WHAT SURPRISED US
- [ Something that turned out differently than expected, and when we found out ]
- [ Anything we shipped that had been reported before and nobody knew ]


5. ACTION ITEMS  ( three maximum )
- [ Specific change ]   Owner: [ one name ]   By: [ date ]
- [ ... ]
- [ ... ]

Parking list: [ things worth doing that did not make the top three ]
Needs a deeper session: [ anything recurring that deserves a root cause analysis ]
Next retro:   [ date ]

Section one is the one that gets skipped when the meeting starts late, and it is the one that makes the other four worth holding. A team that reviews its own follow-through every two weeks will improve at a rate that a team running the same meeting without that section never reaches, whatever format it picks and however good the discussion feels on the day.

If a theme keeps returning in section three across several sprints, stop trying to solve it inside the hour and give it a root cause analysis of its own. Recurrence is the signal that the team has been treating a symptom, and the retro is good at spotting that and bad at fixing it in twenty minutes.

Frequently Asked Questions

What is a sprint retrospective?

What should a retrospective template include?

How long should a sprint retrospective be?

What questions should you ask in a retrospective?

What is the difference between a retrospective and a post mortem?

Who should attend a retrospective?

How do you make retrospective action items actually get done?