Demonstrations Show Progress and Value
The smaller the story, the more the team can demonstrate value. Sometimes the team demonstrates for the product owner. The product owner can then accept, reject, or realize some other future story needs to change. If the team has small-enough stories, the team might demonstrate several times a day.
In addition, the team might demonstrate to other teams, a senior manager, or a customer. In that case help the people demonstrating show the people watching the demo how the product works—a holistic perspective. While a product owner might be fine seeing independent stories, customers or senior managers are much more likely to want to see how the product works.
Make sure your team knows who the demonstration is for, so the team is ready for it. For example, if the team demos to a customer once a month, it might be worth the team’s time to decide who will run the demo. The team might want to (loosely) script the demo to show the customer what’s working now.
Sometimes the product owner drives the demo. Sometimes team members do. Sometimes, depending on the data the team wants, the customer might drive the demo. These are all decisions the team and the product owner can make together.
Demonstrable means the team can show its work to whomever is interested. Releasable means the team could release, at minimum, internally.
If your product has hardware, maybe you demonstrate the progress and you don’t release it. If your team is concerned about releasing a feature before the entire feature set is done, the team might demonstrate it and not release it.
Creating demonstrable but not releasable digital products is a form of WIP. Watch for it and decide what to do about it.
If you have a product with hardware, you might only be able to demonstrate until you have working hardware. The team still has WIP because it can’t check that the product works until the team can marry the software and the hardware. Recognize that the work is not actually done.