Demonstrations are an important tool for teams to gather feedback to shape the value they deliver.  Demonstrations provide a platform for the team to show the stories that have been completed so the stakeholders can interact with the solution.  The feedback a team receives not only ensures that the solution delivered meets the needs but also generates new insights and lets the team know they are on track.  Demonstrations should provide value to everyone involved. Given the breadth of participation in a demo, the chance of a distributed meeting is even more likely.  Techniques that support distributed demonstrations include:

  1. More written documentation: Teams, especially long-established teams, often develop shorthand expressions that convey meaning fall short before a broader audience. Written communication can be more effective at conveying meaning where body language can’t be read and eye contact can’t be made. Publish an agenda to guide the meeting; this will help everyone stay on track or get back on track when the phone line drops. Capture comments and ideas on paper where everyone can see them.  If using flip charts, use webcams to share the written notes.  Some collaboration tools provide a notepad feature that stays resident on the screen that can be used to capture notes that can be referenced by all sites.
  2. Prepare and practice the demo. The risk that something will go wrong with the logistics of the meeting increase exponentially with the number of sites involved.  Have a plan for the demo and then practice the plan to reduce the risk that you have not forgotten something.  Practice will not eliminate all risk of an unforeseen problem, but it will help.
  3. Replicate the demo in multiple locations. In scenarios with multiple locations with large or important stakeholder populations, consider running separate demonstrations.  Separate demonstrations will lose some of the interaction between sites and add some overhead but will reduce the logistical complications.
  4. Record the demo. Some sites may not be able to participate in the demo live due to their time zones or other limitations. Recording the demo lets stakeholders that could not participate in the live demo hear and see what happened and provide feedback, albeit asynchronously.  Recording the demo will also give the team the ability to use the recording as documentation and reference material, which I strongly recommend.
  5. Check the network(s)! Bandwidth is generally not your friend. Make sure the network at each location can support the tools you are going to use (video, audio or other collaboration tools) and then have a fallback plan. Fallback plans should be as low tech as practical.  One team I observed actually had to fall back to scribes in two locations who kept notes on flip charts by mirroring each other (cell phones, bluetooth headphones and whispering were employed) when the audio service they were using went down.

Demonstrations typically involve stakeholders, management and others.  The team needs feedback, but also needs to ensure a successful demo to maintain credibility within the organization.  In order to get the most effective feedback in a demo everyone needs to be able to hear, see and get involved.  Distributed demos need to focus on facilitating interaction more than in-person demos. Otherwise, distributed demos risk not being effective.

Business and Technical Stakeholders Must Both Be Involved In Demonstrations

Business and Technical Stakeholders Must Both Be Involved In Demonstrations

In order to efficiently gather feedback and support, demos require broad involvement. Involvement must include the team and a cross section of relevant stakeholders. Stakeholders should span the interests of both the business and technical environments.

Business stakeholders include those representing product and back-office functionality. The stakeholders bring the understanding of market needs and wishes for both customer facing products as well as applications used within the organization to the sprint team and to other stakeholders.

Technical stakeholders include data and technical architects, process improvement personnel and DevOps teams that might need to provide guidance or direction to the sprint team. The technical feedback helps the team to stay within the environmental constraints of the organization.

The demonstrations bring the business and technical stakeholders together with the sprint team to generate feedback. The different perspectives that the business and technical stakeholders bring to the table extend the knowledge of the team. Teams that constrain participation in the demo rob themselves of significant input that may have to be “discovered” later in the project, which can generate customer dissatisfaction and rework.

Sometimes some parts may need to be a little different.

Sometimes some parts may need to be a little different.

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. Demonstrations deliver fast feedback, but only if they happen and only if they are engineered to facilitate a bi-directional exchange of information. The classic mechanism of showing functional software to stakeholders, having them interact with the software and asking (and listening) to feedback is fairly difficult to improve upon. Perhaps that is why there are so few true variants of demonstrations. The variants that have shown traction are driven either by scope or team distribution.

Two variants of the classic demonstration by scope are SAFe’s (Scaled Agile Framework) System Demos. It provides a demonstration of all of the software delivered (a systems view). A Technical Demo focuses on units of work that by nature are not interpretive by typical business stakeholders. While the Technical Demo makes me nervous, I believe we have all seen a story or unit of work that relates to technical infrastructure or relates to a specific audience of stakeholder.   Each of these demos use slightly different techniques to engage different audiences. What they don’t do is stray from the principle of showing completed work and activity soliciting feedback.

Executing demos for distributed teams and distributed stakeholders has generated a wide range of variants. As with the scope variants, most of the different techniques are used to ensure that completed work is shown, interacted with and that feedback is collected.  Many of the variants are driven by the communication technology being used, such as teleconferencing or video conferencing. Each of these technologies requires the team to plan in more depth to ensure interactivity and feedback. One interesting variant is the use of satellite demos (if there are multiple concentrations of team members or stakeholders) with feedback being rolled up to a higher level demo (somewhat akin to a scrum or scrums).  The concepts used in the SAFe System Demo may well be useful in this type of a distributed environment.

The basic mechanism of a demo is simple. Show stakeholders the completed work, let them interact with it and actively solicit feedback. I once heard someone describe this as running toward criticism. Where variations do happen they tend to be driven by scope, which implies different audiences, or by the geography of the team and stakeholders.  The variations in demonstration techniques are less about the goal of gathering feedback than about audiences and enabling the audience to provide the feedback.


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.

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.