The Sprint Review That Became a Ticket Tour
A payments company runs Scrum with two teams working on one product in four-week Sprints. The Sprint Review is held in a meeting room with twelve attendees: the Product Owner, both teams, and six stakeholders from sales, compliance and operations. For the last three Sprints the Product Owner has spent the first forty minutes walking through completed Jira tickets slide by slide, then asked, 'Any questions?' The final ten minutes are used by the program manager for a status update. Two stakeholders have stopped attending. Last Sprint one team showed nothing at all because its lead judged the work 'not finished enough to demo'. Afterwards the compliance stakeholder said, 'I still don't know what I'll be able to tell the regulator next month.' A sponsor has concluded that the answer is to shorten Sprints to one week so that 'more gets reviewed'. The Scrum Master has been asked to fix the Review.
1. What is the most accurate diagnosis of why this Sprint Review is failing, and what should the Scrum Master change first?
Read the worked answer
The Review exists so that the Scrum Team and stakeholders inspect the Increment and adapt the Product Backlog. Everything in this setup blocks that single purpose. A ticket walk-through shows activity, not a usable product; the program manager's status slot consumes the time that should go to inspection and adaptation; and withholding work that is 'not finished enough' removes transparency about what is genuinely releasable. Attendance is a symptom, not the cause - two stakeholders stopped coming because nothing in the room changed their decisions.
So the first change is to the shape of the event, not its frequency. Replace the ticket tour with a working session: a compliance officer runs a real report end to end against the Increment, an operations user tries the flow they care about, and the Product Owner opens with the Sprint Goal and what changed in product value. Unfinished items are shown too, with their status against the Definition of Done - an incomplete item is information, not embarrassment. The final third belongs to stakeholders and the Product Owner reordering the Product Backlog visibly, in the room. The status update moves outside the event; the Scrum Master should negotiate that boundary directly rather than letting it quietly erode the Review.
2. The sponsor wants one-week Sprints to increase how often work is reviewed. How should the Scrum Master respond, and what evidence would justify actually changing the Sprint length?
Read the worked answer
The sponsor's premise is that more frequent Reviews produce more inspection. But inspection is currently near zero regardless of cadence: a forty-minute ticket tour reviewed weekly is still a ticket tour. Shortening the Sprint also raises overhead - more Planning, Reviews and Retrospectives per unit of work - and can push the team toward smaller, safer items that fit a week, which may or may not be valuable to the regulator.
Sprint length is a decision for the Scrum Team, chosen to balance the cost of change against the frequency of inspection. The Scrum Master should say plainly that the Review will be rebuilt first, then measure over two or three Sprints whether inspection is actually happening: how many Product Backlog ordering changes came out of each Review, whether stakeholders used the Increment, whether compliance questions got answered. If those signals improve at four weeks, the sponsor's problem is solved without shortening. If the team genuinely cannot produce a Done Increment that stakeholders can react to within four weeks - or the market changes faster than that - a shorter Sprint becomes a reasoned experiment with a hypothesis, not a punishment. Offer the sponsor that path and the data that would trigger it.