Skip to content

Sprint Review

At a glance

  • Purpose: Inspect what was actually built with the people it is for, and use their reaction to change the backlog — not to receive approval.
  • Use it when: At the end of every sprint. Allow around an hour for a two-week sprint, and invite the users, not only management.
  • Owner: The product owner runs it; the team demonstrates.
  • Related: Module 04 · Lab 15

How to use this template

  1. Demonstrate working software against the sprint goal, on realistic data. Slides are not a demonstration, and a prepared script with hand-picked records is not evidence.
  2. Show the unfinished and the difficult too. A review that only displays success cannot produce a useful decision.
  3. Record feedback as backlog items or decisions, with an owner. Feedback that is only discussed evaporates by the next sprint.
  4. Report the sprint's outcome with numbers — planned against achieved — and the reason for any gap.
  5. Invite the people who can say "that is not what we meant". Their reaction is the value of the meeting.

Field descriptions

Field What goes in it Watch out for
Sprint goal outcome Met, partly met, not met, with the reason Silence about a missed goal
Demonstrations Item, what was shown, on what data Screenshots instead of running software
Feedback What a stakeholder said, and what it becomes Feedback with no owner
Metrics Planned vs achieved, defects found, work carried over Reporting only percentages
Decisions What changed, by whom Decisions taken outside the meeting
Next sprint outlook The emerging priority A promise made on the team's behalf

Blank template

# Sprint Review — [Sprint n]

| | |
| --- | --- |
| **Date** | [YYYY-MM-DD] |
| **Sprint goal** | [The goal as stated at planning] |
| **Outcome** | [Met / Partly met / Not met] |
| **Attendees** | [Team, product owner, users, stakeholders — list roles] |

## 1. Sprint goal outcome

[One paragraph: what was achieved against the goal, and if the goal was not met, the reason — stated
plainly, without attributing it to an individual.]

## 2. Demonstrations

| Item | What was shown | Data used | State |
| --- | --- | --- | --- |
| [Item] | [The behaviour demonstrated] | [Real / realistic / synthetic] | [Done / partly done] |

For each item not meeting the definition of done, state what remains and where it is recorded.

## 3. Measured outcome

| Measure | Planned | Achieved | Note |
| --- | --- | --- | --- |
| Items completed | [n] | [n] | |
| Work carried over | — | [n] | |
| Defects found during the sprint | — | [n] | [Severity breakdown] |

## 4. Feedback from stakeholders

| # | Feedback | Source | Becomes | Owner |
| --- | --- | --- | --- | --- |
| 1 | [What was said] | [Role] | [Backlog item / change request / declined, with reason] | [Who] |

## 5. Decisions

| Decision | Made by | Consequence |
| --- | --- | --- |

## 6. Outlook

[What the backlog now suggests for the next sprint, and any constraint the product owner should know
about. This is a forecast, not a commitment.]

Worked example

From Lab 15, invented for teaching:

Measure Planned Achieved Note
Items completed 5 3 Two items failed the definition of done
Defects found — 4 1 P2 in the document upload; 3 P3 cosmetic
# Feedback Source Becomes Owner
1 "Staff need to see why an application was rejected, not just that it was" Admissions officer New backlog item, ordered above the notification feature Product owner
2 "Can applicants edit a submitted application?" Admissions officer Change request — outside the agreed scope Product owner
3 "The list screen is slow with our real data" IT operations Defect P2, linked to the pagination gap Tester

Feedback item 2 is the pedagogically important one: it is a scope change, not a defect, and it therefore belongs in the change request process with its cost stated — the pattern that Lab 19 tests. Feedback items 1 and 3 are safe to absorb into the backlog because they fall inside the agreed scope. Deciding which is which at the review is exactly the judgement the meeting exists to develop.

Common mistakes

  • Slides instead of working software. A prepared presentation hides precisely what the review is for.
  • Only showing successes. Problems surface later and more expensively.
  • Demonstrating on curated data. Realistic data is what exposes performance and edge-case problems; reviewing on synthetic records is how the pagination gap in the example above goes unnoticed.
  • Feedback captured but not owned. Unassigned feedback is a conversation, not a decision.
  • Treating the review as an approval gate. It exists to inspect and adapt, not to sign off.
  • Promising dates on the team's behalf. The team forecasts; the product owner communicates.
  • Turning it into a status meeting. If no user attends, it becomes a progress report and stops producing useful change.