Download the retrospective template
Print it for the wall or edit it in the tool you already use. Free, with no email and no sign-up.
An agile retrospective is a short, regular meeting where a team looks back at a period of work, usually a sprint, and agrees on what to change about how it works. A planning meeting is about what the team will build; a retrospective is about the way it builds. The output is not a list of complaints but one or two concrete changes the team will try before the next retrospective.
Retrospectives come straight from the Agile Manifesto of 2001, whose final principle asks teams to reflect at regular intervals on how to become more effective and then adjust their behavior. In Scrum, the Sprint Retrospective is the event that closes every sprint.
This guide covers the five stages of a good retrospective, how the most common formats compare, and a worked example that takes one team from sticky notes to a single committed change with an owner.
The short version
A retrospective has done its job when the team leaves with one specific change, one owner and a way to tell whether it worked. Everything else in the meeting exists to find that change.
The Prime Directive
Most retrospectives open by restating the Retrospective Prime Directive, written by Norm Kerth in Project Retrospectives (2001). In short: whatever we discover, we assume everyone did the best job they could with what they knew, their skills, the resources available and the situation at the time.
It is not there to be polite. A team that expects blame will offer safe, generic feedback and hide the real cause. Taking blame off the table is what lets people say "I didn't know the spec had changed" out loud, and that sentence is usually where the useful part of the meeting starts.
The five stages of a retrospective
Esther Derby and Diana Larsen's book Agile Retrospectives describes five stages that almost every good retrospective follows, whatever format it uses:
| Stage | Purpose | Typical time in a 45-minute retro |
|---|---|---|
| 1. Set the stage | Restate the goal and the Prime Directive; get everyone talking early | 5 minutes |
| 2. Gather data | Collect what happened: facts, events and how people felt | 10 minutes |
| 3. Generate insights | Group the data, pick the biggest theme and find its root cause | 15 minutes |
| 4. Decide what to do | Choose one or two changes, each with an owner | 10 minutes |
| 5. Close | Confirm the commitments and check how the meeting went | 5 minutes |
The stage teams skip most often is the third. Moving straight from "here are our sticky notes" to "here are our actions" produces actions that treat symptoms.
Common retrospective formats
The format is the set of prompts you use in stage 2. Rotating formats keeps a regular retrospective from going stale.
| Format | Prompts | Best for |
|---|---|---|
| Start, Stop, Continue | What should we start, stop and keep doing? | New teams; quick retros |
| Starfish | Keep doing, more of, less of, stop doing, start doing | Teams that want nuance beyond "good" and "bad" |
| Mad, Sad, Glad | What frustrated, disappointed or pleased you? | Sprints that were emotionally hard |
| 4Ls | Liked, learned, lacked, longed for | End of a project or a quarter |
| Sailboat | Wind (what helped), anchors (what slowed us), rocks (risks ahead) | Teams heading into a risky stretch |
| Timeline | Plot the sprint's key events, then mark highs and lows | Post-incident or post-release reviews |
The Starfish, usually credited to Patrick Kua, is the format our free retrospective template uses. Its five categories make room for "this is working but we overdo it," which a simple good/bad split loses.
A worked retrospective example
Here is a 45-minute retrospective for a fictional seven-person product team. Their two-week sprint ended with a customer export feature shipping three days late.
Stage 1: Set the stage (5 minutes)
The facilitator restates the Prime Directive and names the goal: "We shipped the export three days late. Let's find out why and agree on one change for next sprint." Everyone gives a one-word summary of the sprint. Two people say "rushed."
Stage 2: Gather data (10 minutes)
The team builds a quick timeline of the sprint, then writes Starfish notes in silence for five minutes so the loudest voice does not set the agenda.
| Keep doing | More of | Less of | Stop doing | Start doing |
|---|---|---|---|---|
| Daily standups under 15 minutes | Pairing on tricky stories | Ad-hoc design reviews in chat | Changing acceptance criteria mid-sprint | Showing designs to the customer before the sprint |
| Writing tests before merging | Demos to the customer | Status meetings that could be a message | Starting stories without a final mockup |
Stage 3: Generate insights (15 minutes)
The team clusters the notes and votes. The biggest cluster, by far, is about requirements changing after the sprint started. The team runs 5 Whys on it:
- Why did the export ship late? Testing found it did not match what the customer expected.
- Why? The acceptance criteria changed on day six of the sprint.
- Why? The customer's operations lead saw the design for the first time on day five.
- Why? Designs are reviewed internally but not shown to the customer before a story enters the sprint.
- Why? Nobody owns customer sign-off. Product assumed account management handled it, and account management assumed product did.
The root cause is not "communication." It is a step in the process with no owner.
Stage 4: Decide what to do (10 minutes)
Someone suggests "communicate better with the customer." The facilitator pushes back: that is a wish, not a change. The team agrees on one experiment instead:
- Change: for the next two sprints, any story with a customer-facing change needs a customer-reviewed mockup before it enters the sprint.
- Owner: the product manager.
- How we'll know: count the stories whose acceptance criteria change after the sprint starts. Last sprint it was three.
The other notes go on a list to revisit. The team commits to one change, not seven.
Stage 5: Close (5 minutes)
The facilitator reads back the experiment and the owner, and each person rates the retrospective from one to five. The next retrospective will open by checking the count.
What makes a retrospective fail
- No action, or too many. A list of ten improvements is a list nobody owns. Pick one or two.
- Actions that are wishes. "Communicate better" cannot be done on Monday. "Customer signs off on mockups before the sprint" can.
- Never checking last time's action. If the next retrospective does not open by reviewing the last change, the team learns that commitments are optional.
- Blame. Once one person is singled out, everyone else starts editing what they say.
- The same format every time. Rotate prompts so the team does not give the same answers on autopilot.
Skipping retrospectives altogether has its own cost, which we cover in the cost of process debt.
Retrospective vs. sprint review vs. post-mortem
These three get confused because they all look backward:
- Sprint review: the team shows what it built to stakeholders and gets feedback on the product.
- Retrospective: the team looks at how it worked and changes its process. Stakeholders usually are not in the room.
- Post-mortem: a one-off review of a specific incident or failure. It often uses the same stages, with a timeline at its center.
Free retrospective template
The free retrospective template comes as a PDF, Word document, Excel workbook and PowerPoint deck. It uses the Starfish format, with prompts for each of the five categories and an action tracker for owners and dates.
Keep going with retrospectives
- How to run a project retrospective: the facilitator's mindset and how to handle a heated room.
- How to run a sprint retrospective in Microsoft Teams: a 45-minute remote playbook.
- The cost of process debt: why skipping retrospectives slows teams down.
Frequently asked questions
How often should a team hold a retrospective?
At the end of every sprint, or every two to four weeks for teams that do not work in sprints. Holding one after a major release or incident is also common.
How long should a retrospective take?
Around 45 minutes for a two-week sprint. The Scrum Guide caps the Sprint Retrospective at three hours for a one-month sprint and notes it is usually shorter for shorter sprints.
Who should attend a retrospective?
The people who did the work: the delivery team, including the product owner and Scrum Master in Scrum. Managers and stakeholders usually stay out, so people can speak openly.
Who should facilitate a retrospective?
Often the Scrum Master or a rotating team member. Rotating helps, and for a tense retrospective an outside facilitator can keep the room focused on the process rather than on people.
What is the output of a retrospective?
One or two specific process changes, each with an owner and a way to tell at the next retrospective whether it worked.
Ready to put this into practice? Run it with your team using the free retrospective template.
