How to get more out of every sprint demo

The sprint demo is the recurring point where you, as the client, actually see what you’re paying for. Yet it often gets used passively: the team shows, the client nods, everyone moves on. That wastes your best checkpoint. With the right questions and the right focus, the demo instead becomes a sharp steering tool. Here’s what to review, follow up on, and say.

Tell done from almost done

The most common way a demo misleads is by showing “done” as a successful ideal path. The feature works exactly as long as everything is entered perfectly – but the edges are missing. Your job is to tell genuinely done from almost done.

Here’s how:

• Ask to see it run live, not described or shown along a prepared successful path.
• Ask what happens when something goes wrong – empty fields, invalid input, a dropped connection.
• Test it yourself if you get access. Your hand on the keyboard finds what the team’s prepared demo avoids.

If the team can’t show the feature actually working, including when it breaks, it isn’t done. That’s a friendly but firm stance: “almost done” isn’t done, and it’s cheaper to know that now than at launch.

Follow up against the sprint goal and the budget

A demo that looks good feature by feature can still hide two bigger problems: that you missed the sprint’s actual goal, or that the money is running out faster than the work gets done. So lift your gaze from the individual features.

Check budget usage against remaining work in particular. If you’ve used half the budget but only a third of the work is done, that’s a warning sign worth acting on immediately – far better to catch it in a demo mid-project than in a final invoice.

Give feedback the team can act on

Your feedback is only worth something if the team can act on it. Vague feedback creates another round of guessing; concrete feedback becomes a buildable task. The difference lies in pointing at what’s observable.

• Weak: “That feels a bit off.”
• Strong: “When I submit the form without an email address, nothing happens – I want to see a clear error message.”

Describe what you saw, what you expected instead, and ideally why it matters. Then the team can go straight from your comment to an action, without first having to interpret what you meant.

A concrete scenario

Say the team demos a new booking feature, and it looks flawless when they book a slot. You ask to try it yourself, attempt to book a slot that’s already taken, and nothing happens – no warning, no explanation. You note it concretely: “on a double booking, I want the customer to know the slot is taken.” Then you ask about the sprint goal, which was “the customer can book and cancel” – and it turns out cancellation didn’t get done in time. Finally, you check the budget and see it’s on track.

In twenty minutes, the demo has given you three things: a real bug caught, an insight that the goal was only partly reached, and a budget check-in. That’s the difference between watching and steering.

Prepare – that’s where the value gets created

The active demo doesn’t start when the meeting starts, but before. Read through what the sprint was supposed to deliver in advance, so you can check against that instead of just reacting to whatever happens to be shown. Have your questions ready. If you get access to what’s been built, try it yourself before the meeting – then the demo can be spent on the interesting questions instead of a first walkthrough.

A prepared client asks better questions, catches more, and also signals to the team that the demo is taken seriously. That raises the quality of what’s shown next time too: a team that knows the client tests the edges gets sloppier with them less often. The opposite holds just as strongly – a client who always nods things through teaches the team that a nice happy path is enough.

Preparing with the sprint’s goal in hand is the difference between watching and steering – it ties into how you take on the client role more broadly. Want to know how our demos are set up? Get in touch.