Skip to content

Retrospective

At a glance

  • Purpose: Look back at a period of work, decide what to keep and what to change, and commit to a small number of concrete improvements.
  • Use it when: At the end of every iteration, and at project close. The retrospective owns the process; the sprint review owns the product.
  • Owner: A facilitator — ideally not the person who has to defend the decisions being discussed.
  • Related: Module 04 · Module 12

A retrospective looks back at a period of work to decide what to keep doing and what to change. It is a working tool, not a report card — its output must be concrete changes, not feelings.

Copy the skeleton below and replace the bracketed text.

Retrospective skeleton

# Retrospective — [Project / iteration name]

| | |
| --- | --- |
| **Date** | [YYYY-MM-DD] |
| **Period covered** | [Start] – [End] |
| **Facilitator** | [Name] |
| **Participants** | [Roles, not necessarily names] |

## 1. What was the goal?

[What did the period set out to achieve? State it plainly so the discussion has a reference.]

## 2. What happened?

[A factual summary — delivered work, missed items, and any surprises. Avoid blame.]

## 3. What went well?

- [Item — and *why* it worked, so it can be repeated deliberately]

## 4. What went poorly?

- [Item — and the underlying cause, not just the symptom]

## 5. What did we learn?

- [Insight]

## 6. What will we change?

Each improvement must be specific, owned, and checkable. Vague intentions change nothing.

| # | Change | Owner | By when | How we will know it worked |
| --- | --- | --- | --- | --- |
| 1 | [Concrete change] | [Who] | [Date] | [Observable result] |

## 7. Actions carried forward

| Action | From | Status |
| --- | --- | --- |
| [Action] | [Earlier retrospective] | [Done / Open] |

How to use this template

  1. Open the previous actions first. A retrospective that never checks its own outcomes teaches the team that the meeting changes nothing.
  2. Establish the goal of the period before discussing what happened, so the conversation has a reference point rather than becoming a general mood.
  3. Discuss facts before feelings: what was delivered, what slipped, what surprised you. Blame-free does not mean evidence-free.
  4. Limit the output to two or three committed changes. Ten intentions produce none; the limit is what forces a choice.
  5. Give every change an owner, a date, and a way of knowing it worked. Without the third, you cannot tell improvement from amnesia.
  6. At project close, route the organisational lessons to whoever owns the process — otherwise they are filed with the project and die with it.

Field descriptions

Section What goes in it Watch out for
Period goal What the period set out to achieve Jumping straight to complaints
What happened A factual summary with numbers Narrative shaped to a conclusion
What went well Items and why they worked Skipping this section entirely
What went poorly Symptoms plus underlying causes Naming individuals
What we learned The generalisable insight Restating the symptom
What we will change Two or three concrete, owned changes Ten aspirations
Carried-forward actions Status of previous commitments A section everyone avoids

Worked example

From the capstone checkpoints, invented for teaching. Compare a weak output with a workable one:

Weak change Why it fails Workable version
"Communicate better" Not specific, not owned, not checkable "Post the sprint goal on the shared board at planning and refer to it at stand-up — owner: product owner; check: goal visible for the next sprint"
"Be more careful with estimates" Assumes effort was the problem; blames without diagnosing "Record in each estimate whether it is analogous, three-point, or expert judgement, and compare at the next retrospective — owner: PM; check: all estimates carry a basis"
"Start testing earlier" Vague timing, no owner "The tester joins refinement so test cases exist before the item enters the sprint — owner: tester; check: every ready item has at least one test case"

Note that the fourth column occasionally shows the systemic cause rather than the individual act. In the second row, the diagnosis could equally have been "the estimates were right and the scope kept changing" — and a retrospective that jumps to the first explanation misses the more useful one. Testing that hypothesis is what the check column is for.

Common mistakes

  • Blame-free, but not vague. "The security review found two bugs" is fine; "we should be more careful" is not.
  • Limit the changes. Two or three committed changes beat ten aspirational ones.
  • Every change needs an owner and a check. Otherwise it will not happen, and you will have the same retrospective again next time.
  • Follow up. Open the previous retrospective's actions at the start of each session.
  • Look for systemic causes. "A person forgot" is rarely the real explanation; the interesting question is why the process allowed it to matter.
  • No facilitator. The person with most at stake ends up steering the discussion away from their own decisions.
  • Retrospective used as a complaints session. Without the "what went well" section, the meeting becomes a list of grievances and the practices worth keeping get dismantled.
  • Confusing it with the review. Process improvement and product feedback are different conversations, and one meeting cannot do both well.
  • Actions carried into a document nobody opens. Put them where the team already looks — the board, the next sprint's plan — and review them first next time.