A Demo

Demonstrations reflect the output of the team, i.e. the value they created during a sprint. Because of the pressure to “show” value there is a tendency for immature Agile teams to add all sorts of interim deliverables to the demo. Assuming that you are involved in a software project, an Agile demonstration would be based on working software. Lists of code, PowerPoint slides and status reports should be avoided.

The demonstration, led by the Product Owner, shows how the unit of work was completed. In the best case scenario, the stakeholders get to exercise the functionality. By seeing and exercising the software stakeholders are in a great position to provide feedback about what they need or don’t need and about new ideas that might have been triggered. Only the units of work (also known as stories) that are done should be included in the demonstration. The word “done” has a special meaning in Agile. Done is defined as the task required to make the software shippable/implementable. The definition of done usually includes design, coding, testing (various flavors) and documenting. These tasks are completed during the sprint.

Items such as code (the printed representation), status reports, graphs or PowerPoint slides do not represent progress. PowerPoint slides are very rarely installed in production as operational software. Anything that does not fall into the category of implementable software is not demonstrable. I have seen perfectly fine demos that begin with a a slide showing a list of stories that were in the sprint, a few minutes of a preamble describing how a demo works and a flip chart showing the burn-down chart for the sprint and the program.  While these are really barnacles (add-ons) attached to the demonstration they didn’t distract from the real measure of progress.

Demonstrations are a tool to solicit feedback by presenting working software (if this is a software project). Demonstrations are not status meetings or platforms for presentations or for reading code, showing PowerPoint slides or graphs as a proof that work has been accomplished. The point is to show what has been completed and could be implemented. That gives the stakeholders the best understanding of direction and allows them to supply targeted feedback based on knowledge.