tutorial
Scrum, day 17: a Review that informs the next decision
Today's objective: use a Sprint Review to connect the usable product, stakeholder feedback, and changes in the environment to a possible next step.
Read alongside: Scrum.org's Sprint Review reference and Scrum: A Pocket Guide, fourth edition, §2.5, focusing on the Sprint Review. Allow roughly five minutes for this companion, plus the assigned reading.
Bring a result that stakeholders can inspect
Near the end of our fictional ShiftSwap Sprint, employees can see a readable decline explanation and the next permitted action. The behavior works for the record types included in the release, satisfies the team's Definition of Done, and has been introduced to a small pilot group.
The automatic invitation shortcut was deferred. Employees can still follow the explained next step through the existing request flow. The team needs to inspect whether this result helps people understand a decline without asking the manager to interpret it.
A presentation listing completed tickets would establish activity. The Sprint Review needs a richer conversation about the result, progress toward the Product Goal, and what has changed. A demonstration can give everyone a shared basis for that conversation.
Prepare the questions that need other perspectives
Elena invites the relevant employees, café managers, and business sponsor to work with the Scrum Team. The participants do not all need the same technical knowledge, but they should be able to contribute information about the product and its context.
The team prepares three questions. Can employees understand the explanation? Does the suggested next action fit the café's actual policy? What have participants observed that could affect the next improvement?
It also prepares an honest account of the evidence. In this invented pilot, four employees tried the completed flow. Three found the next step without help. One understood the reason but was unsure whether a different colleague could be invited after a manager's decline. Four observations can reveal a useful issue; they do not establish success across every employee and situation.
The people attending should not need a long sequence of internal ticket numbers to understand what the team is trying to learn.
Use the product to make disagreement concrete
During the Review, an employee walks through a declined request. The team shows the actual usable behavior, including the explanation and available next action. The manager then describes an exception: when a swap is declined because the shift needs a particular qualification, inviting another colleague is useful only if that person has the qualification.
The interface already checks eligibility before a request can be completed, but the explanatory text does not make the constraint clear. The employee's hesitation now has a plausible explanation. The team can discuss a precise improvement rather than collecting a broad comment that the screen should be “more intuitive.”
The automatic invitation shortcut remains unfinished. The team can explain that fact and its consequence for the goal without demonstrating it as part of the Increment. Making the difference visible preserves the meaning of completed work.
Include changes outside the product
The sponsor explains that another café wants to join the pilot next month. Its manager expects different eligibility rules. That information affects the product's future, even though it is not feedback about the screen being demonstrated.
The group considers the current Product Goal: dependable exchanges at the first two cafés. The new interest may be encouraging, but the team still has unresolved questions about those locations. Expanding immediately could multiply the ambiguity rather than resolve it.
The Review creates an opportunity to discuss that trade-off with the people affected. It does not require the team to accept every suggestion made in the meeting. Nor does it turn a stakeholder vote into a substitute for Product Owner accountability.
Turn feedback into an inspectable next step
Elena works with the participants to distinguish observations, proposed solutions, and questions requiring further investigation.
| Input from the Review | What it tells the team | Possible next step |
|---|---|---|
| An employee hesitates over inviting a different colleague. | The suggested action may lack enough context. | Clarify the eligibility explanation and check it with users. |
| The manager describes a qualification constraint. | A rule is understood differently by different participants. | Add concrete examples to the relevant backlog work. |
| Another café wants to join. | The potential audience is growing. | Investigate its differences before committing to expansion. |
The Product Backlog can change as a result. Elena may reorder improvements or add a question that needs attention. The Developers contribute information about the work and its implications. This provides useful input to the next Sprint Planning, without pretending the next Sprint has already been fully planned.
Scrum.org describes the Review as a working session about outcomes and future adaptation. The quality of the resulting decisions matters more than how polished the presentation appears.
Keep the Review distinct from a release gate
The team released the usable decline improvement to the pilot before the Review. Scrum permits that. Waiting for the event would have delayed feedback that now helps the group inspect the result.
Release decisions can still depend on product and operational considerations. The point is that the Scrum framework does not make stakeholder applause or a Product Owner signature at the Review the condition that turns work into a Done Increment.
The Review has a maximum four-hour timebox for a one-month Sprint and is usually shorter for shorter Sprints. A shorter event can be effective if participants have the relevant information and time to work through the decisions. Merely shortening a one-way presentation does not create collaboration.
Prepare a Review around a decision
Choose a recent usable product change. Write the goal it was intended to advance, what is actually Done, what remains incomplete, and what has been observed in use. Identify the people whose perspectives could change the next decision.
Prepare one concrete example they can inspect and two questions that allow them to challenge your interpretation. After the conversation, record the proposed adaptation and the information still missing.
Reflection: if stakeholders watched your demonstration and said only “looks good,” what question would help uncover whether the product supports their actual work?
The next companion turns from the product's future to how the team can improve its own way of working.