"It works" is doing a lot of quiet work in most status updates. Working for a screen recording and working for the acceptance criteria are different claims, and we now insist teams say which one they mean.
The demo bar is lower than it looks
A demo runs a rehearsed path, with data the presenter chose, on a machine the presenter controls, watched by people who are not trying to break it. None of that is dishonest. It is simply a much easier bar to clear than "ready to ship", and mistaking one for the other is how a feature that looked finished in a Thursday demo turns out to need another two weeks once QA gets at it.
What we require before something is called review-worthy
- The acceptance criteria are checked off individually, not assessed as a general impression of "looks done".
- It has been run against unrehearsed data — real or realistic, not the tidy example used in the demo.
- Someone other than the author has operated it, because authors unconsciously avoid the inputs that break their own code.
A feature can fail this bar and still demo beautifully. That gap is exactly what the bar exists to catch.
Where the confusion causes the most damage
Status reporting upward. "Feature X is done, we showed it in the sprint review" travels up a chain of people who were not in the room to see which path was rehearsed, and by the time it reaches a delivery date commitment, "demoed" has quietly become "shipped" in everyone's head except the engineer who actually knows the difference.
A demo answers "can this work". A review answers "does this work, reliably, for the cases we did not choose". Reporting the first as though it were the second is how a project looks on schedule right up until it isn't.
The language we use now
We ask teams to state explicitly, in updates, whether something is "demoed" or "verified", and we do not let the words be used interchangeably. It is a small vocabulary discipline that has caught more than one status update that would otherwise have overstated where a feature actually stood.
What this is not
It is not an argument against demos, which remain useful for exactly what they are good at: showing stakeholders a shape early, gathering feedback on direction before investing further. It is an argument against letting a demo's success stand in for a review that has not actually happened yet.