September 8, 2026 · 7 min read
TL;DR: The sprint review is keyed 10 times and offered as a distractor 19 times in this bank. Its job is narrow and consistent: show working product to the people who can accept it or react to it, and adapt the backlog from what they say. Almost every distractor asks it to do something adjacent, inspect the team's way of working, substitute for a report, or stand in for a conversation about expectations that should have happened earlier.
Candidates who can name the five Scrum events still lose marks here, because naming an event is not the same as knowing what it is allowed to decide.
The product, in front of the people who have a stake in it.
The bank states the distinction directly. A business representative is confused about how a sprint review differs from a sprint retrospective, and keyed is that sprint reviews are for product demonstrations while retrospectives are for lessons learned. The explanation expands it usefully: the two events differ on subject, audience, and cadence. The sprint review is about the product, the team demonstrates what is genuinely done to the product owner and stakeholders, feedback is taken, and the product backlog is adapted in light of it.
Three keyed cases follow directly from that definition.
Scope acceptance. On an automotive project developing hardware and software together, keyed is demonstrating the features and obtaining the product owner's approval at the iteration review. Obtaining approval by the route set out in the project management plan is offered and loses as the predictive route, and asking the product owner to give feedback at the retrospective loses because the retrospective examines how the team worked rather than what it built.
Showing progress to a senior stakeholder. A board member wants to attend a meeting to see how delivery of the project scope is progressing. Keyed is inviting them to the next sprint review. Arranging a separate demonstration is the interesting distractor, and the explanation names why it fails: it duplicates an event the team already holds and hides the real one.
Which meetings the product owner cannot miss. With a product owner's calendar overloaded, the keyed pair is sprint planning and the sprint review, because the product owner is indispensable where the work is chosen against their ordering of the backlog and where they accept or reject what was built. The daily stand-up and blocker meeting are the team's own coordination.
Three things, and each substitution has its own record.
The retrospective. A year into a hybrid model, one project is performing worse than others in the portfolio, and the question asks what its manager can do over the next couple of sprints. Raising it with the product owner at the sprint review is offered. Keyed is finding the root cause at the sprint retrospective, and the explanation draws the boundary in one clause: the sprint review inspects the increment with the product owner rather than the team's way of working.
A written report. Senior management asks a team for a written sprint completion report after every iteration. Inviting management to the sprint reviews and letting the demonstration stand in for the report is offered. Keyed is having the team facilitator help the team agree indicators that keep progress visible to management continuously. The explanation says what management actually wants, which is visibility, and rejects both the standing invitation and an emailed burndown for substituting a single artifact of the team's choosing for the continuous view.
A conversation about expectations. In a retrospective, a project manager hears that stakeholders keep complaining at iteration demos that features are not being delivered as requested. Keeping stakeholders out of the iteration reviews to avoid unfocused feedback is offered, and it loses. Keyed is validating the acceptance criteria with the stakeholders before backlog refinement, because the gap is between what stakeholders mean and what the team builds, and it is cheapest to close before the work is estimated and pulled into an iteration.
| The stem's need | Keyed | The sprint review distractor |
|---|---|---|
| Improve team performance | Root cause at the retrospective | Raise it at the sprint review |
| Written progress for management | Agreed continuous indicators | Let the demo stand in for the report |
| Stakeholders say features are wrong | Validate acceptance criteria before refinement | Keep stakeholders out of reviews |
| A forum's proposal was overruled unannounced | Go back and explain what drove the decision | Invite them to the next iteration review |
| Surprise technical hurdle mid-project | A continuous risk management process | Schedule mid-sprint reviews |
| Two functions briefed different purposes | Leads state one shared purpose together | Send representatives to every review |
Common trap: using a demonstration where an explanation is owed. A technicians' forum spent two months on how repeat prescriptions should be queued, the project took a different route for supplier-interface reasons, and nobody told them. Inviting the forum to the next iteration review, where they can see the working software, is offered. Keyed is going back to the forum with what happened to their proposal and what drove the decision. The explanation is worth carrying whole: an iteration review shows them a result without explaining the choice. This is the sharpest version of the pattern in the slice, because showing working software is genuinely the strongest thing agile does, and it still does not answer why someone's contribution was discarded. The bank explains this rather than just marking the option wrong, which is what makes the boundary learnable rather than arbitrary.
Read for the subject and the audience, not the format.
The bank tests this repeatedly with near-identical wording. Each member stating in round-robin order what they finished, what they plan next, and what is blocking them is the daily coordination meeting, not the sprint review, and the explanation says the blocker report is what identifies it. The event where the team decides what its responsibilities will be is sprint planning, because that is where members decide who works on which tasks. The change control board is not a Scrum event at all, being a governance body from predictive delivery.
Closing is the one that catches people. Asked when closing activities begin on an iteration-based agile project, the sprint review is offered along with the retrospective and meeting the definition of done. Keyed is at the time of a release. The explanation notes that all three of those occur at the end of an iteration and are needed before closing can begin, but the reverse is not true, and a release often spans multiple iterations.
One more is worth knowing because it tests the review's value rather than its definition. Asked what can be eliminated to maximise value, sprint reviews are offered alongside daily stand-ups and testing. Keyed is unnecessary features, because lean thinking treats functionality nobody uses as the largest single source of waste in product development. The ceremonies are not the waste.
What is the difference between a sprint review and a sprint retrospective? The review is about the product: the team demonstrates what is genuinely done to the product owner and stakeholders, feedback is taken, and the backlog is adapted. The retrospective is about the team's way of working. They differ on subject, audience, and what changes as a result.
Is the sprint review where project scope gets approved on an agile project? Yes, increment by increment. The bank keys demonstrating the features and obtaining the product owner's approval at the iteration review, rather than following an approval route set out in a project management plan, which is the predictive equivalent.
Can a sprint review replace a written status report for management? No. When management asks for a written completion report after every iteration, the bank rejects inviting them to sprint reviews and letting the demonstration stand in for the report, and keys agreeing indicators that keep progress visible continuously.
Should stakeholders be kept out of iteration reviews if their feedback is unfocused? No. That option is offered as a distractor and loses. When stakeholders complain at demos that features are not as requested, the keyed answer is validating acceptance criteria with them before backlog refinement, which fixes the gap earlier rather than removing the feedback.
PMP Practice's 2,141 questions are certified against PMBOK 8 and the July 2026 ECO, with every wrong answer explained rather than just marked wrong. Start the free 20-question sample — no card, no signup required to try it.
Related reading: Which Ceremony? 50 Keyed, 115 Distractors, and the Wrong Event Is Always on the List and Continuous Improvement: Retrospectives, Lessons Learned, and What the Exam Actually Rewards. Delivery tasks are mapped on the Process domain study page.
What is the difference between a sprint review and a sprint retrospective?
The review is about the product: the team demonstrates what is genuinely done to the product owner and stakeholders, feedback is taken, and the backlog is adapted. The retrospective is about the team's way of working. They differ on subject, audience, and what changes as a result.
Is the sprint review where project scope gets approved on an agile project?
Yes, increment by increment. The bank keys demonstrating the features and obtaining the product owner's approval at the iteration review, rather than following an approval route set out in a project management plan, which is the predictive equivalent.
Can a sprint review replace a written status report for management?
No. When management asks for a written completion report after every iteration, the bank rejects inviting them to sprint reviews and letting the demonstration stand in for the report, and keys agreeing indicators that keep progress visible continuously.
Should stakeholders be kept out of iteration reviews if their feedback is unfocused?
No. That option is offered as a distractor and loses. When stakeholders complain at demos that features are not as requested, the keyed answer is validating acceptance criteria with them before backlog refinement, which fixes the gap earlier rather than removing the feedback.