How to Give a Great Sprint Demo

Exciting. Entertaining. Do these words describe your sprint demo meetings? Or are boring and unfocused more accurate?

I can’t believe how many times I’ve come in to coach a team and they’ve been surprised when I actually expected to see a software demo in the sprint demo meeting. As the agile principle says, “Working software is the primary measure of progress.” Let’s see some software!

Why are so many agile teams so hesitant to do demos? Why are demos so lifeless? Sometimes, the team’s not actually done. That makes a demo awkward. Other times, they can’t communicate what they did to the Product Owner; they don’t speak “business.” But most often, they simply don’t know how to give a good demo.

So, how do you give a good demo?

Here are a few tips:

  • Focus on acceptance criteria. You’ve defined what done means for the story (right?), so focus your demo around proving that you’re actually done.
  • Start with the demo in mind. Don’t wait to think about the demo until you’re done with the story. You might be able to write tests that double as demo scripts. And it’s best to plan your demo for a story while it’s fresh in your mind, before you move to the next story.
  • Prepare. Don’t ad lib. Think through an interesting scenario to prove that you’ve satisfied the core acceptance criteria. Create any necessary test data. Use tools like Watir if necessary to get your app into a state where you can start an interesting demo.
  • Practice. Run through the demo at least once. When you’re getting started, you might want to grab a trial version of Camtasia and record yourself giving the practice demo. Painful, huh? That just means you need to work on it.
  • Tell a story. Center your demo around a realistic user solving a real problem. The point is not just to show that the software works, but to show that it’s valuable.
  • Keep it short. If you work on your stories one at a time and get them accepted when they’re ready, you don’t need to exhaustively cover all your acceptance criteria in your demo. Instead, focus your demo on what’s interesting and what’s valuable about each feature.

The sprint demo should be the most exciting part of Scrum. It’s when the team gets to show everyone all the value they’re delivering. That’s worth investing a little time to do well. You may find that previously disinterested stakeholders start coming just for the show.

What has worked well for you in sprint demos? What hasn’t worked? Share in the comments.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

  1. Excellent advice written with style and grace.

    I especially like the idea of an exciting and entertaining demo, which, contrary to some people’s opinion, can still be relevant and informative.

    I also like your advice about the importance of practice. Any presentation, which is what a demo is, benefits from practice.

    Nice work, Richard. I like your writing a lot.

  2. @Steven – Thanks for the kind words. I agree, there’s no reason you have to choose between exciting and entertaining and relevant and informative. The most relevant and informative demos ought to also be the most exciting, assuming you’re really building a valuable product.

    @Bob – Good point. I like to rotate the demo role around the team usually. But one interesting case I saw was a team where the Product Owner did the demos. The demo wasn’t the team showing her what they built–it was her showing the rest of the stakeholders what *her team* built.

  3. I like the demo but with a pinch of salt, with my experience, the “demo day” is huge overhead time spend in the project.

    -Preparing the software for demo
    -Practicing for the demo (as per you)
    -Sometimes preparing special hardware for the demostration purpose only.

    All this shows ok, the software works as per the PBI.

    having a functional software every sprint end is not always realistic, sometimes a software needs refactoring or “break all bones before rebuilding” all that does not happen in a sprint time and in such cases software are not in a demonstrable state.

    The only people who are happy with the demos are the product managers who likes to see nice nice thing all the time.

    Peer engineers knows the problem and would rather would like to spend time on getting the software working rather then spend time demostrating and preparing for demos.

    all in all, with all the software processes i have gone through, i find the scrum process to be very cumberson one.

    The process is not really agile, the only part of aglity is ability to be prepared for a change in spec. otherwise, Scrum is not really an interesting process.

  4. Is it necessary to give a demo internally on the last day of sprint? If there are no customers in the meeting how does a demo help the developer, business analysts and the product manager?

    • @Aninda – I find it valuable to look at the state of the product at the end of each sprint, both from the functional perspective and from the technical perspective, under the covers. A demo is one way to do this. It may be combined with other ways. If everyone has seen the features already, maybe the sprint review is more about the big picture and less about the specific items from the sprint.

      At the time I wrote this post almost 4 years ago, I was working with teams who could have got a lot of value out of improving their demos but instead were thinking of giving them up. Today, I often see teams doing decent demos but not using them to look at the overall state of the product, so “improve your demos” is just a piece of the advice I give around sprint reviews.

  5. Can we demo only defect fixes in agile when only defects are committed for the sprints or do we always need to demo only user stories.
    Thanks,

    • @Madhu – Sure, why not? Defect fixes can sometimes be difficult to demo in an interesting way because the fix is to make the system do what it was already assumed to do. Nonetheless, showing the new state of the system in some way can be valuable.

Richard Lawrence

Is co-owner of Agile For All. He trains and coaches teams and organizations to become happier and more productive. He draws on a diverse background in software development, engineering, anthropology, and political science. Richard is a Scrum Alliance Certified Enterprise Coach and Certified Scrum Trainer, as well as a certified trainer of the accelerated learning method, Training from the Back of the Room.

Connect

richard.lawrence@agileforall.com Twitter LinkedIn Subscribe to RSS Feed Blog posts by this author