The Project Manager’s Guide to a Perfect Demo
When have you attended or heard about a good Sprint review? I’m not talking about any review meeting after which all the feedback you get is “it was ok”. Sprint Demo is one of the Scrum events where the whole team makes a show. Unfortunately, most of them don’t find it super interesting, to say the least. Developers usually focus on the product’s functionality and whether it works as expected. Product owners or clients won’t attend a boring demo session that doesn’t make them care about the project’s progress.
Sounds familiar? At Polidea we believe that understanding how important the Review meeting is and how to make it more interesting for your team is key. With simple, small adjustments your team can feel more appreciated and have way more fun working.
What is a Scrum Review?
First, let me shortly describe what the Scrum Review (aka demo) is. Below you can find the Scrum workflow overview with the “Sprint Review” meeting highlighted.
So here’s the deal—according to Scrum the goal of each iteration is to produce a working increment of the product which can be demonstrated to stakeholders and be potentially releasable. It seems obvious, but some have a different approach; they say that during the first 5 Sprints a product is still in a very low stage of the development and it doesn’t support any necessary functionality. That’s wrong. Even after the first Sprint, Scrum team is able to demonstrate a potentially releasable version. It doesn’t matter that it will not include any functionality—the build is running and can be installed on clients’ device. Teams tend to forget about this, wasting time on the CI configuration. One of the key elements of the Scrum Sprint is the end of the Sprint demonstration (also known as the Sprint Review Meeting). In this article, I will call it ‘demo’.
Why do we need a demo?
Why are so many agile teams so hesitant to do demos? Why are demos so lifeless? Sometimes a demo becomes so boring that the Scrum Team decides to skip it all together. Other times, a team doesn’t have the skills to report their work to the Product Owner, as they don’t know how to “speak business”. But most often however, they simply don’t know how to perform a good demo.
In most cases a team simply doesn’t understand the reason or the background of why a demo is so important. At Polidea, the Sprint Demo is invaluable for keeping stakeholders up to date with the progress of the product development. It’s up to the stakeholders to decide when the product campaign should start and when it should be released to the market.
Everything is done to ensure the biggest profit with the developed product. Demo also allows them to give feedback and discuss with the Product Owner and the Scrum team any possible changes to the Product Backlog which would help to maximize value.
The goal of such discussions is to align the scope of the next sprint and the contents of the next sprint backlog. They will often result in stories being added further down the product backlog too.
Having regular demo meetings helps us build relationships and trust with our clients. It is also a perfect moment for a team to update each other on the current progress of a project.
Tips and guidelines for the perfect demo
Let’s start with a format of the sprint demo. The demo takes place at the end of the sprint and is attended by the whole Scrum team, including Product Owner and Scrum Master, as well as relevant stakeholders, management and developers from other teams. Here at Polidea we follow an “Open Demos” policy that allows any employee to attend demonstrations performed by other teams (of course after an “OK” from the PM who informed the client about it beforehand).
When an organization has more than one Scrum team working on the same project the teams should consider running their demo together. It’s not just easier to arrange it this way – it also keeps the teams abreast of what the others are working on and helps to avoid the duplication of work. However, at a certain size of the team this may not work and having only representatives from Scrum teams attending each other’s demos may be more practical.
Each Scrum team takes turns while giving an update on their progress against their sprint goal and demo the working iteration of the product that resulted from their sprint. Generally, I like to do this with the user stories organized into a logical narrative structure which shows all the items done during the Sprint. Teams usually train before the Sprint demo, to be sure all agreed and implemented items will be presented. Sometimes the team will nominate one member to present the demo and sometimes the task will be shared among the individuals demonstrating the particular parts of their work. Again, it’s a personal preference, but from my experience demos work really well when one person runs the main talk and the other one runs the demo.
Does your team know how to prepare for a demo? First of all, the Sprint Demo should not take up too much of the team’s time. I’ve heard about a lot of situations where a team said they don’t do a demo, because they don’t have time. Ensuring that the Sprint Review meeting is informal—with questions, feedback and discussion welcome—allows for prep time to be kept to a minimum. Easy as that.
Your time shouldn’t be spent putting long slide decks together—the focus should be on the work and your demo should only include stories that meet the team’s definition of ‘done’.
Generally, a day before the end of the Sprint try to align a short demo run-through with your team during which they agree on the order of the stories—and make notes on anything that needs to be set up in order to make the demo flow smooth. This meeting should be kept short (15 mins is enough).
Finally, it’s important to say that a demo is not a sign-off meeting. The Product Owner should have already seen the stories and be happy with them. Participating in a discussion and offering feedback is definitely encouraged—but while this might result in some new backlog items, it shouldn’t change whether existing items are considered to be done.
A perfect demo: cheat sheet
- Focus on the acceptance criteria. We’ve defined what ‘done’ means for the story, so focus your demo on proving that you’re actually done. Taking a separate meeting to explore with your team the definition of Done (DoD) and definition of Ready (DoR) might be very useful. A common understanding of what ‘done’ means is key to deliver what a Product Owner expects.
- 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 one.
- Prepare. Create an interesting scenario to prove that you’ve satisfied the core acceptance criteria. Create all the necessary test data. Make sure the environment for your demo will work as expected. During the demo everyone will notice how well you are prepared. It’s also good to plan the Q&A.
- Practice. Run through your demo script at least once. It will help the team to reduce stress and prepare for any surprises. Let your team ask questions to the main speaker. Believe it or not but this will help during the actual demo. Any points which will be noticed during the demo suppose to be discussed by the Scrum team during the retrospective. This is the right time to inspect and adapt to any changes.
- Tell a story. Focus your demo on a realistic user solving a real problem. The goal 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 the Scrum process. This is when the team gets to show everyone all the value they’re delivering, which is why it’s worth investing a little time to do well. You may find that previously not interested stakeholders start showing up just for the show.
All teams are different and face different problems. This article is for those who faced similar issues as I have. Let me know what’s your experience with running the Scrum and Sprint Demos!