How to Give a Great Sprint Demo

The sprint demo is a critical part of the sprint review ceremony in Agile and Scrum methodology. It's an opportunity to excite stakeholders, a chance for developers to show off their work, and a moment to celebrate a successful sprint. 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 just want to be a better presenter, this post will provide an easy-to-follow recipe for sprint demo success.

The first step in preparing a great demo is to gather information and build an outline of key points to cover. 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.

As a presenter, you must do three things to prepare a great demo: know your audience, plan ahead, and practice.

Know Your Audience

Perhaps the most important factor in giving a great demo is knowing your audience. Specifically, you must know who's in the room and speak the stakeholder's language.

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. 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 particular dynamics of your 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 terms they'll appreciate, i.e. business value. For instance, if a sponsor seems particularly concerned about the accessibility of your product, make sure to point out its accessible features, and demonstrate how these features drive business value by meeting compliance obligations or expanding your customer base.

Speak plainly and avoid jargon. Obviously there’s a give and take, but I find it’s best not to try to force non-technical stakeholders to speak a different language unless it’s absolutely 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.

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, or that might be misinterpreted. This doesn’t mean you should hide problems from stakeholders. It’s important to be transparent and lean into uncomfortable issues, but using triggering language isn’t going to do anyone any favors.

Action Items

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
• What their priorities are, and how they measure business value
• Topics, words and phrases to use or focus on
• Topics, words and phrases to avoid (and possibly some more positive alternatives, such as "patching" instead of "hacking")

Plan The Demo

Now it's time to plan the demo. For this step, you want to brainstorm demo content, tell a story, let developers brag, and set expectations.

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. 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.

Now take the stories that you’ve completed and start to group them logically by functional area. Epics are a natural way to do this. The goal here is to identify themes in the work that you’ve completed. While doing this, take the opportunity to discard any stories that you know off the bat won’t demo well, perhaps because they're incomplete, unstable, or not user-facing. For instance, while refactoring might be terrific for engineering efficiency, you’re going to have a tough time exciting a sponsor unless it clearly drives business value.

If you do want to show significant “behind the curtain” work, 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. A structured narrative is critical for engaging and exciting 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 group topics by theme. 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, here are a few 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. It’s generally 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 err on the side of addressing sprint goals rather than individual tickets
• 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

Having a single presenter for the whole demo 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.

Set Expectations

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. 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!).

Action Items

• 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 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 on the hook if the sponsors are unhappy), 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.

Action Items

• 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!