The Sprint Review is a working session with stakeholders to inspect the sprint's outcome and consider adaptations. A presentation can support it, but should not replace the discussion. The Scrum Guide makes that distinction.
Prepare one inspectable path through the product
Choose a task that makes the completed work understandable. For a search filter, write down the starting query, the filter applied, and the result that the audience should inspect. Bring the actual usable increment and its verification evidence. A drawing of a planned control cannot establish that the feature works.
Before inviting stakeholders, confirm which work meets the team's Definition of Done. Work that does not meet it is not part of the increment to demonstrate. Keep its status in the maintained backlog rather than presenting it as a completed product result.
A fictional search increment
Illustrative example: this product, test material, and proposed priorities are fictional. No stakeholder feedback or real product performance is claimed. The sample completed work is a document-type filter. Export is unfinished and stays outside the demo path.
| Review material | What it lets the group inspect | Boundary |
|---|---|---|
| Search for “travel policy,” then apply the policy-document filter | Whether the completed control narrows this supplied sample dataset as expected | A sample task, not proof of general search quality |
| Example verification note: expected policy documents appear and other types are excluded | The tested behavior of this sample path | Illustrative evidence, to be replaced with actual test records |
| Export item in the backlog | Its unfinished status and possible future priority | Not a demo or an increment claim |
Leave a stakeholder question open: Does narrowing by type help you locate the document you need, or is another distinction more useful? An open question gives the discussion a purpose. A fabricated quote such as “customers loved the filter” would erase the very feedback the meeting is meant to seek.
A proposed 50-minute review
- Product direction and review task, 5 minutes. Set the context for why this completed work matters.
- Inspect the completed increment, 15 minutes. Follow the search task in the product. Give stakeholders room to examine the result and ask about behavior.
- Discuss evidence and changed needs, 15 minutes. Ask what the result means for their work and whether the surrounding needs have changed.
- Consider adaptations, 10 minutes. Connect possible next priorities to the discussion. Distinguish a suggestion from an accepted backlog change.
- Read back decisions and open questions, 5 minutes. Identify which changes need follow-up and who will return with the missing information.
Fifty minutes is an example allocation. The task and discussion should determine the detail you need; do not spend the available time reporting individual activity simply because it is easy to put on slides.
Trace the next proposal to a question
Suppose the filter demo raises an unanswered question about whether users can distinguish document labels. The proposed adaptation is to investigate label clarity before increasing the scope of export. That proposal is conditional: the team needs actual feedback before deciding its priority.
Write the chain explicitly:
Evidence inspected: Completed type-filter behavior on the supplied dataset.
Question still open: Are the labels meaningful to the stakeholders who search for these documents?
Proposed next step: Product Owner to arrange a label review and consider its result in backlog ordering.
Decision status: Proposed; no stakeholder response supplied.
Keep completed evidence, unfinished work status, and proposed adaptations in separate parts of the packet. Read the label-review proposal back against the open feedback question: it is an investigation to consider, not a response stakeholders have already given. An HTML briefing can map that discussion; use the working product for the actual inspection.
Build your review packet from actual evidence
Write a sprint review meeting agenda in US English.
Sprint and meeting duration: [enter]
Product Goal and Sprint Goal: [paste]
Stakeholders and the task they need to inspect: [enter]
Completed work meeting our Definition of Done: [paste with evidence references]
Definition of Done: [paste]
Unfinished work, for backlog status only: [paste]
Known changes in stakeholder needs: [paste or NOT SUPPLIED]
Actual feedback already received: [paste or NOT SUPPLIED]
Maintained Product Backlog: [enter]
Allocate time for context, inspecting completed work in the product,
stakeholder discussion, adaptations, and read-back. Times must sum to the
meeting length and be labeled proposed. Keep unfinished work out of the
completed demonstration. Link each proposed adaptation to supplied evidence
or an explicitly open question. Do not invent test results, stakeholder
quotes, approvals, or product outcomes. Missing feedback stays NOT SUPPLIED.
Return a text agenda and evidence/question/adaptation record. If requested,
include an HTML briefing with separate completed-evidence and proposed-
adaptation views, plus clearly separate unfinished backlog status. Do not
claim the briefing proves work is Done or collects stakeholder responses.
At the close, ask which proposed adaptation the group actually discussed and what remains unanswered. Put resulting backlog changes in the maintained Product Backlog. Leave future reviewers with the inspected evidence and the reason for the change, not an unsupported claim that the demonstration was a success.
Optional: read the review outline in NOS
NOS can save and display an HTML briefing that pairs the demo task with the questions you intend to ask. Use the product itself for inspection and its actual records for completion evidence. The briefing can help prepare that conversation without becoming another product-status record.