Demo Scripting

Recently we've started a simple, but very effective, process to help our Agile Scrum demo's go smoothly. We write up a short document, called a Demo Script, that describes what we're going to demonstrate for the sprint, and pass it out to the stakeholders before the demo starts. It's very simple, but it has lots of benefits.

Benefits of a Demo Script

1. Start a demo script at sprint planning to begin to understand what will be shown to the Stakeholders. This helps get the creative juices flowing about how the functionality in the sprint is going to be deployed and demonstrated. Some deployments can be very complicated. Getting the team thinking about the end is a good way to mitigate risk and keep the team focused on the right goals. Clearly, the script will change as the sprint progresses, but it should roughly correspond to the commitment that the team makes to the Product Owner.
2. Allows the team some think-time to understand if a particular environment needs to be setup or updated to allow for final demonstration or production deployment.
3. Gives the team a way to write down and walk through the steps they intend to take during the demo (pre-demo demo). This should be more than just a list of stories. It could list specific pages in a website that are visited, usernames/SKUs to look up, particular emails that are sent, or whatever it is that the product is doing. Writing down the steps helps the team understand clearly what they are going to be showing.
4. Gives the stakeholders something they can look at before the demo so they know if they need to be there, be prepared, or pay more attention in particular sections. Provides them a reference for the new functionality to keep with them. Provides an instrument to discuss potential changes or impacts to future/other work/products.
   
5. Helps the team practice in a room if the demo is in a place that isn't dedicated for that or that needs to be changed for some reason.
   
6. Provides a simple release notes of sorts (in lieu of some other more rigorous form).
7. Provides a common point of reference for the team to drop or add an item quickly, before the demo (depending on how soon you send it out).
8. When the team successfully demonstrates all the done functionality on the script, it becomes a statement of their success. Since things that aren't done, aren't demonstrated, the stakeholders are left with a clear understanding of what was accomplished.
9. Provides a way to reference work that didn't have visible outcomes. We always try to link actual end user functionality to every story, however sometimes those stories produce work that is not really demonstrable without taking more time than necessary (like on a sprint where there is no deployment potentially). This hard work needs to be made visible and this provides a simple way to do that.
10. Provides a simple list that support functions in the organization can reference in other discussions to form more complete documentation.

Tips on building your Demo Script

1. Have a good title - Name of team/sprint
2. List the team members names, including the Product Owner
3. Include a list of stories for sprint that have been completed
4. Include a list of steps that will be taken during demo, and then stick to them.
5. Remember to include done and undone work (retain visibility for accountability)
6. Don't include anything that distracts from the work of the team for that sprint. Other documents can fully describe things that need more work, bug lists, future stories, retrospective reports, etc. Including too much can detract from what is being presented.

The Demo Script is, in a sense, both a working document and a marketing instrument for the team. It clearly shows what is done and provides a high level view of the status of the sprint for the stakeholders and user representatives. Use a Demo Script to bring visibility to the hard work completed by the team. <><