TABLE OF CONTENTS
How to prepare for a successful Demo
How to prepare for a Demo session? Before I answer this question let’s see what are some common traps you can fall into without adequate preparation.
Common traps
When... you don’t have a Demo at all
The first trap would be when the Scrum team does not give a Demo at all. For me, the kernel idea of agility is to receive feedback for your work as soon and as often as possible. Primarily, from those who will use it in production or have any kind of use from it.
Countless software projects and products failed because they were delivering something that users were not interested in, that was not used in the way it was designed, or that was not needed for the business.
So, every Agile team and Product Owner should embrace the opportunity to receive feedback on a regular basis so that they know if their work is valuable to the business. And if not, to make needed adaptations soon enough so that they achieve a given goal to deliver a useful product and functionality.
When… you have a Demo with no preparation
Next to not having a Demo at all, is having a Demo without preparation.
Do not allow yourself a situation where you are surprised with the outcome of your work while presenting it, or with sudden errors. In the Demo, you are presenting your work, so if you do not know it properly, what opinion others might have about you and your team?
Also, to not have the answers to questions related to your work, or get tangled up in explaining your own work – gives “feedback givers” a hard time trying to understand the presented work. In the end, they are not able to give feedback at all.
This is something that an Agile team wants to avoid at any cost!
When… the demo facilitator is not the Product Owner himself.
One more thing, not as harsh as the first two, but still a bad practice is when the Demo facilitator is not the Product Owner himself.
Don’t get me wrong here, it is a good thing when other team members give presentations for so many reasons. It builds their confidence, they can show how proud they are of the work they have delivered, they are practicing presentation skills and yes, usually, they will explain the functionality better anyway!
But in practice, I often see that, when the developer or business analyst is giving the presentation, the first questions come from their Product Owner. The Product Owner is the one who accepts stories, so when he sees them for the first time on the Demo and has questions about them, it tells me that this Product Owner is not aware of his job and responsibilities. I just raise my eyebrows when I see this happening and wonder what other things this Product Owner is doing without understanding his job and role.
So, giving Demo sessions by other team members is all right only when the PO is familiar with the stories and participates as the one who gives the answers, rather than the other way around.
Now that is clear how important it is to be well-prepared for a demo session, let’s finally answer the dreaded question:
How to prepare for a successful Demo?
Prepare a narrative
You as a Product Owner know the reason why some functionality is done in the first place.
Tell that to the audience first.
To give a good introduction you can try one or more of the following:
- Show an end-to-end process and emphasize which part of that process is being delivered by the story you are presenting.
- Make up an entertaining story with funny jokes about imaginary characters or situations, the ones that will emphasize the reasons why you developed this functionality in the first place and give context to the demo and stories that you are showing.
- When possible, order the stories you are presenting to tell the story with a beginning and end, giving a bigger picture.
- Explain the business perspective and value whenever possible, after all, business people are the ones who will use your deliverables and they have to understand what their purpose is.
- Engage your audience by mentioning them in your story, the goal is to make the presentation interesting so that they listen to you, and later have something to comment on.
Make sure that the functionality is working as it should before presenting it
Try functionalities yourself before the Demo, and do it with the developer who was working on it as part of the story acceptance. Whatever questions you have, make sure that you ask them before the Demo itself. Sometimes, you will get the same questions during the Demo, but now you will know the answer since you had the chance to check in advance with your team.
In case of lacking a proper test environment…
Showing your stories locally during Demo sessions should be avoided when possible. Also, your Definition of Done most certainly demands that the story can be pronounced as ready if it is deployed to a test environment.
But sometimes, there are circumstances when you will have to show things locally. If you have a good reason why this story cannot be deployed in a test environment at the moment, and you would like to show it locally anyway, just explain to the audience why you are presenting it locally.
As long as you are in control of your Demo, and you have an explanation for the things you do – no one will have reason to question you.
In case of errors…
Decide if the errors you found during your preparation are acceptable. It is perfectly fine to show errors during your presentation as long as you are aware of them and explain how you will tackle them. Stating that you are aware of the faults and that you will solve them gives you credibility.
If the error found is not acceptable to be presented during the Demo, you should either not approve the story, or the developer should fix it as soon as possible so that you approve the story and show it on the Demo.
Prepare data
Make sure that the data that you enter during the presentation will be accepted by the system and also be understandable for the audience. Prepare this data with your team and have it somewhere easily accessible during the presentation. Existing data in the application that you are showing during your demo should be understandable to the audience, so instead of naming your values as ‘a, b, c’, give them names from the business case. Prepare which data you will select during the presentation to have a showcase to properly present your story.
Best practices
“MVP”
You do not have to show all the stories you delivered in your Sprint, although, it would be good if you do. You can show not only stories but also fixed errors, or tasks you completed during the Sprint. You can also present part of the analysis of some story if it makes sense for you to do it.
I show them when they are interesting enough to be part of the Demo or when I do not know how to proceed with it and I expect the audience to help me with ideas.
In short, show everything that you would like to receive someone's opinion on.
“Nice to have”
My practice is to summarize the stories I want to show on Demo into a PowerPoint presentation. In that way, everything is transparent, it is well known which stories we finished and it helps me to have an order according to which I present the stories.
“Must have”
Same as you have Retro for your Sprint, have a Retro for your Demo. Learn from your Demo and based on what you have learned, improve it. If questions you received in the demo session tell you that the introduction or explanation you gave wasn’t understandable, find another way to explain the same thing. So, if the opportunity in the next demo session is given, repeat the explanation in another way.
If you receive comments not to your liking, give them a thought anyway, e.g. why they were given and for what possible reasons. You might discover new viewpoints that you haven't thought about before.
Finally, write down any feedback you receive and later decide whether you will act according to it.
How much time does all of this take?
Over time it downsizes to half an hour top!
It gets easier after a while. First make sure that you approve your stories regularly during the Sprint, not before the demo. That way, your preparation for the demo will be shorter and with less stress. Also, you will have many demo sessions behind you, so you will have your own template for demo presentations and every next preparation will take less time than the previous one.
Sure, from time to time, when you are developing completely new things, you will need more time to prepare an introduction to a new subject, but overall, same as other things, perfection comes with practice ;).
Good luck!
