Weekly demos in software projects, and what to ask

Every software project that went badly had a status report saying it was going well. That is not because people lie on status reports. It is because a percentage is an opinion with a number attached, and nobody writing one has a way to be wrong in public.

A demo removes that. Either the thing runs in front of you or it does not, and the week it does not is the week you find out, rather than the week before launch.

What a status report cannot tell you

The two artefacts answer different questions, and the gap between them is where projects hide.

The fourth row is the one worth the meeting. Build speed is rarely lost to slow typing. It is lost to building something correctly specified and useless, then rebuilding it, which is the pattern behind most of why software projects take so long.

What the Scrum Guide actually says

Teams invoke Scrum for this and then run something the document does not describe, so it is worth quoting. The Scrum Guide is short enough to read in a sitting, and four lines in it carry the whole argument.

• The purpose is to "inspect the outcome of the Sprint and determine future adaptations". Not to report on it.
• It is "timeboxed to a maximum of four hours for a one-month Sprint", and usually shorter for shorter Sprints.
• It is explicit about the failure mode: "The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation."
• "Work cannot be considered part of an Increment unless it meets the Definition of Done."
• "The Sprint Review should never be considered a gate to releasing value."

Two of those correct the way these meetings usually run. The working session line says that if stakeholders watch silently and then leave, the event did not happen, whatever the calendar claims. The gate line surprises people who were taught to treat the demo as a sign off: the guide is saying value should already have been releasable, not that the meeting is where permission is granted.

Why weekly, when the guide describes a Sprint

Honest answer first: a weekly demo is not Scrum. Scrum ties the review to a Sprint, and Sprints are commonly two weeks. Weekly is a deliberate departure, and it is worth knowing what you are trading.

What you gain is a shorter interval between a wrong assumption and the evidence of it. Two weeks of work built on a misread requirement costs two weeks. One week costs one. For a small team building for a client who has never commissioned software before, that halving is usually worth more than the ceremony it breaks.

What you lose is real. A weekly cadence pulls the team toward work that demonstrates well, which is not always the work that matters. Infrastructure, data migration and test coverage demo terribly and are often the week that saves the project. If the demo becomes the scoreboard, the team optimises for the scoreboard.

The way through is to let a week be boring. A demo that opens with "nothing visible changed, here is the migration running against a copy of your real data" is a good demo. It is also the one teams feel pressure to dress up.

The five questions to ask in one

If you are the client in the room, these five take ten minutes and change what the next week contains.

• Can I drive it? Ask for the mouse. Software that only works in the hands of the person who built it is a demo of a person, not a product.
• What happens with my real data? Seeded data is clean by construction. Your data has a customer called TEST DELETE and three records with no phone number.
• Which part of this is not finished? Asked directly, this is almost always answered honestly. Not asked, it is almost never volunteered.
• What did you learn this week that changes the plan? The answer is the real output of the meeting. If it is nothing for three weeks running, nobody is learning anything.
• What are you blocked on that I own? Access, a decision, a sample file, a person who will not reply. This is usually where weeks go.

What a staged demo looks like

Not every demo is evidence. Four patterns mean you are watching a presentation with a cursor in it.

• Screenshots or a recording instead of a running system, for anything other than a genuinely unavailable environment.
• A path so narrow that any deviation is deflected with "that part is mocked".
• Data that is uniformly plausible. Real data is lumpy and slightly wrong.
• The same two screens every week, explained as backend work. Sometimes true. Three weeks running, ask for a database query and a log.

None of these mean anyone is being dishonest. They usually mean the environment is hard to run, which is itself the finding, because a system nobody can start is a system nobody can test. Asking what evidence a supplier can produce on demand is the same instinct as evaluating a software development proposal properly before signing it.

The Definition of Done is what makes any of this mean something

A demo with no agreed Definition of Done is theatre, because done is being decided live by whoever is most confident in the room. The Scrum Guide puts it as a commitment: the moment an item meets the Definition of Done an Increment exists, and work that fails it returns to the Product Backlog.

For a small project the definition does not need to be elaborate. Merged, deployed to a shared environment, works on a phone, has one test, and the acceptance criterion written in the ticket is satisfied. Five lines, agreed once, and the weekly demo stops being a negotiation about the meaning of a word. Where those acceptance criteria come from is the subject of writing a software requirements document.

There is a people dimension too, and it decides whether anyone tells you the truth in the room. Feedback that arrives as an opinion produces defensiveness and rework. Khaled Badr makes the adjacent point from the client side in how to find the client's real problem rather than the stated one, and a demo is the cheapest place that distinction surfaces.

Honest limits

Three, and the first argues against the practice.

Weekly is too often for some work. A six month data platform with one integration milestone has nothing meaningful to show in week three, and forcing a demo produces a dashboard built to be shown. Match the interval to the smallest unit of real output, which on some projects is a fortnight.

A demo is not a test. It proves the happy path runs in front of an audience. It says nothing about load, security, or the fourteenth edge case, and treating it as assurance is how teams ship something that worked in the meeting. Demos replace status reports, not testing.

The Scrum Guide is a framework document, not evidence. It describes what Scrum is, which is a different kind of claim from a study showing weekly demos produce better outcomes. We have not cited such a study because we did not read one. The argument here rests on a mechanism, that shorter feedback intervals cost less to correct, and on the guide being explicit about the presentation failure mode. Take the mechanism, and if your own projects say otherwise, believe your projects. If the constraint is capacity rather than cadence, that is shipping faster without hiring.