You know the retro I mean. Forty-five minutes of sticky notes, a lot of nodding, someone writes “communication” for the third sprint running, and two weeks later the exact same sticky note turns up again like a sequel nobody asked for.
Retrospectives are supposed to be agile’s built-in improvement loop. The Agile Manifesto even writes it into its twelfth principle: at regular intervals, the team reflects on how to become more effective and adjusts. In practice, plenty of retros produce a lovely board and no change at all.
This guide covers how to run one step by step, a free template, the formats worth knowing, and how to make the action items survive past Monday. For your other sprint ceremonies, tl;dv has agile scrum meeting templates too.
What Is a Retrospective Meeting?
A retrospective meeting is a short, recurring session where a team reviews how it worked during a recent period and agrees on a few specific changes to try next. It looks at the process (people, tools and habits) rather than the product.
In Scrum, the retrospective has a formal name and a fixed slot. According to the 2020 Scrum Guide, the sprint retrospective exists to plan ways to increase quality and effectiveness. The team looks at individuals, interactions, processes, tools and its Definition of Done, then picks the most helpful changes, which can go straight into the next Sprint Backlog.
Is a Sprint Retrospective the Same as a Sprint Review?
No. A sprint review inspects the product with stakeholders, while a sprint retrospective inspects the team’s way of working, usually without them. A post-mortem is a third thing: typically a one-off after a project or incident rather than a regular event.
| Question | Sprint Retrospective | Sprint Review | Post-Mortem |
|---|---|---|---|
| What it inspects | How the team worked | What the team built | What happened on a finished project or incident |
| When | End of every sprint, after the review | End of every sprint, before the retro | Once, after the project or incident |
| Who attends | The Scrum team | The Scrum team plus stakeholders | Everyone involved, often across teams |
| Main output | One to three process changes | An updated Product Backlog | Lessons and preventive actions |
The client-facing look-back is a different animal: the quarterly business review (QBR).
How Long Should a Sprint Retrospective Be (and Who Attends)?
The Scrum Guide caps a sprint retrospective at three hours for a one-month sprint and says shorter sprints usually get shorter retros. It doesn’t set exact times for shorter sprints, so the common rule of thumb of 45 to 90 minutes for a two-week sprint comes from practitioner convention rather than the Scrum Guide.
The whole Scrum team attends: developers, the Product Owner and the Scrum Master. The Scrum Master is accountable for making sure Scrum events happen and stay within their timebox, but they don’t have to facilitate every retro. Rotating the facilitator stops one voice from steering every session.
Managers and stakeholders usually stay out, because people are less candid with the boss in the room. The retro sits after the sprint review and before the next sprint planning, like a project kickoff meeting in reverse.
How Do You Run a Retrospective Meeting? (5 Steps)
Run it in five stages: set the stage, gather data, generate insights, decide what to do, and close. That structure comes from Esther Derby and Diana Larsen’s book Agile Retrospectives, and it works with any format.
- Set the stage (5 minutes). State the goal, the timebox and the ground rules, then do a quick check-in, such as one word for how the sprint felt. Review the last retro’s action items first: done, in progress or dropped. Skip this and you’re just generating fresh to-dos to ignore.
- Gather data (10–15 minutes). Everyone writes notes silently before anyone speaks. This stops the loudest person from setting the agenda and gets the quiet teammates’ input onto the board. Add hard data where you have it: carried-over tickets, incidents, cycle time.
- Generate insights (15–20 minutes). Group similar notes, then dot-vote on what matters most. Dig into the top one or two by asking “why?” until you reach something the team can actually change.
- Decide what to do (10 minutes). Turn the top issues into one to three actions, each with an owner, a due date and a way to tell whether it worked.
- Close (5 minutes). Read the actions back, confirm the owners, and ask how the retro itself could be better next time. Then send the notes out the same day.
The five stages, timed for a 60-minute retro after a two-week sprint.
Keep the write-up closer to notes than formal minutes. If you need something more structured, borrow from these meeting minutes templates, or adapt one of tl;dv’s meeting agenda templates for the five steps above.
What Should a Retrospective Template Include?
A retrospective template needs five things: sprint context, the last retro’s actions, the board itself, the themes you voted on, and an action table with owners and dates. Everything else is decoration.
Sprint retrospective template (copy and paste):
- Sprint: [number and dates] · Facilitator: [name] · Attendees: [names]
- Sprint goal met? Yes / Partly / No
- Last retro’s actions: [action] (Done / In progress / Dropped)
- Start: [new practices to try]
- Stop: [practices that slowed us down]
- Continue: [practices that worked]
- Top voted themes: 1. [theme] 2. [theme]
- Action items: [action] · [owner] · [due date] · [how we’ll know it worked]
If you’d rather the board filled itself in, AI notetakers can apply the same structure to the conversation. tl;dv has a built-in Retrospective session template that you can customize with these headings, so your AI meeting notes come out as a ready-made retro summary.
tl;dv’s Retrospective session template, which you can customize and apply to future retros automatically.
Which Agile Retrospective Format Should You Use?
Start with Start, Stop, Continue for a new team or a short retro, and switch to the 4Ls when you want to surface what the team learned and what it’s missing. Rotate formats every few sprints if answers start sounding scripted, but keep the action-item step identical every time.
Start, Stop, Continue
Three columns: what the team should start doing, stop doing and keep doing. It’s the fastest route from feedback to action, because every note is already phrased as a behavior, such as “Start: posting PRs before 3 p.m.” or “Stop: adding tickets mid-sprint without the Product Owner.” The catch is that it skips feelings and learning, so real frustration can hide inside a polite “Stop: long meetings.”
4Ls (Liked, Learned, Lacked, Longed For)
Four columns: what the team liked, learned, lacked and longed for. It’s better than Start, Stop, Continue at surfacing missing resources and skills (“lacked a staging environment”), but its notes aren’t actions yet, so budget extra time for step four.
The same sprint through two formats: Start, Stop, Continue gives you behaviors, the 4Ls gives you gaps.
Other Retrospective Formats Compared
| Format | Columns | Best for | Watch out for |
|---|---|---|---|
| Start, Stop, Continue | Start · Stop · Continue | New teams, short retros | Skips feelings and learning |
| 4Ls | Liked · Learned · Lacked · Longed for | Surfacing gaps in skills or resources | Notes need converting into actions |
| Mad, Sad, Glad | Mad · Sad · Glad | Checking morale after a rough sprint | Can stay emotional without a decision step |
| Sailboat | Wind · Anchors · Rocks · Island | Spotting risks ahead of a goal | The metaphor eats time with new teams |
| Starfish | Keep · Less of · More of · Stop · Start | Fine-tuning a team that mostly works | Five columns can spread votes thin |
| Rose, Thorn, Bud | Rose · Thorn · Bud | Quick retros with non-technical teams | Light on root causes |
Whatever the format, let people vote. In a three-year study of 37 team retrospectives, about two-thirds of the corrective actions came from problems participants had voted for, so the vote does real work in steering what gets fixed.
What Questions Should You Ask in a Retrospective?
Ask about the process rather than the people, and finish with questions that force a decision. These cover most sprints:
- What helped us move faster this sprint?
- Where did work get stuck or wait on someone?
- Did we do what we agreed in the last retro? If not, why not?
- Is this within our control, or does it need escalating?
- Who owns it, by when, and how will we know it worked?
How Do You Turn Retrospective Feedback into Action Items?
Pick one to three actions, give each a single owner and a due date inside the next sprint, and review them at the start of the next retro. Anything vaguer tends to turn into a wish.
This is where most retros fall apart. Researchers who analyzed retro minutes from a large Scandinavian agile project logged 109 issues and 36 action items, yet couldn’t tell how many of those actions were ever carried out.
A good retro action item is:
- Specific: “Add a ‘blocked’ column to the Jira board” beats “improve communication.”
- Owned: one name, never “the team.”
- Dated: due before the next retro.
- Checkable: you can answer “did it work?” with a yes or no.
- In your control: if it isn’t, escalate it instead.
Then put it where people already look. The Scrum Guide allows improvements to go straight into the next Sprint Backlog, which beats a doc nobody opens. tl;dv picks out action items and owners from the recording. On paid plans, it can send them straight to tools like ClickUp, Monday or Confluence, or to Jira through Zapier, and run AI agents for meetings that handle the follow-up after every retro.
Action items with owners, pulled from the retro itself rather than someone’s memory of it.
How Do You Know If Your Retros Are Working?
Track two numbers: the share of retro actions completed by the next retro, and how often the same issue comes back. If the same note keeps reappearing, your actions aren’t reaching the cause. On tl;dv’s Business and Enterprise plans, recurring AI reports can summarize themes across several retros so the repeat offenders stand out.
Why Do Retrospectives Fail?
Retrospectives usually fail for one of four reasons: people don’t feel safe being honest, the team keeps discussing problems it can’t fix, the actions never happen, or the retro itself has gone stale. All four are fixable once you name them.
- Low psychological safety. Google’s Project Aristotle studied 180 teams and found that psychological safety mattered most among the five dynamics of effective teams. If people fear blame, the board fills up with “communication could be better” and nothing real.
- Groundhog Day issues. The three-year study above found some topics, like estimation accuracy, recurring for years because the team couldn’t control them. Escalate what the team can’t fix instead of rediscussing it every two weeks.
- No follow-through. If the last retro’s actions aren’t the first item on the agenda, start there.
- Retro fatigue. Same format, same facilitator, same 90 minutes. Rotate both, and shorten it when there’s little to say.
Spotting the Groundhog Day issues across a quarter of retros.
How Do You Run a Remote or Async Retrospective?
Run a remote retro the same way as an in-person one, but collect written input before the call and keep the live part short. Async retros work best as a hybrid: everyone adds notes and votes on a shared board over a day or two, then a 30-minute call decides the actions.
Silent writing matters even more on video, where whoever unmutes first wins. Across time zones, rotate the slot so the same people aren’t always on at 10 p.m., and share the notes with anyone who can’t attend; that’s how tl;dv helps teams collaborate across time zones.
Should You Record Your Retrospective?
Record a retrospective only if the whole team agrees and knows how the recording will be used. A recording makes action items and decisions easy to capture, but it can make people more guarded, which defeats the point of a retro.
In the Scandinavian study above, the researchers noted that making retro minutes widely available could lead teams to tone down their criticism, and a recording is a far more detailed version of the same thing. If your team still wants one, set ground rules:
- Ask first, every time, and give people a real option to say no.
- Say who can access the recording and how long it’s kept.
- Stop recording for sensitive interpersonal topics.
- Check the call recording laws that apply where your teammates are. This isn’t legal advice, and consent rules vary by jurisdiction.
Bot-free recording doesn’t remove the need for consent. tl;dv’s desktop app can record retro audio without a bot joining the call, which some teams find less intrusive (see this round-up of bot-free AI notetakers). But nobody sees a bot, and tl;dv’s consent requests only cover meetings you created in your calendar, so announcing a bot-free recording at the start is on you. There’s more on that in is bot-free recording legal and tl;dv’s guide to AI and privacy.
Bot-free mode records audio from your device, so tell the team before you start.
Consent requests can cover internal, external or all meetings you created in your calendar.
Which tl;dv Plan Do You Need for Retros?
The Free plan covers AI notes and action items for up to 10 meetings, Pro removes that cap and adds integrations like Jira, and Business adds unlimited Ask AI across multiple retros. Here’s how the plans compare on the features that matter for retrospectives.
| Feature | Free | Pro | Business | Enterprise |
|---|---|---|---|---|
| Price per seat | $0 | $18/month billed annually ($216/year), or $29 monthly | $29/month billed annually ($348/year), or $39 monthly | Custom |
| AI meeting notes | Up to 10 meetings | Unlimited | Unlimited | Unlimited |
| Action item assignment | Yes | Yes | Yes | Yes |
| Custom AI notes templates | Yes | Yes | Yes | Yes |
| Ask AI on a single retro | 10 queries | Unlimited | Unlimited | Unlimited |
| Ask AI across multiple retros | Up to 5 queries | Up to 5 queries | Unlimited | Unlimited |
| Follow-up email drafting | Yes | Yes | Yes | Yes |
| Integrations (e.g. Jira via Zapier) | No | 5,000+ | 5,000+ | 5,000+ |
| Recording consent settings | Personal | Personal + team | Personal + team | Personal + team + organization |
| Data retention | Up to 3 months | Custom | Custom | Custom |
Checked October 16, 2026. Source: tl;dv’s pricing page.
Conclusion
The short version: run every retro in five stages, leave with one to three actions that each have an owner and a due date, and check those actions at the start of the next retro.
A retrospective meeting only works if something changes after it. Keep the structure predictable, rotate the format when it goes stale, make honesty safe, and treat action items like real work with owners and dates. Then open every retro by checking the last one’s list.
Do that, and the retro becomes the meeting that makes all the other meetings better.
Capture Your Next Retro’s Action Items Free
Free plan includes AI notes for up to 10 meetings. No credit card required.
Frequently asked questions
What Is the Difference Between a Retrospective and a Stand-Up?
A stand-up is a short daily check on progress toward the sprint goal. A retrospective happens once per sprint and looks at how the team worked, so it can change the process rather than just the plan for the next day.
Are Retrospectives Only for Software Teams?
No. Any team that works in cycles can run one, including marketing, sales, design and customer success teams. The format is the same; only the examples on the board change.
Do Kanban Teams Hold Retrospectives?
Yes, though Kanban has no sprints to end. Kanban teams typically schedule retros on a regular cadence or after a milestone instead of tying them to a sprint boundary.
How Many Action Items Should Come Out of a Retrospective?
One to three. Fewer actions with clear owners and dates beat a long list that nobody finishes, and they leave room to review each one properly at the next retro.