# Sprint Review: [Team name], Sprint [NN]

> A Sprint Review is the Scrum event where the Scrum Team and its key stakeholders inspect the outcome of the Sprint and decide what to adapt next. This template follows the Scrum Guide 2020 (the latest revision as of October 2026): the team shows the Increment that meets the Definition of Done, the group discusses progress toward the Product Goal and changes in the environment, and the Product Backlog is adjusted. It is a working session, not a status presentation and not a release gate. Replace every `[bracketed]` value and every row marked *Example*.

<!-- Guidance: How to use this template
- Fill sections 1 and 2 before the event: what the Sprint aimed for and which items are actually Done. Only work that meets the Definition of Done can be shown.
- Spend most of the time on sections 3 and 4 (demo and feedback), then record the backlog changes in section 5 while people are still in the room.
- Timebox: at most four hours for a one-month Sprint, usually shorter for shorter Sprints (Scrum Guide 2020). The Sprint Review comes before the Sprint Retrospective.
- The worked example is fictional: the Quillmoor Scheduling team, Sprint 14, building an offline mode for its field-service app.
-->

## Document control

| Field | Value |
|---|---|
| Document ID | [REVIEW-TEAM-NN] |
| Sprint | [NN] (YYYY-MM-DD to YYYY-MM-DD) |
| Review date and timebox | YYYY-MM-DD, [N] minutes |
| Product Goal | [The current Product Goal, from the Product Backlog] |
| Sprint Goal | [One sentence, from Sprint Planning] |
| Product Owner | [@po] |
| Facilitator | [@name] |
| Stakeholders invited | [Names or roles] |
| Last updated | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | YYYY-MM-DD | [@po] | Notes from the Sprint Review |

## 1. Sprint Goal and outcome

<!-- Guidance: State the goal and say plainly whether it was met. Judge the Sprint by its goal, not by the number of items closed. Pitfall: hiding a missed goal behind a long list of finished tasks. -->

| Item | Value |
|---|---|
| Sprint Goal | *Example:* Field technicians can view and update today's jobs with no network connection |
| Goal met | [Yes / Partly / No] *Example:* Partly |
| Why | *Example:* Offline viewing and updates work; conflict handling when two people edit the same job is not Done |

## 2. What is Done

<!-- Guidance: List only items that meet the Definition of Done. Items that do not meet it go back to the Product Backlog and are not demonstrated. Link the evidence (test report, build, release note). -->

| Backlog item | Done (meets DoD) | Shown in demo | Released to users | Evidence |
|---|---|---|---|---|
| PBI-201 *(Example)* Cache today's jobs on the device | Yes | Yes | No, behind a flag | [Test report link] |
| PBI-202 *(Example)* Edit job status offline and sync later | Yes | Yes | No, behind a flag | [Test report link] |
| PBI-203 *(Example)* Resolve edit conflicts on sync | No, returned to backlog | No | No | Two acceptance tests fail |

## 3. Demonstration

<!-- Guidance: Let stakeholders use the product where possible, on realistic data. Show the user problem first, then the working software. Keep slides to a minimum. -->

| Order | What is shown | Presenter | User scenario |
|---|---|---|---|
| 1 *(Example)* | Job list opens with the phone in airplane mode | [@dev-a] | Technician in a basement with no signal |
| 2 *(Example)* | Status changed offline appears in the dispatcher view after reconnecting | [@dev-b] | Dispatcher checks progress at noon |
| [N] | [What is shown] | [@name] | [Scenario] |

## 4. Stakeholder feedback

<!-- Guidance: Capture feedback in the stakeholder's words, with who said it. Do not argue or solve it in the room; decide in section 5 what happens to each point. -->

| ID | From | Feedback | Proposed response |
|---|---|---|---|
| FB-01 *(Example)* | [Head of field operations] | Technicians also need the site safety notes offline | New backlog item, refine next Sprint |
| FB-02 *(Example)* | [Support lead] | Show the last sync time on screen, support will be asked about it | Add to PBI-202 acceptance criteria |
| [FB-NN] | [Role] | [Feedback] | [New item / change item / no action, with reason] |

## 5. Environment and Product Backlog changes

<!-- Guidance: Note what changed outside the team (market, users, budget, timeline, dependencies), then record every change to the Product Backlog. The Product Owner decides ordering. -->

**Changes in the environment:** [*Example:* the largest customer moves its rollout from March to May, which reduces the urgency of conflict handling]

| Change | Backlog item | Reason | Decided by |
|---|---|---|---|
| Added *(Example)* | PBI-215 Offline site safety notes | FB-01 | [@po] |
| Reordered *(Example)* | PBI-203 conflict handling stays first | Still needed before any external beta | [@po] |
| [Added / Removed / Reordered / Split] | [PBI-NNN] | [Reason] | [@po] |

**Progress toward the Product Goal:** [Short assessment, for example the share of goal-related items Done and what remains]

**Likely focus of the next Sprint:** [Input for Sprint Planning; the Sprint Goal itself is set at Sprint Planning]

## Related templates and references

- [Sprint retrospective](./sprint-retro.md), held after this event
- [Sprint planning](./sprint-planning.md), [Product backlog](./product-backlog.md) and [Definition of Done](./definition-of-done.md)
- [Release plan](./release-plan.md) and [roadmap](./roadmap.md)
- [User story](./user-story.md)
- Scrum Guide 2020, K. Schwaber and J. Sutherland: https://scrumguides.org/scrum-guide.html (revisions: https://scrumguides.org/revisions.html)

## Standard and licence note

Structure aligned with the Sprint Review event of the Scrum Guide 2020 (Schwaber and Sutherland, published under CC BY-SA 4.0). This template names and cites the guide only; it does not copy its text, and all wording here is original. Check the current Scrum Guide at scrumguides.org. Template licence: MIT.