Showing your work and the work of your team to a broader audience uses some different skills than we might use when building products. Here are tips gleaned from a decade of doing demos everywhere from hospital beds to happy hour to executive boardrooms.

The demo team

Usually, the Eng Lead is the point person for running a demo. But make no mistake: this activity is most successful when it is a collaboration of product and development. There are too many blind spots during a demo for one person to attempt without a buddy or two.

The product manager has a good vantage point to set the stage. To compactly state the goals of the sprint in the language of the stakeholders in attendance. The product manager can respond and follow up when additional requests or suggestions are made in the form of feedback.

The development team is uniquely positioned to show the work they did. They can reach a high level of confidence that the environments are ready, and they can use backups if anything goes wrong during the demo. They can answer questions about underlying mechanisms and alternate use cases.

Practically speaking, this is a great place to tag-team. It’s so much more interesting to go through a demo experience when there is both somebody to listen to and something to see. (As anybody who has ever run a technical demo knows, it can be very difficult to keep an audience engaged while trying to figure out why all dropdown selectors are empty.) The best demos switch speakers frequently, and leave lots of room for questions and reactions. 

To this end, the demoer role should be shared by taking turns to give a fresh face to the development team each sprint. Each developer should know how to show the basic functionality that everybody has been working on. Iron sharpens iron, and in this case we want all of our developers to stay sharp! The best quality is delivered by teams that work this way. Quality is a whole team sport. Even if you have the same demoer on point most of the time it's healthy to train others up for when the Eng Lead isn't available. 
 
Developers often know about features that have either unpredicted utility or unpredicted beauty. (The developer is, after all, the first user tester of the working product.) A developer may be able to show how a native Chrome widget, working with the software, makes an operation even easier than was anticipated by the design. Any member of the team can contribute an idea for something to add to the demo, whether or not there is a story for it.

Getting ready

Write a script. As a team, at minimum, you need to know what you’re going to show, who is going to show it, who is going to talk about what, and in what order. Formalizing a demo template that you fill out each sprint is your strongest move. If your script is in a tidy place you should show that during the demo, to both anchor the agenda as well as have a place for taking notes. We often do this in Google docs and have a history of all of our demos and the feedback/questions we scribed from our stakeholders.

Go through all of the delivered and accepted tickets to make sure you know what was done and how to show it.

Get on the same page by having a pre-demo meeting for 30 minutes where the product manager and dev team meets to review the work for the sprint. This is a great place for the demoer to do their homework with the other devs and product owner there to answer questions on how to demo things.

Do the demo as much as you can just as you would for your audience, in as close to the demo conditions as possible.

Have you done fewer than fifty demos? Then try this: record your demo as you plan to do it with video and screen capture turned on, and then watch it. If you watch it, I’ll bet you change quite a few things before you end up asking others to sit through it.

Your demo environment isn't what you thought it was

You rehearsed your demo but it still went horribly wrong. The most common cause is that you were demoing in an environment you weren't used to. Here are the most common differences that can cause a demo to go off the rails:

• projector versus laptop display
  • missing display adapter
  • Bluetooth or Wi-Fi needs to be joined for display
  • stuff that you ordinarily just click on you now have to search for in your window hierarchies
• conferencing software versus without
  • you have to specify what you will show to people on the call
  • screen real estate is affected by conferencing software and display overhead
• dev versus test versus prod
  • Never demo from your laptop, use your automation to deliver your work to a pre-prod environment that matches production as much as possible. This way you will have fewer surprises from dev->test->prod.
• that last mod that you made that broke the parts you weren’t looking at
  • (and you hoped Jenkins was lying)
  • Put your dev pencils down the day before the demo. Don't allow for the risk of new work to get into your demo, either accidentally or on purpose. The temptation to get one more story into the demo needs to be reviewed for safety. The teams that have the fewest surprises during demos will lock down their development branch until the demo and release have been performed successfully. 
  • Make sure that you don't let demo pressure short-cut your team's adherance to their "definition of done." If you haven't written one with your team yet you really need to do that ASAP. Here's a good definition of done to start from, and do your best to honor the spirit of each item while writing one with your team. If you don't all agree on what demoing a "done" ticket is then you can count on chaotic flying monkeys finding their way into your demos.

If you have to make a leap of faith about the environment you're demoing in, it's best to give a disclaimer at the beginning that some stories that were accepted in a test or staging environment may fail in the demo environment.

Tell a story

Your script should tell a story, and the story is about delivering value to users. 

Use names! Your user research probably includes personas or customer names that have been circulated among the team to motivate value creation. Your use of them connects you to your audience, and lets them know you’re aligned on delivering that value.

Sometimes it’s easy to see the value that stories deliver. For example, your team built a two-factor authentication system. Why? Because your users’ data is sensitive, and you don’t want anybody else to see it. But sometimes it’s harder to see the value. Suppose you’ve done a large refactoring project. As a technical team member you may be tempted to say that you did it because the code was messy and it was driving you crazy. But from the perspective of user value, clean extensible code means that you can respond faster to a user group that needs the existing feature to be modified. Code refactoring helps you to satisfy a future need rather than addressing a past dissatisfaction. If you’re in doubt about the value a story delivers, discuss it with your product manager.

Where possible, put user stories together to make a continuous experience. It’s okay to include interstitial elements that were demoed previously, as long as you call out what’s new and why it adds value. If you have a ‘happy path’ to demo as well as exception cases, see if you can make them part of a continuous narrative using as small a ‘data universe’ as possible. For example, if the same user can be used to represent the happy path and all the exception cases, use that one user and describe the setup in terms of that one person.

Connect with the audience

This is the easiest thing to forget if you are demoing software that you helped build. During the demo, the people attending the demo are more important than the software.

Know your audience and adjust your demo to cater specifically to them. If you are demoing to non-technical people, don't dive into the weeds of how something was done, or why it was difficult or easy to implement. Instead, focus on the value that has been added to the product or user, for example.

Make sure the audience is with you. Look them in the eye. Seek permission to continue. Look for questions; welcome comments.

Strive for harmony during the demo, and stay connected and confident of all the contributors on your team. 

Make sure you get what you need from your stakeholders during the demo! I bet there are things that you are hoping they might validate or affirm. Write down your learning goals as well so that you don't miss the perfect chance to connect with your stakeholder while looking at working software.

Check yourself

There are a handful of common things that a demoer can do and say that don't show well. Avoid things like:

• Extra mouse clicks
• Fast scrolling or extra scrolling
• Rapidly changing windows

Demoing onsite on a strange projector with remote attendees is especially challenging when you’re not prepared. Arrive early and get ready by following these steps:

• Download video conferencing software, if it’s not already installed
• Check to see that any codes are working for yourself and others
• See how the in-room video display interacts with video conferencing software
• Where are the speakers? Where are the microphones?
• How do you mute remote attendees when their phones play hold music?

If it’s an option, get somebody else to run the conference, and allow you to join as a presenter. That way, the other person is responsible for ensuring that others can join, muting/unmuting, etc.

During a demo, there are a few things you should never say.

• "There's not much to show today."
• "We didn't get as much done as we wanted to."
• "...but there's nothing for me to really show you..."
• “We almost finished this story…”

T minus 1 hour

As you get closer to demo time, you’ve done the hard part of prep. Now it’s time to use a simple checklist to get you down to the demo time with no last-minute misses.

• Let the product manager know if there are any issues or variations from the script
• Open your demo script and have the staging site open and ready to go
• Arrive 5-10 minutes early to set up your AV
• Add 30 minutes if you are demoing over conferencing software
• Is anything going to go to sleep during your demo?
• Turn on your computer's Do Not Disturb mode
• Close all communication apps:
  • Slack
  • Messages
  • Email

Make sure you have a few extra minutes before the demo so that you can shift your focus to the most important component: interacting with the people who are attending
During the demo, there are some basic things that you've practiced in advance:

• Draw a circle around navigation elements with your mouse before clicking to draw attention to where the action is happening and give the audience time to follow along.
• Zoom in to a level that makes text readable to everybody (especially when showing things like a Pivotal backlog).

When things go wrong

Even the best presenters have bad days. When things go wrong, the most important thing is to stay calm. Don’t forget why you’re there. If you ever have to decide between getting something to work and paying attention to your audience, pay attention to your audience.