20130620-211537.jpg

Demonstrations come in many sizes and formats. Some are concise affairs while others are long and labored. Some are interactive and conversational while others are grand presentations with information being shared in one direction. The more complex and unidirectional the conversation the less interesting the demonstrations are for attendees. Interesting and focused demonstrations can be accomplished using a few basic techniques. Good demonstration requires context, preparation and execution.

Sprints begin with work being accepted by the team into the sprint. The work that the team accepts into the sprint provides the context of the demonstration. The goal of taking work into a sprint is to complete all of that work based on the overall definition of done and as proved by completing all acceptance criteria. Work that does not meet the definition of done should not be demonstrated. When not completed the team needs to communicate that they were not able to complete the work and return the unit of work to the backlog then move on to the units of work that were completed.

Preparing for a demonstration includes beginning with the end in mind. As units of work are accepted into the team should ensure that the acceptance criteria are written that so they can demonstrate the team met the definition of done. A second step in the preparation process is to have the team walk through the demo prior to do it live. I believe that the product owner should facilitate the demonstration, explaining how the team has solved the business problem and soliciting interaction and feedback. Therefore a bit of practice is always good idea to ensure the product owner is not caught flatfooted. Demonstrations in which the team fumbles around or solicits interaction and feedback and the software isn’t accessible is at best comedic and at worst gut-wrenching.

When it is time for the demo, execute according to the plan. I suggest beginning with a bit of preamble such as explaining what a demo is, for any new attendees, introduce the team and then let everyone know which units of work will be demo’ed and which won’t. Then demo the units of work one by one. Explain the unit of work, walk through an execution of the acceptance criteria, solicit interaction with the software (if appropriate) and finally ask for feedback. As noted before I have found that having the product owner facilitate the demo supported by the technical team is most effective for getting stakeholder involvement and feedback. Keep the process concise without being clipped or abrupt. At the end of demonstrating each unit of work it should be easy to determine if the stakeholders believe the units of work are complete, if there are issues that will require the unit of work to be returned to the backlog or if new backlog items have been identified.

Demonstrations can be done using a simple, repeatable process that straight forward and to the point. By making sure the process is interactive and the material concise all of the participants will find the demo engaging and focused.

Advertisements