Sprint Demo Protocol: Show Working Software Every Sprint

The sprint demo started, as it had every fortnight, with a deck. Twelve slides walking the stakeholders through what the team had built. Screenshots of completed UI. A list of tickets moved to Done. A short video, recorded earlier, of a feature that wasn't yet deployed anywhere a stakeholder could reach. The stakeholders nodded, asked two questions, approved the sprint. Five months later, at launch, the product they saw running on staging for the first time was not the product they thought they had been approving since week one. Each fortnight's "demo" had quietly drifted from "show working software" to "report on work in progress," and nobody in the room had the artefact in front of them to spot the gap.

A sprint demo protocol is the structured cadence that prevents that drift. The demo's job isn't to summarise what the team did. It is to put working software in the stakeholder's hands while there is still time to change direction. The Built to Last™ 2.0 framework treats the sprint demo as the working cadence that makes "no surprises at handover" structural rather than aspirational. A real demo is a live system running in staging that the stakeholder can click through, test, and challenge. A status meeting with screenshots is a different ritual entirely — and one that lets a six-month build land at launch as a surprise.

What follows is a walkthrough of the protocol: how the demo is set up, what happens in the room, what stakeholders are expected to do during it, and what gets written down at the end. The protocol is small. It fits in a fortnightly hour. The cost of skipping it is the build that drifts for five sprints before anyone notices.

Why Status-Meeting Demos Fail

The reason fake demos persist is that they feel productive. The team has prepared. The stakeholders are briefed. Tickets have moved across the board. Everyone leaves the meeting confident that the sprint went well. Confidence is not the same as alignment.

The mechanism is straightforward. A screenshot shows one frame of one screen at one moment. The stakeholder accepts what they see at face value because they have nothing else to test it against. The team, knowing the demo is the deliverable, optimises for the demo: they prepare the screen that looks best, the path that works cleanly, the feature that demos well. The seven adjacent flows that the user will actually take in production are not in the deck because they were not ready to show. Each sprint's deck repeats the pattern. By sprint eight, the product on staging has accumulated a list of small drift items that the slides never surfaced. A few are cosmetic. Two are structural. One is going to require a rework that costs four weeks.

The cost of the pattern is rarely a single dramatic moment. It is a launch that opens with the founders saying "this isn't what I thought we were building." That conversation is expensive in three ways: the rework itself, the time-to-launch slip while the rework happens, and the relationship damage that compounds across every subsequent sprint. The sprint demo protocol exists to convert all three into a fortnightly hour of friction instead of a single end-of-build crisis.

What a Real Sprint Demo Is

A real sprint demo is a live demonstration of working software running in a staging environment that stakeholders can access independently. The software does what the sprint's user stories said it would do. The stakeholders are able to click through it themselves, ask questions while it is running, and form their own view of whether it matches the intent of the work. The output of the demo is a written decision: accepted, accepted with notes, or sent back for changes.

That definition rules out a number of common substitutes. A slide deck of completed tickets is not a demo. A pre-recorded video is not a demo. A walkthrough on the developer's laptop that nobody else can reach is not a demo. A description of what will be ready next sprint is not a demo. The bar is that the stakeholder can interact with the software at the time the demo happens, and that interaction is the source of the feedback the team takes back into the next sprint.

The protocol applies across service lines. It runs the same way for a custom software build, a website rebuild, and an embedded team engagement — only the surface changes. The cadence is what holds the engagement honest.

How a Sprint Demo Runs, Step by Step

The protocol has six steps. Each is small. Skipping any of them is the difference between a demo and a status meeting.

Step 1: Confirm the Staging Build Is Live and Reachable Before the Demo Starts

The first step happens the day before the meeting, not in it. The team confirms that the sprint's completed work is deployed to a staging environment, that the environment is up, that the stakeholder's credentials still work, and that the path through the new features has been walked at least once by someone who didn't build them.

This step exists because the most common reason demos slip into status mode is that the software isn't ready to be touched. If the deploy is broken, the demo will pivot to slides — and once it pivots once, it pivots every fortnight after. Pre-flighting staging the day before is the protocol's structural defence against that drift.

For teams running our delivery cadence on custom software, the staging check is a named pre-demo task in the sprint, not a "we'll see on the day" assumption. The cost is small. The benefit is that the demo is always a demo.

Step 2: Open the Demo by Running, Not Talking

The second step is to start the meeting by opening the staging URL on screen and walking the new functionality. Not by reciting the sprint goals. Not by recapping the tickets. The first three minutes are working software being used. Everything that needs to be said about the work can be said while the software is being demonstrated.

Starting with the software is a discipline. It rules out the deck. It rules out the warm-up of "here's what we did." It puts the stakeholder in front of the artefact before any framing has been applied. If the work doesn't survive the first three minutes of a stakeholder watching it run, the sprint had a problem that the protocol has now surfaced — which is the point.

Step 3: Hand the Keyboard to the Stakeholder

The third step is the one that separates demos from presentations. After the team walks the new functionality once, the stakeholder is given access to test it. They click through the flows themselves. They try the path they would expect a user to take. They press the buttons the team didn't necessarily prepare for.

This step does two things at once. It surfaces the gap between "works on the happy path the team demoed" and "works on the path the user actually takes." It also signals to the stakeholder that the demo is something they participate in, not something performed at them. The stakeholder leaves the meeting having tested the software, not having watched a video of it.

For embedded engagements the stakeholder might be a product owner inside the client team rather than an external founder, but the protocol is identical. The keyboard moves.

Step 4: Capture Feedback in Writing, in the Room

The fourth step is the team's job. As the stakeholder tests, someone on the team is writing down every comment, every question, every "that's not what I expected" — in the demo doc, visible on screen, in real time. Feedback that goes into a Slack thread later is feedback that gets re-litigated later. Feedback written down at the moment it was said is feedback that can be tracked into a decision.

The doc captures three categories: accepted (the work matches intent), needs change (the work needs a defined adjustment before it is accepted), and out-of-scope new request (a new idea the stakeholder had during the demo). Mixing those three is how scope creep enters a build. Separating them is how the sprint demo feeds the change control register cleanly.

Step 5: Make a Decision on Every Sprint Item Before the Meeting Ends

The fifth step is to walk back through each sprint item before anyone leaves and label it: accepted, accepted with notes, or sent back. An item with no label is an item that will be debated three weeks later. The meeting does not end with items unlabeled.

For items sent back, the decision includes what specifically needs to change and which sprint will pick up the work. For items accepted with notes, the notes are written into the next sprint's backlog as defined tasks, not vague intentions. The stakeholder's signoff on the decision is captured — a comment in the doc, an email confirmation, a tick on the agenda — so that "I thought we agreed to X" conversations have a written answer in the future.

Step 6: Publish the Demo Record Within 24 Hours

The sixth step closes the loop. Within a day, the team publishes the demo record: what was shown, what was tested, what was accepted, what changes were committed to. The record is sent to every stakeholder, not only those who attended. The record is the artefact that the engagement can refer back to months later when someone asks what was agreed in sprint four.

For website rebuilds, this record becomes the running log of how the site evolved from launch concept to launched product. For long-running engagements, the demo records collectively form the timeline of decisions that makes month-six conversations productive.

Two Engagements, Two Outcomes

A mid-sized SaaS client (engineering team of around 15) we worked with had run a previous build using sprint "demos" that were slide decks with screenshots and a list of completed tickets. The stakeholder reviewed each deck for around twenty minutes a fortnight and approved the sprint without testing the software. Five months in, at the first staging walkthrough the stakeholder did themselves, the gap between expected behaviour and built behaviour was wide enough that two features needed to be rebuilt. The rebuild added six weeks to the launch. The slides had not been wrong. They had simply not been the artefact that would have caught the drift.

The next engagement with the same team ran on the protocol above. Demo on a staging URL the stakeholder could reach independently. Keyboard handed over in week two. By week four, the stakeholder identified a misalignment in the onboarding flow — the demo recorded it, the team committed to a defined change in sprint three, and by week six the flow had been corrected. The misalignment that had cost six weeks of rebuild on the previous engagement cost two weeks of in-cadence adjustment on this one. The team that demoed was no different. The protocol was.

When the Protocol Is Critical, When You Might Adjust It

The sprint demo protocol is critical for any build where the team and the stakeholder are not in the same room daily — which is most builds. It is critical for fixed-price engagements where scope changes need a written trail. It is critical for any product where the launch has a date attached and end-of-build surprises translate into time-to-market cost.

It can be adapted, not skipped, in specific cases. For an internal-tools build where the engineer and the stakeholder are sitting beside each other every day, the formal demo can collapse into a daily walkthrough — but the written record still gets published every fortnight, because the next person who joins the team needs the trail. For an early prototype that is explicitly throwaway, the demo can shorten to twenty minutes — but the keyboard still moves. The non-negotiable parts of the protocol are the live software, the stakeholder's hands on it, and the written record. Everything else is timing.

What to Do This Week

If your current build has not run a real sprint demo in the last fortnight — staging URL, keyboard handed over, decisions written down — book one for the next sprint boundary. Pre-flight the staging environment the day before. Hand the keyboard over in the first ten minutes. Publish the record within twenty-four hours.

For a wider view of how the demo sits inside the broader delivery discipline, read our project delivery framework. For the full lifecycle context, the journey after you sign the engagement covers how the demos fit alongside discovery, architecture, and launch readiness.

Frequently Asked Questions