Review & Showcase Techniques

---

Origins

The sprint review has been part of Scrum since the original Scrum Guide.¹ Its stated purpose is simple: inspect the increment and adapt the backlog. Its actual practice in most organizations is harder to recognize — a parade of slide decks, a passive audience of stakeholders, a rehearsed demo of features the team built, and a tepid round of applause before everyone returns to their inboxes.

The drift is structural. Reviews tend to inherit the muscle memory of older governance rituals — steering committees, milestone gates, status briefings — and become performances of progress rather than working sessions. Recovering the review means deliberately re-shaping it: who is in the room, what they look at, and what conversation the event is designed to provoke.

What the Review Is For

Three outcomes, in order of importance:

• Feedback on the increment. Real users, real stakeholders, real reactions to the actual product. Not slides about the product.
• Re-grounding in outcomes. What did this sprint move? What did it not move? What did we learn about the bet we were running?
• Adapting the backlog. The next sprint’s shape is the output of the review, not an unrelated planning session that happens to come after it.

A review that produces none of these is a status meeting in costume. The single most important indicator that a review is healthy is whether the backlog actually changes as a consequence of it.

Common Anti-Patterns

• Demo theatre. The team shows polished, rehearsed flows that bear little resemblance to how the product is used. Stakeholders nod. Nothing changes.
• One-way broadcast. The team talks; stakeholders listen. No questions, no debate, no shift in plan.
• Closed-door demo. Only the team and the PM attend. Stakeholders find out about the work through release notes weeks later.
• Slide-heavy showcase. A deck about what was built, instead of the built thing itself.
• Acceptance theatre. The PO formally “accepts” items in the meeting, turning the review into a ceremonial sign-off rather than a conversation.

Techniques That Work

Live, hands-on use

The strongest reviews put the product in the hands of stakeholders during the meeting. If the audience can click, type, and try to break it, the conversation becomes specific instantly. “I assumed the search would filter as I typed — does it?” is a kind of question that does not happen during a slide.

Outcome framing, not feature listing

Open the review with the bet, not the backlog. This sprint we were trying to reduce the drop-off in checkout step three. Here is what we did, and here is what the funnel now shows. The features become evidence rather than the subject.

Showcase by user journey

Instead of marching through tickets, walk through the experience end-to-end as a user would. Tickets fall into the journey naturally. Gaps and seams show up that no ticket-by-ticket demo would surface.

Stakeholder-driven exploration

Invite a stakeholder to drive part of the demo. “You wanted this — try it.” Genuine first-encounter friction surfaces that the team can no longer see.

Open backlog at the end

Close the review with the next slice of backlog visible on screen. Ask: given what we just saw, is this still the right next bet? The backlog becomes a living document, not a frozen artifact.

The Showcase as a Separate Event

Some organizations separate review (small, working, internal) from showcase (broader, communicative, periodic). This can work, but only if the smaller review remains the place where the backlog actually adapts. The showcase becomes a communication ritual for a wider audience — useful for alignment, but not a substitute for the working review.

Where this separation fails is when the showcase becomes the only event and the smaller review quietly disappears. The team then optimizes for the showcase — polish, narrative, big reveals — and loses the rough, useful conversation that produced real change.

Who Should Be in the Room

The right answer depends on the work, but a useful default:

• The whole team.
• The product owner (driving, not presenting).
• Two to four real users, or proxies as close to real as you can find.
• One or two key stakeholders — funders, partners, dependent teams.

What you want to avoid is a room dominated by people whose only role is to watch. If half the room is silent observers, the meeting will drift toward performance.

Coaching Tips

Ban slides for one quarter.

Force the team to show the product itself. The withdrawal symptoms reveal what slides were hiding.

Open with the bet, not the burndown.

Two sentences: what we were trying to move, and what the evidence says now.

Hand the mouse over.

Let a stakeholder drive part of the demo. Watch where they hesitate — that is where the design has a gap.

End on the next slice.

Put tomorrow’s backlog on screen for the last five minutes. Ask is this still right?

Count the questions.

A review with no stakeholder questions is broken. If the audience is quiet, redesign the format.

Track what changed because of it.

After each review, write one line: what did we adjust as a result? If the line is blank for three sprints, the review is decoration.

Summary

A healthy review feels less like a presentation and more like a tasting menu — small, specific, hands-on, and ending in a different opinion than the one you walked in with. The format is a small ritual, but its effect on direction is outsized: a good review can change what the team works on tomorrow, and a bad review reliably will not.

Back to Agile Delivery