The Sprint Demo (often part of the Sprint Review ceremony in Agile/Scrum methodology) is a critical step in completing a sprint, an opportunity to excite stakeholders, and a chance for developers to show off their work. For presenters, however, the demo can be a stressful exercise due to a lack of confidence, structure, or practice.
If you’re nervous about giving your first demo, haven’t enjoyed giving demos in the past, or you just want to get better at demoing, this post is for you!
Note that I’m not going to spend much time describing what a demo is–there are plenty of other posts online about that. This post is specifically geared towards helping you give a great one.
Okay, so you’ve been tapped / elected / volunteered to give a demo, what’s the first step? Start by gathering information and setting some boundary conditions for the demo. I like to have a single document that serves as an outline or agenda, so start by creating one now. We’ll be adding to it step-by-step as we go.
Know your audience
Perhaps the most important factor in giving a great demo is knowing your audience. Specifically…
Know who’s in the room
Ideally it’s developers, sponsors, stakeholders, and the product owner, but this can vary by team. Especially consider who your sponsors and stakeholders are–the content of the demo may not change much if the CEO is in the room, but the amount of preparation you do probably should since the stakes are obviously higher. For this reason, most of these tips focus on how to speak to stakeholders and sponsors.
Keep in mind that there are lots of ways to give a demo, and the best one might depend on the dynamics of your particular organization. For instance, this post errs on the side of encouraging a more formal, polished, narrative-based demo that tends to play well to executive sponsors in larger organizations. If you know that you have a more technical, playful, or informal audience, you should experiment and adapt to see what works best (this is Agile after all!)
Speak the stakeholder’s language
Every stakeholder or sponsor has their pet features and requirements. Find out what these are and make sure to touch on them in the demo in the language of stakeholder. For instance, if a sponsor seems particularly concerned about the accessibility of your product, make sure to point out its accessible features.
Note that the language used by stakeholders rarely matches the technical language native to your product space. Obviously there’s a give and take here, but I find it’s best not to try to force anyone to speak a different language unless it’s necessary to avoid confusion or problems down the road. If you must use jargon, make sure to take the time to explain its meaning and put it in context for the non-technical audience.
Just as important as saying things the stakeholders want to hear is not saying things they don’t want to hear. Avoid words and phrases that have caused tension in the past. Consider how features, work, and problems you discuss might be perceived by stakeholders. Note that this doesn’t mean you are sweeping problems under the rug–it’s important to lean into uncomfortable issues, but the Sprint Demo may not be the best forum for airing problems, and using triggering language isn’t going to do anyone any favors.
So, now that we’ve discussed what’s important in knowing your audience, start by putting these items into your demo agenda:
Who you expect to be in the room
Topics, words and phrases to use or focus on
Topics, words and phrases to avoid (and possibly some more positive alternatives)
Plan the demo
Brainstorm demo content
Now that you know your audience, it’s time to think about the content of the demo. I like to start by creating a comprehensive list of all of the work that your team has completed this sprint. Note that you are not going to simply present a list of tickets come demo day. Rather, this is a brainstorming exercise–you want to get all of your (perhaps literal) cards on the table to see what you have to work with, and then craft them into a story in later steps.
Now take the stories that you’ve completed and start to group them logically by functional area. Epics are a natural (though hardly the only) way to do this. The goal here is simply to identify general themes in the work that you’ve completed. While you are doing this, also take the opportunity to discard any stories that you know off the bat won’t demo well, perhaps because they are incomplete, unstable, or not user-facing. You’re going to have a tough time making refactoring sound sexy to a sponsor, for instance.
If you do want to show significant “behind the curtain” work like this, it’s fine to speak directly to the work and its value to the project without exactly demoing it. For instance, in the case of refactoring talk about how it will lower the long-term maintenance burden and total cost of ownership, improve reliability, and unblock future work.
Finally, you don’t have to limit your demo to work completed in the service of user stories. Sponsors always appreciate getting insight into the governance, development, and testing processes that drive value on projects. It’s especially important to mention significant process changes, and to remind everyone that these sorts of changes are part and parcel of the Agile process. Talking about process work can be especially useful if you’ve had a light sprint (due to holidays or time off, for instance) and are lacking in story content.
Tell a story
This is one of the most important factors for a great demo, and also the most overlooked. Given the structured nature of Agile stories and epics, it’s easy to fall into the trap of simply enumerating the work that you’ve done. This isn’t necessarily bad, but it’s unlikely to excite non-technical stakeholders.
Stakeholders want to see value, and they want to see how the product is going to delight their customers, employees, and shareholders, so focus on these factors when deciding what story to tell. One way to do this is to tell the story from the point of view of a particular persona or user role, making sure to put the audience in the shoes of a user trying to perform a specific task. Another is to simply group topics by high-level categories. If all else fails, I find that simply talking through what you want to demo, either with yourself or a small group of internal team members, can help to naturally develop a story.
Regardless of how you tell the story, there are a few good rules to keep in mind
Keep it short, even if this means leaving stories on the cutting room floor. Some Agile purists might scoff at this, so as always, do what’s right for your organization. In general, it’s better to demonstrate that the overall goal of a sprint was completed rather than demonstrating that all of its individual stories were completed.
Tie the work you’ve done to the larger sprint goals, and to the above point, err on the side of addressing sprint goals rather than individual tickets
Try to structure the demo into a series of scenarios or scripts that minimize context switching. This reduces the total length of the demo and helps to hold people’s focus.
Demonstrate value wherever possible, such as by pointing out how a particular feature fulfills a long-standing customer request, or how fixing a bug improves productivity for employees.
Be willing to flex a little bit in service of the story in terms of working around minor gaps in functionality or leaving out completed work that won’t demo well. No feature is ever 100% complete in Agile development, so be comfortable showing works in progress as long as you set expectations accordingly.
Let developers brag
There are multiple ways to arrange the presentation of the demo. Having a single speaker helps to control the narrative and provides the most consistent and cohesive experience, which can be valuable in some organizations. However, whenever possible, it’s great to allow developers to present their own work, which helps to build confidence, morale, and a sense of ownership. A good compromise can be to have one organizing speaker with a different “guest” developer showing off their work each week.
Setting expectations and providing context are critical for a successful demo, especially for less technical sponsors who may not be familiar with the development lifecycle or accustomed to seeing works in progress. Specifically, set expectations around:
What was done in the sprint: give a high level overview of what was achieved and how it ties into sprint planning or previous demos (did you achieve what you said you would last time?)
What will be shown in the demo: at the start of the demo, briefly discuss the purpose and structure of the demo. Before showing individual scenarios, make sure to warn if they are works in progress so that stakeholders don’t expect spit and polish. Also take time to explain the work that went into producing the finished product. Flashy features can often play as difficult to develop while mundane-looking features come off as easy. Help sponsors understand the difference between the two and don’t leave it to chance that they will recognize the effort.
What’s still to come: at the end of each scenario as well as the demo as a whole, point to future directions for the work so the stakeholders know what to expect next time
The point here is to avoid any surprises or chances of missed expectations, and reassure stakeholders that things are on track (assuming they actually are!) For instance, if you want to show off backend development work but don’t yet have a good theme in place, simply mention that what will be shown will be themed in a later sprint so that no one is surprised.
List all completed stories in your agenda
Weed out any stories that shouldn’t be demoed
Organize the remaining stories roughly into scenarios or topics
Decide whether to have developers help give parts of the demo
Always set expectations and give context throughout the demo
Practice, practice, practice
Now that you have the rough outline of your demo, it’s time to practice and refine it. Before giving the demo for real, it’s best to practice it at least three times. This may sound like a lot, but keep in mind that a good demo is less than 15-20 minutes long, so this shouldn’t take too much time.
The amount of practice you put in may also vary depending on your audience and organization. Many people advocate for spending less than an hour total preparing for demos, preferring instead to spend time on development work. Consider the potential payoff in terms of team buy-in and sponsor support when deciding how much time to put into your preparations.
The first practice is just by yourself to ensure that the demo environment is stable, the necessary features are in place, and to generate a “pre-flight checklist” of items that need to be setup before the demo. For instance, you often need to have sample content in place to demo a client’s website, or you may need to bookmark administrative pages that would otherwise require a lot of distracting clicking around to access.
After you are comfortable with the rough outline of the demo, practice giving it to a few members of your internal team. This will help shake out any rough spots in the story, and allow you to get some early feedback on the overall structure and catch anything you might have missed.
Your final practice should be a mock demo with a trusted stakeholder such as the product owner. This can help to reduce anxiety on the part of the product owner (who is often under the critical eye of sponsors and probably doesn’t like surprises), and can help to identify any political sticking points or optics issues that you might not have considered. Sometimes this can be combined with the internal team practice.
Finally, as a general tip when practicing: if you’ve never watched a recording of yourself speaking in public (or practicing to do so), you really should. It’s uncomfortable at first, but by far one of the best ways to get better.
Run through the demo once by yourself
Generate a “pre-flight” checklist that needs to be completed before the demo in order to ensure that any sample content is created, any necessary pages are already opened or bookmarked, the software is in the correct state, etc…
Run through the demo once with a small internal team
Run through the demo once with the product owner or trusted stakeholder
The day of the demo
By this point, hopefully you are relaxed and confident going into the demo. Here are a few tips to make the day of go well:
Print a copy of your agenda / outline, since it may not be possible to simultaneously present the demo and view your notes.
Have backup plans for any particularly finicky or complex pieces of functionality you want to demo (such as pre-recorded videos)
Welcome and thank all participants for coming, and introduce any newcomers
Hit the record button before starting, so that you can distribute the recording and/or use it for self-improvement
After the demo is complete, solicit feedback to make sure there are no misunderstandings about what was shown
Incorporate any feedback into your planning process for next time
Hopefully everything went well, and you’re excited to demo again next time!