What Is a Sprint Retrospective?

What is a sprint retrospective?

The retrospective is the mechanism through which a team improves itself. Without it, a team repeats the same friction indefinitely, because nobody has a dedicated moment to name it.

This guide covers what a retrospective is for, its structure, how it differs from the sprint review, and what makes one work.

Quick answer: A sprint retrospective is a meeting at the end of each sprint where the team examines how it worked — not what it built — and agrees one or two changes to try next sprint.

It is attended by the team alone, it looks at process rather than product, and its output is a small number of improvement actions with named owners.

What a Retrospective Is For

The retrospective inspects the team's own process and produces changes to it — it is the sprint's improvement mechanism.

Inspecting the process, not the product

Product questions — is this the right feature, does it meet the need — belong in the sprint review. The retrospective asks how the work went: what slowed us down, what worked, what should change.

Keeping this boundary is what makes the meeting useful. Teams that drift into discussing features spend their improvement time on something the review already covered.

Who attends and why

The development team, the scrum master, and usually the product owner as part of the team.

Line managers, executives and stakeholders generally do not, because people discuss problems differently when someone who influences their career is listening. The meeting's entire value depends on candour, and candour depends on who is in the room.

Where it sits in the sprint

At the end, after the sprint review. The order matters: what happened in the review — stakeholder reactions, surprises, feedback — is useful input to the process discussion.

Holding it before the review means discussing the sprint without knowing how the work landed.

The Five Stages of a Retrospective

Stage Purpose Typical time (60 min) Set the stage Open, review previous actions 5 min Gather data Collect facts and observations 15 min Generate insights Find patterns and causes 15 min Decide what to do Agree 1–2 actions with owners 15 min Close Confirm actions, brief feedback 5 min

What Actually Happens in the Meeting

A retrospective opens by checking the previous sprint's actions, gathers observations before opinions, and closes by committing to one or two specific changes.

Reviewing the previous actions

The first item is always what was agreed last time and what happened.

This takes three minutes and is the most important part of the agenda. It creates accountability, and it demonstrates that the meeting has consequences. Teams that skip this step teach everyone that retrospective outcomes are optional, which is the fastest route to a meeting nobody takes seriously.

Gathering observations

Give everyone a few minutes to write privately before anything is discussed. Written first, spoken second.

Silent writing prevents the loudest or most senior voice from setting the agenda, and it means quieter people arrive with something prepared rather than having to interject. The range of issues surfaced is noticeably wider.

Start from facts where possible — cycle time, carryover, what actually happened and when — before moving to interpretation. Teams whose tooling shows this readily have an easier time here; a board with sprint history, as in Taskzin's sprint view, means the evidence is already assembled rather than reconstructed from memory.

Choosing what to change

Pick one or two changes. Give each a named owner and a due date. Keep them small enough to complete alongside delivery work.

The temptation is to agree six. A team that completes one action per sprint improves twelve times a year; a team that agrees six and completes none improves not at all.

Retrospective vs Sprint Review

The review inspects the product with stakeholders present; the retrospective inspects the process with the team alone.

Different subject

The review asks whether the right thing was built. The retrospective asks whether the team is working well.

Different attendees

The review is deliberately broad — anyone whose input shapes what gets built next. The retrospective is deliberately narrow.

Different output

The review updates the product backlog. The retrospective changes how the team operates.

Both are inspect-and-adapt events, applied to different things.

What Makes a Retrospective Work

Three conditions determine whether retrospectives improve anything: people feel safe raising real problems, actions are few enough to complete, and discussion is grounded in evidence.

Psychological safety

If the real problem is a person, a decision or something political, and the room does not feel safe, the retrospective will discuss build times instead.

The signal is a run of sessions producing small, technical, uncontroversial observations while everyone privately knows what the actual issue is. No format fixes this — it requires changing who attends or how the organisation responds to bad news.

Reading the retrospective prime directive at the start helps set the frame: that everyone did the best they could with what they knew at the time. It is not ceremony; it gives the facilitator something to point at when discussion turns toward blame.

A small number of actions

One or two, owned and dated. Credibility comes from completion, and completion is what makes people invest real thought next time.

Evidence rather than impressions

Opening with "how did the sprint feel?" produces impressions dominated by whatever happened most recently.

Starting from data — carryover, cycle time, what was blocked and for how long — grounds the discussion in the whole sprint rather than the last three days.

Common Retrospective Mistakes

The three failures are skipping the meeting when time is tight, generating actions nobody owns, and running the same format indefinitely.

Skipping it when time is short

The sprints most worth examining are the difficult ones, and those are exactly the sprints teams want to skip the retrospective and move on.

If emotions are high, delay by a day rather than cancelling. The same discussion held two days later produces analysis rather than blame.

Generating actions nobody owns

An action assigned to "the team" is assigned to nobody. One named person per action, always.

Running the same format forever

Start, Stop, Continue works well. Used twenty-six times a year, it stops producing new thinking because people answer from habit.

Rotating between a few formats — a timeline retrospective, five whys on a single problem, an appreciation session after a hard period — keeps attention without adding complexity.