Sprint Retrospective Template (PMI Standard Word & PDF)

8 min read · Reviewed August 2026 by Dan Sunil Kumar

When to use it

• Retros have turned into a status round or a complaints session with no follow-through.
• The same problem keeps appearing sprint after sprint and nothing changes.
• Actions get agreed but never land because they have no owner or due date.
• A new facilitator needs a script and a set of formats to rotate between.
• A difficult sprint needs a blame-free, factual review the team will actually engage with.

Every section, and what good looks like

1. Section 1

   Session header

   Team, sprint reviewed, date, timebox, facilitator, attendees and which format you are using.

   The format is rotated. Running Start/Stop/Continue for the twentieth time is why people stop contributing.

2. Section 2

   Data to bring

   Committed versus delivered, velocity or throughput, carry-over, escaped defects, unplanned work added, cycle time.

   Prepared before the session and shown first, so the discussion starts from facts rather than the last two days of memory.

3. Section 3

   Gather the data

   Silent writing, one observation per note, in three columns: went well, got in the way, puzzled us.

   Five silent minutes before anyone speaks — otherwise the first or loudest voice sets the entire agenda.

4. Section 4

   Themes and root causes

   Group the notes, dot-vote, take the top two or three, and ask why until you reach a cause you can change.

   The cause is a process, an information gap or an unclear decision right — never a person's name.

5. Section 5

   Actions — three at most

   Each with an owner, a due date, and how you will know it worked.

   Actions go into the next sprint backlog as real items so they compete honestly for capacity.

6. Section 6

   Previous actions check

   Last sprint's actions, whether they were done, and what effect was observed.

   Done first, before new actions are agreed. It is the fastest way to make retrospectives feel worth attending.

7. Section 7

   Facilitation notes

   Prime directive, timeboxes, escalation route for issues outside the team's control, and closing check.

   Anything raised three retros running is escalated rather than re-discussed — the team cannot fix it alone.

A filled-in example

A realistic retrospective record, so you can see how discussion turns into one or two owned actions.

Mistakes that make retrospectives repeat themselves

• Skipping the retrospective when the sprint was busy — precisely the sprint with the most to learn from.
• No data, so the conversation is dominated by whatever happened most recently.
• Discussion straight after the prompt, letting the first speaker frame every theme.
• Agreeing eight actions. Three is the realistic ceiling; one that lands beats five that do not.
• Actions with no owner or no due date, which are wishes rather than commitments.
• Never reviewing whether last sprint's actions worked, which teaches the team that retros are theatre.
• Letting it become a performance review. Focus on the system that produced the outcome, not the people inside it.
• Managers using retro notes as evidence, which ends candour permanently.

Questions people ask

What is a sprint retrospective?

A recurring team session at the end of a sprint to inspect how the work went — process, tools, collaboration and quality — and to agree a small number of specific improvements for the next sprint.

How long should a sprint retrospective be?

Up to three hours for a one-month sprint under Scrum, which in practice means about 45 minutes for a one-week sprint and 60 to 90 minutes for a two-week sprint.

What questions should you ask in a retrospective?

What went well, what got in the way, and what puzzled us. Then for each theme: why did that happen, what would we change, who owns the change, and how will we know it worked.

What are common retrospective formats?

Start / Stop / Continue, Mad-Sad-Glad, the 4Ls (Liked, Learned, Lacked, Longed for), Sailboat (wind and anchors), and a Timeline walk-through of the sprint. Rotate them so the session stays fresh.

What is the difference between a retrospective and a lessons learned log?

A retrospective is a short, recurring team session focused on the next sprint. A lessons learned log is the durable project-level record that outlives individual sprints and feeds organisational templates and standards. Run both — retros feed the log.

How do you make retrospective actions actually happen?

Cap them at three, give each an owner, a due date and a success measure, add them to the next sprint backlog so they consume real capacity, and review them at the start of the following retrospective.

Read next

• Scrum Ceremonies: Purpose, Timebox and Agenda
• Status, Steering and Retrospectives That Earn Their Time
• Scrum Mechanics Without the Dogma
• Kanban, WIP Limits and Flow Metrics

Other PMI-standard templates

Every one has the same walkthrough, worked example and PMI mapping, and every file ships inside the PM Delivery Toolkit.

• Project charter templateWord & PDF · Integration Management
• Project plan pack templateWord, Excel & PDF · Integration & Schedule Management
• Project status report templateWord & PDF · Communications Management
• RACI matrix templateExcel, Word & PDF · Resource Management

Keep going on the site

The hubs and tools that pair with this sprint retrospective.

• PM Delivery ToolkitEvery PMBOK-mapped template in one paid pack, with the walkthroughs.
• PM glossaryPlain-English definitions for the terms these registers use.