Last year, I was looking for a new place to live. This involved a lot of house and apartment tours. A typical real estate tour would go like this:
“Here we have the main entrance, with big windows, a closet, and hardwood floors. Now down the hall is the kitchen. There’s a double sink, a dishwasher, and stainless steel fridge. There you have your living room with the stairs going to the basement…”
The landlord just explained what I was already looking at.
Some agile sprint demos feel like real estate tours. In the scrum framework, the sprint demo (sometimes called the sprint review) is a meeting for a product team to show the product owner and other stakeholders the work they’ve completed in the sprint. It makes the product team’s work transparent, giving the product owner an opportunity to course-correct along the way if something isn’t quite right.
A developer may go through a list of features the team completed, jumping from one to the next. It might go something like this:
“Now, I’ll open the settings page here, and you can see we now have a video quality option. You can choose 480p, 720p, 1080p, or Auto with the radio buttons. I can save all the settings by clicking the save button below. The user preference is saved and applies across all the user’s devices. Then, it takes me back to the home page.”
If you work on an agile team, you may see demos like this often, and it’s not surprising. It’s a fairly simple way to demo: just show the changes you made and explain how it works. However, it doesn’t put the feature into context. It doesn’t touch on what type of user this is, what they were doing before going to the settings page, or why they want to change the video quality. Depending on the audience and purpose of the demo, these could be important details.
At Zeitspace, we use the scrum framework in our projects, and we’ve done a lot of sprint demos over the years. Here are some tips that have helped us run engaging and effective sprint demos.
Know the audience and the purpose of the demo
Know who’s going to be in the room. You can tailor the demo to the audience. If your audience is a group of software engineers, then it might be helpful to dig into edge cases and some technical details. If your audience is a high-level executive, then you may want to keep the demo short, avoid getting into deep technical details, and point out how the product helps meet business goals. Think about what’s important to the people in the audience.
Typically, the purpose of the sprint demo is to show stakeholders progress, and to get the product owner’s continual buy-in and direction. The sprint demo also keeps the sprint team accountable for delivering the user stories and tasks they committed to during sprint planning.
Once you know your audience and understand the goal of the meeting, you can start planning a great demo.
Create an outline
Preparing and delivering a great demo is a team effort. It’s a good idea to work with the whole sprint team to go over what you’ll include in the demo. If you work with an issue tracking system like JIRA, this is straightforward. You can go through all the tickets in the sprint and create a list of things to demonstrate.
There should be a defined standard that determines what items can be included in the sprint demo. Usually that comes from the team’s “definition of done,” a shared understanding of what it means for a story in the sprint board to be done. If you show a mix of completed and work-in-progress features, your audience won’t have a clear understanding of the current state of the product.
Once you have your list, group the items into functional areas. This will help you build a natural flow, and help build a story for your demo.
An example of taking completed user stories and organizing them into logical categories.
Tell a story
A sprint demo is a performance. You have an audience, and you want them to get something out of the experience. In many cases, a team member walking through a long list of features makes for a dull demo. Consider an example similar to the real estate tour I mentioned previously:
“Now, I’ll open the Recommended Videos tab. There’s now a context menu that shows when you tap the three dots here – and you can mark something as ‘Not interested.’ The app will then show a message for 10 seconds that allows the user to undo that action. When I click ‘Undo’ the video appears back in the list.”
While this demonstration accurately shows how a new feature works, it leaves a few key questions unanswered:
- What type of user is this?
- Why did they go to the Recommended Videos tab?
- Why would they mark something as “Not interested?”
- What value does this feature bring to the user?
- Why is the ability to undo an action important?
The team may have already had discussions about these details during sprint planning or other meetings, but it’s helpful to remind your audience of the context and benefit of a feature. You can engage your audience by telling a story from a user’s perspective.
Let’s take the previous example and demonstrate it differently:
“Let’s say I’m a new user who’s just started using this app. I’ve watched a few cooking videos so far. Now, when I open the app I see I’m on the Recommended Videos tab by default. I’m seeing some recommendations for Gordon Ramsay videos. I’m not a big fan of him though, he’s a pretty mean guy. I’ll mark these two videos as ‘Not interested.’ Oops, I accidentally did that to a third video. Oh, I’ll just hit the undo button and it pops back in my feed. Now I won’t see any more Gordon Ramsay recommendations! Cool!”
This puts the new feature into context. It reminds the audience why we included and prioritized this feature in the first place. They can imagine themselves as a user and see how it would fit into their workflow. Humans naturally relate to each other through stories, and storytelling is also powerful in UX design. So why not use storytelling to level up our sprint demos?
You may find yourself repeating the same user flow each sprint, or showing work from previous sprints. That’s fine! It helps to tell a complete story. Just be sure to point out what’s new this time around. Stakeholders will be able to see the evolution of the product as the team iteratively builds it.
Don’t have too many presenters
While people typically work on their own tickets throughout the sprint, everyone is still part of a single sprint team. You’re working together toward a common goal. If you have each member demonstrating their own work, it can be hard for the audience to piece everything together. It can also be distracting to keep changing the person who’s speaking and sharing their screen.
A single presenter can give a demo that flows well with minimal distractions. You don’t have to transition between speakers, switch the screen that’s being shared, or mix multiple different presentation styles in one demo.
You can rotate presenters each sprint to give everyone the chance to demonstrate the team’s work. This is a great opportunity for team members to improve their demonstration skills through practice. I’d still stress that it’s incredibly helpful to prepare for the demo as a team.
Practice it!
As with any presentation, you can do a practice run to iron out the kinks. For sprint demos, it’s good to have the whole team there to observe a dry run. Everyone can help make sure that the work is being demonstrated properly and that the story flows well.
This is also a great opportunity to fix any last minute bugs or technical issues that crop up. An unexpected technical failure could derail the entire sprint demo. It’s better to find it sooner rather than later.
When you run through the demo and speak out loud, you may notice something doesn’t flow well, or you realize the order should change. Make sure you do the dry run far enough in advance to allow time to adjust and fix anything.
Demo day
Congrats, you’ve made it through another packed sprint. Thankfully you’ve thoroughly prepared for this moment and you’re all set for a successful demo. It’s showtime!
When you’re presenting during the sprint demo, use your voice and expressions to show that you’re excited and proud of the work you’ve done this sprint. After all, it’s a performance, and it’s best to keep your audience actively engaged.
Remember to allow time for questions and feedback. Depending on how you structure your sprint demo meetings, you may want to have discussions throughout the demonstration, or you may find it better to wait until the end.
Step back and reflect
The sprint retrospective is another scrum ceremony, and it’s a great opportunity to reflect and evaluate how the sprint went. This is a great time to talk about how the team does sprint demos. There are lots of ways to structure and run retrospectives, but I won’t get into that here. The important thing is to step back and see what’s working well, and which areas could use improvement.
If you’re intentional about preparing for and improving your sprint demos, you’ll have a good shared understanding with stakeholders. The team gets to show off their great work. The product owner gets to see the product evolve. Everyone can make informed decisions when prioritizing features in the next sprint. Ultimately, giving great sprint demos helps you build a great product.
Want more free advice from our experts? Sign up for Office Hours, a free one-hour consultation with our team.
