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.
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.
[…] Oh, and while we’re on the topic, if you want to know how to have a great demo, read this blog entry. It has some awesome ideas that all teams should try to follow. The only thing I would add is to have someone other than a developer or tester be able to try the software during the demo. Too many horror stories about how things were missed when developers went through demos too fast! […]
@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.
Great tips Richard, thanks!
Another suggestion: have the customer/product owner “run” the demo him or herself.
thanks for your blogging!
~ ellen
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.
We started allowing Developers to demo their code as soon as they finished it. So we don’t have a demo day (our experience with it was similar to yours)…instead, demos are done on the fly as soon as the developer is ready – what happens is the PO gets 10-20 demos per sprint, but they are spread out and done when the PO and the Developer have minute to spare. It saves a lot of time by eliminating the need for the time it takes to plan and run a meeting, the developers are excited to show their work as soon as it’s ready, and we find it significantly improves both morale and productivity.
@david,
Yes! I like that way better than waiting until the end of the sprint. I often tell my classes, “The sprint review is the last and worst moment for the PO to see something. Last because it’s literally the end of the sprint. Worst because you can’t collaborate to get the thing done at that point. It’s probably not perfect, so now you’re stuck accepting it as-is or telling the team they’ve failed. Mid-sprint, you can collaborate towards done.”
Once you move this kind of review into the sprint, the review at the end of the sprint can be about looking at the big picture of how the product has changed and what it means for the future.
Thanks for the helpful comment.
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.
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.
Thank you for your insight Richard .. this is very similar to how my organization functions as it pertains to our Demo. I am curious if anyone may have some suggestions or thoughts around multi-team demo’s that are limited. I work within a category that has 8 teams to demo their work from their sprint all within 60 minutes. That gives each team 7.5 minutes and timing isn’t working well. I struggle with micro-managing the process but it seems like someone always gets cut off and doesn’t get to speak to great work they have done which could be of great value to peers across the development org. If anyone has experienced something similar or has any thoughts I would love suggestions.
@Celena – Thanks for the comment.
What you’re doing sounds like a different meeting than the Sprint Review, so I’d use those 7.5 minutes to focus on giving a great demo of what the larger group should see (probably MMF-level; see https://agileforall.com/mmfs-what-they-are-and-why-they-matter/). You’re not limited to the four Scrum events for coordinating and getting feedback.
Then, I’d do a separate team-level review to inspect the change in the state of the product since the last review (story level and internal quality).
Between the two, then, you’d get a good view into the state of the product and be able to make decisions about how to update the backlog accordingly for future work.
Very good article…Thank you very much, Bob
It is very interesting to see how this topic persisted since it was posted first 13 years ago.
I am writing to see if anyone has any good ideas about doing a demo for a team that is dedicated to API module/layer of a bigger product. The API layer is used to integrate the product with important customers that themselves represent groups of individual product customers (product is B2B). These integrations are crucial for the functioning of the overall product and API layer has both inbound and outbound messages passing through it. For demo purposes, it is (at least currently) difficult to show one of the ends of each type of API message because it happens on the customer side. Short of building some sort of demo platform, any ideas about how to effectively showcase the work of such team would be highly appreciated.