Retrospective template: format, example — and how action items survive until the next retro (2026)

A retrospective is the meeting where a team looks at how it worked — over a sprint, a release, a month — and decides what to change. Not what it built; the review does that. How it built it: what slowed the work down, what made it go, and which one or two things the team will do differently next time. A retrospective template is the one page that holds that conversation in a fixed order so the meeting produces a decision rather than a list of complaints.

This guide is the craft first — the format, a sprint retrospective template you can copy, a filled-in example, the four prompt sets most teams rotate between — then the mechanics: where the retro lives in the tools your team already uses, and what happens to its actions after the call. Because a retrospective's real test is not the board at the end of the hour. It is the first five minutes of the next one, when someone asks whether the two changes everyone agreed on actually happened.

What a retrospective is — and what it isn't

Four meetings sit near the retrospective, and teams merge them at their cost:

The retrospective is the only one of the four that is about the team itself, in the team's presence, with the team deciding. That is why its output is small — a team can change one or two habits per cycle, not ten — and why a retro whose list is long has usually turned into a review or an incident review wearing the wrong name. The sprint review agenda and the retro agenda are two different pages for a reason.

A retrospective is also not a status meeting with feelings. "Let's go round and say how the sprint felt" produces a mood, not a change. The template below asks for data before opinions, writing before talking, and a decision before the hour ends.

What the template carries: the format

A usable retrospective template has seven parts, in this order. Most templates online are a subset; the two that are most often missing are the first and the last.

1. The previous retro's actions, checked. Before anything else: each action from last time, its owner, and one of three states — done, not done with the reason, dropped. Two minutes for a list of three. A retrospective that skips this slot is announcing that its actions are optional, and the room hears it.
2. The period in facts. What shipped, what slipped, what broke, in numbers or dates, on the board before anyone speaks. Three to five lines. Opinions argued over the same facts converge; opinions argued over different memories do not.
3. What went well. In writing first, one note per person per point, then read aloud. Writing first is the rule that lets the quiet half of the team be heard, and the ordinary reason retros are dominated by two voices.
4. What didn't. Same method. Notes are about the work and the way of working, not about people; the facilitator moves a note that names a person into the parking lot for a one-on-one.
5. Group and choose. Cluster the notes, and let each person put two votes on the clusters they want addressed. The top one or two are the retro's subject for the remaining time; the rest wait for the next one, and the list of what waited is kept.
6. One or two changes, as actions. For each chosen cluster, the change the team commits to, written as an action item: one owner, one verb, one date. "Be better at estimating" is a wish; "Lena — add a 15-minute estimate check to Thursday's planning — from next sprint" is an action.
7. Owners, a check date, and appreciation. Read the actions back, with owners; name the date they are checked — normally the next retro; and close with one round of thanks, named. The last item is not decoration: it is what makes people willing to write the notes in item 4 next time.

What stays out: anything that belongs in the review (scope), the incident review (one failure's timeline) or a one-on-one (one person). A retrospective that tries to carry those runs long and decides nothing.

How to run one: before, during, after

Before: fix the slot and prepare the facts. A retrospective is a recurring meeting, after the review and before the next planning, so that it works from what actually shipped; how it sits in the week is in the meeting cadence guide. The day before, the facilitator posts the facts of the period in the team's channel — the shipped list, the slipped list, the incidents — and last retro's actions with owners, so that item 1 and item 2 are read before the meeting, not assembled during it. Rotate the facilitator: a retro run by the manager every time becomes a report to the manager.

During: writing before talking, then a decision. Open with the actions check — each owner says done or not, and why, in one sentence. Then the facts, read aloud in a minute. Then eight minutes of silent writing on went-well and didn't, every note visible to everyone as it lands, in each member's own language if the board translates and in the one language the room agreed on if it does not. Read-out, clustering, votes: fifteen minutes. The chosen clusters get the rest of the hour, and the facilitator's one job in that stretch is to turn talk into an action with a name before the clock runs out, reading each one back aloud so the owner agrees to it twice. Five minutes at the end: actions with owners and the check date, then appreciation.

After: publish the page the same day, where the next retro will open it. The board with its notes, the chosen clusters, the actions with owners, and the previous actions with their states — one page, to everyone, including whoever missed it. Then put it where the next retrospective starts: the action check at the top of the next page is a copy of the action list at the bottom of this one. A retrospective kept in the facilitator's notebook is a retrospective the team doesn't have.

How the hour itself is run — the opening, the time boxes, the read-back of outcomes in the last five minutes — is the same craft as any effective meeting. What is specific to the retro is the writing-first rule and the limit of two changes.

A sprint retrospective template

[Team] — Retrospective, sprint [number] / [period]
Date: [date] · Time: [start]–[end] · Link: [meeting link]
Purpose: choose one or two changes to how we work, and check the ones we chose last time.
Facilitator: [name, rotating] · Notes: [name or "the recap"]
Pre-read: last retro's page, this period's facts

1. Last retro's actions — facilitator — 5 min — information
– [Owner] — [action] — was due [date] — done / not done: [reason] / dropped
– [Owner] — [action] — was due [date] — done / not done: [reason] / dropped

2. The period in facts — facilitator — 3 min — information
Shipped: [list]. Slipped: [list]. Broke: [list]. [One number that matters this period.]

3. What went well — everyone, in writing first — 8 min — discussion
[Notes, one point each, read aloud after the writing.]

4. What didn't — everyone, in writing first — 8 min — discussion
[Notes about the work and the way of working — not about people.]

5. Group and vote — everyone — 10 min — decision
Clusters: [A], [B], [C]. Two votes each. Chosen: [one or two]. Waiting for next time: [the rest].

6. The changes we commit to — team — 15 min — decision
– [Owner] — [verb + object] — from [date] — checked at the retro of [date]
– [Owner] — [verb + object] — from [date] — checked at the retro of [date]

7. Owners, check date, appreciation — 5 min
Actions read back with owners. Check date: next retro, [date]. One thanks each, named.

Parking lot: [items raised and not chosen — carried to the next retro's page]

The template is plain text: it pastes into a document, a canvas, a whiteboard sticky-note column or a chat message without reformatting. The order is the point; the tool is not.

A filled-in example: a product team of eight, after a two-week sprint

Platform team — Retrospective, sprint 31
Purpose: choose one or two changes to how we work, and check the ones we chose last time.
Facilitator: Mateusz · Notes: the recap
Pre-read: sprint 30's retro page; the sprint 31 facts posted in the channel yesterday

1. Last retro's actions — 5 min
– Priya — move the daily to 09:30 so Lisbon joins live — was due 2 Nov — done
– Kenji — one-page definition of done for the mobile track — was due 6 Nov — not done: waiting on the QA lead's edits; re-dated 20 Nov

2. The period in facts — 3 min
Shipped 9 of 11 planned items. Slipped: the export job, the onboarding email. Broke: one incident, 40 minutes, the search index. Review on Thursday ran 25 minutes over.

3. What went well — 8 min
Pairing on the search fix got it closed the same day. The channel kept the facts, so nobody asked "what did we ship" twice. Lisbon joined every daily.

4. What didn't — 8 min
Two items were half-specified when the sprint started. The review ran over because the demo was being set up during the meeting. The incident report was written three days late.

5. Group and vote — 10 min
Clusters: readiness at sprint start (6 votes), the review's length (4), incident write-ups (3), estimates (2). Chosen: readiness, the review. Waiting: incident write-ups, estimates.

6. The changes we commit to — 15 min
– Lena — a readiness check for each item on the Tuesday before planning; an item without a one-line spec and an owner does not enter the sprint — from sprint 32 — checked at the retro of 28 Nov
– Tomás — the demo environment ready and tested by noon on review day — from sprint 32 — checked at the retro of 28 Nov

7. Owners, check date, appreciation — 5 min
Read back. Check date: 28 Nov. Thanks to Priya for the search pairing and to Lisbon for the early starts.

Parking lot: incident write-ups; estimates — first on the list for sprint 32's retro.

Notice what makes the page work: the first item and the last-but-one are the same list seen two weeks apart. Sprint 31's actions were born at the bottom of the sprint 30 page and were judged at the top of this one; sprint 32's will be judged on 28 November. That loop is the whole value of a retrospective, and it is the part most templates leave to memory.

Four prompt sets, and when each fits

Items 3 and 4 of the template are a pair of prompts, and teams tire of the same pair. Four well-known alternatives, each still ending in item 5 and 6:

Whichever set you use, two rules hold: writing before talking, and the output is one or two actions with owners. A prompt set that produces a richer wall of notes but no decision has made the meeting more interesting and less useful.

Where the retrospective lives in the tools you already use

Each major platform gives the retro a board or a document, and each stops at a different point. Documented behaviour only, from the vendors' own pages, with the month each fact was checked:

Two things are the same in every row. The retro's board is a document next to the meeting, in the one language it was written or held in; and whether last retro's actions were done is a question the document does not answer — a person opens the previous page at the next meeting and reads it into the room. Where that is fine, any of the four will do and the table is the whole answer. Where the transcript, the recording and the summary of a Teams or Meet call end up afterwards, and who can still open each, is mapped in where Teams and Meet store your transcript, recording and summary; what each platform's live translation covers inside the call and where it stops is in the Teams and Meet guides (Teams, Meet).

How the actions survive until the next retro

InterMIND is a communication space where a meeting lives in a channel, so the retrospective has an obvious home: a channel of its own, where the facts of the period and last retro's actions are posted the day before, and the channel keeps every session's recap, so sprint 30's page is one click away from sprint 31's. Each member types in their own language and reads the others in theirs; a page drafted somewhere else lands in the channel by email — the host gives the channel an address of its own, and a message sent to it appears as a regular message with the sender named and attachments kept.

During the call, the board is a note put on everyone's screen next to the video tiles with Share to conference: the facilitator edits it live while the room writes its points, and every participant reads it in their own language, with the original a toggle away. The previous session's recap can be shared into the conference the same way, so item 1 — last retro's actions — is the actual record on everyone's screen rather than someone's recollection of it.

When the call ends, the recap is written from the meeting itself: a summary, the points marked agreed, open or disputed, the action items with owners, each line keeping its timestamp. It arrives by email, as a message in the channel and as a link in the calendar event, and every signed-in member reads it in their own language — the record is translated per reader, not written once in the language the room happened to use. Any member can edit it, every edit keeps author and revision history. The host can add a recap copy to any address — a tracker or CRM inbound mailbox — so the two actions reach the system of record without anyone forwarding anything. Teams and Meet, per their documentation above, translate the moment — captions in the call, a recap in the meeting's language; here the space is what stays translated.

In an organization with team status pages on, the retro's actions are also checked. Every action a recap records joins the organization's task chain, and when the next recap is written the open ones are judged against what was said: an action someone reported finished is marked done; an action discussed but not finished is marked not done with the reason in the words of the meeting; an action nobody brought up stays open. The verdicts live on the organization's status page, each with the recap it rests on, and at the start of the next session Mia names the open items and their owners — so item 1 of the template is spoken about even when nobody opened the previous page. Team status pages are a preview feature: an organization's admin switches them on under Settings → Advanced after accepting the alpha terms (the Preview features page describes each one).

A guest — a contractor on the sprint, a client's engineer invited to one retro — joins by link, without an account and at no cost, from a phone, in the browser, and hears the meeting live in their own language. There is no record for a guest afterwards — the account is free, and it is what makes the record reachable. The host provides the space and, on a paid plan, pays only for the members active in the previous 28 days; members who go quiet keep their access at no cost.

• Open a complete recap — a real record rendered by the same code that writes yours, action items included.
• Try the live demo — no signup; speak, and hear the room translated per listener.

Retrospectives as a craft survive every tool: somebody still has to ask the team what to change and hold it to two answers. What doesn't have to survive is the second job — retyping the board after the call, in one language, and opening the next retro by asking whether anyone did what the last one decided.

FAQ

What is a retrospective meeting?

A retrospective is a recurring meeting where a team looks at how it worked over a period — a sprint, a release, a month — and commits to one or two changes in its way of working. It checks the previous retro's actions first, puts the period's facts on the board, collects what went well and what didn't in writing, groups and votes, and ends with actions that have an owner and a check date. It is distinct from the review, which looks at what was built, and from an incident review, which looks at one failure.

How do you run a sprint retrospective?

Fix the slot after the review and before planning, and post the period's facts and last retro's actions in the team's channel the day before. In the meeting: check last time's actions (five minutes), read the facts, write went-well and didn't notes in silence before anyone talks, read them out, cluster, vote with two votes each, and spend the remaining time turning the top one or two clusters into actions with one owner and one date. Read the actions back, name the check date — normally the next retro — and close with appreciation. Publish the page the same day where the next retro will open it.

What are the 5 stages of a retrospective?

The widely used five-stage structure is: set the stage (purpose, the previous actions, the rules), gather data (the period's facts and everyone's notes), generate insights (group the notes and find the pattern behind them), decide what to do (one or two actions with owners), and close (read-back, check date, appreciation). The template in this guide maps onto those stages item by item: items 1–2 set the stage and gather facts, 3–5 gather and group, 6 decides, 7 closes.

What is the difference between a sprint review and a sprint retrospective?

The review looks at the work — what was built, whether it is what was meant, what changes in the backlog — with stakeholders in the room. The retrospective looks at the way of working — what slowed the team down and what it will change — with the team only. The review leaves behind accepted items and backlog changes; the retrospective leaves behind one or two actions on how the team works, and last time's actions marked done or not. The retro sits after the review so that it works from what actually shipped.

What is start, stop, continue?

A retrospective prompt set with three columns: what the team should start doing, what it should stop doing, and what it should continue doing. It replaces the went-well and didn't pair of the basic template and suits teams that want actions straight from the notes — a "start" note is already half an action. Grouping, voting and the limit of one or two committed changes still apply.

What are the 4 questions of a retrospective?

A classic retrospective asks four questions: what did we do well, what did we learn, what should we do differently next time, and what still puzzles us. They are the 4Ls in another form — liked, learned, lacked, longed for — and work best over a longer period, such as a quarter or the end of a project, where learning matters as much as fixing.

How long should a sprint retrospective be?

For a two-week sprint and a team of five to ten, 45 to 60 minutes: five for the previous actions, three for the facts, sixteen for writing, fifteen for read-out, clustering and votes, fifteen for the changes, five to close. A retrospective that regularly runs longer has usually let the review or an incident discussion into the room; a retro that is much shorter has usually skipped the writing or the actions.

What should a retrospective template include?

Seven things: the previous retro's actions with their states; the period in facts; what went well; what didn't — both in writing first; grouping and votes; one or two changes written as action items with an owner and a date; and the close — read-back, check date, appreciation — with a parking lot for what waited. The two parts most templates skip are the first and the second-to-last: the check of old actions and the owner-and-date on new ones. They are what connect one retro to the next.

Sources: Microsoft — Take meeting notes in Microsoft Teams; Microsoft — Recap in Microsoft Teams; Zoom — Generating meeting agenda with AI Companion; Zoom — Using Meeting Summary with AI Companion; Google — Calendar & Meet settings for "Take notes for me"; Google Meet — "Take notes for me" in Google Meet; Slack — Meeting agenda template; Slack — Use huddles in Slack. Each table cell names the month its fact was checked: Microsoft's notes page, Zoom's agenda page, Google's pages and Slack's pages checked October 2026; Microsoft's recap page and Zoom's meeting-summary page checked August 2026. The five-stage structure and the prompt sets are common practice and carry no vendor claim. Vendors change plans, features and language lists over time; check their pages for the current state.