How do you feel at the end of a product demo? Happy? Energized? Ready to celebrate? Does this feeling last?
My colleagues and I have seen our share of Scrum Meetings. We wrote previously about the Daily Scrum, and decided to focus on demos this time. Many of the demos we’ve seen had issues, and some issues keep repeating.
In this blog post, are presented 3 of the most recurring situations & symptoms: The Loooooong Demo, The Failed Demo, Demo without Feedback, and some practical ideas to fix your demo.
The Loooooong Demo
If your demo lasts more than 1 hour for a two week sprint, you have this issue (The long demo).
The worst offender has been a team whose demo lasted for 6 hours. (Yes, 6 hours) Everything looked good on paper. The PO and the team were involved. The business people, namely the board members, were very interested and attended. The team would demo the user stories finished during the sprint. The PO would accept them. But then, the board members started fighting over details related to the features. And this took a few hours of everyone’s time.
A long demo means that the facilitator of the meeting hasn’t done his or her job well enough. Typically, the facilitator of all Scrum meetings is the Scrum Master, but this job can be delegated to a volunteer or another team member. This is why we will refer to this role as facilitator, and not to the Scrum Master role specifically.
As the facilitator role is rarely well known and well applied, we took the time to detail it in the following section.
What Is Meeting Facilitation?
Good facilitation helps reaching the purpose of the meeting in the given time. Before the meeting, the facilitator should take care of things such as:
- invite people
- communicate purpose and agenda
- prepare the room, the materials and the technical support for the meeting
During the meeting, the facilitator has to:
- communicate the purpose, duration and agenda of the meeting
- define the rules of engagement: who can speak, when can they speak, what kind of topics can be discussed and what kind of topics will be discussed separately etc.
- keep the agenda
- keep the time and aim for finishing on time
- enforce the rules of engagement
- moderate conflicts
- help define next actions, if any
After the meeting, the facilitator has to:
- communicate the results of the meeting and the next actions
Although many companies still use meeting minutes, this is typically considered waste in an agile / lean environment, except when requested by laws or regulations. In a typical Agile team it’s enough to communicate the conclusions and to add the next actions to the backlog. As a good practice, make sure that the next actions are assigned immediately to the right people and communicated to all the stakeholders.
Back to The Long Demo
As we’ve seen, the job of the facilitator is to make sure that the demo finishes on time. So, what can go wrong?
Typically, a demo lasts too long because the discussions move outside the scope and purpose of the demo.
The purpose of the demo is to communicate the progress done in the past sprint, to get feedback on the implemented stories, to accept the stories that are done and to reject the stories that are not done. At the end of the demo, the velocity for the last sprint should be computed based on the done stories and clearly communicated inside the team.
The demo is attended by a few active parties:
- the team: one or more team members demo each user story done in the sprint
- the Product Owner: accepts or rejects the stories
- the facilitator: keeps the meeting running smoothly
and a few silent participants:
- managers
- business representatives
- users
- customers
- etc.
In the case discussed above (The long demo), the facilitator did not communicate effectively the rules of engagement, namely:
The silent participants stay silent during the demo
But, I hear you protest: you spoke before about the importance of feedback! Isn’t this a good time for feedback? I’m glad you asked. If you will watch my talk, you will see that I discuss that good feedback has two characteristics: it is fast and it is high quality. In the case we were discussing, the board members were not focused on providing feedback, but on analyzing and planning the next features. This is not the purpose of the demo, but is rather a meeting that the PO should have after the demo with the interested parties.
So if you want to gather feedback from the managers, marketing professionals, commercials, users, customers etc. during the demo, there’s a very simple thing that can be done:
Provide in the agenda 5′ to anyone who has something to say about the features demoed or about the product as a whole.
But, I hear you again: how can I enforce rules for my managers? Won’t they get upset? Glad you asked. We can guarantee you that even the toughest managers won’t get upset, as long as you explain the reasons behind the rules. After all, they have a choice: keep everyone from working for a few more hours or write down the issues and concerns they have and discuss them separately with the PO, the senior business and technical leaders.
So, how about using the following agenda for your next demo:
“Hello,
I invite you to the Product Demo for <Your Product> on <Date> <Time> <Location>.
In the interest of keeping this meeting effective and finish in max <1 hour / 90′ / 2 hours>, we will use the following rules:
- In the first part of the meeting, only the team, the PO and the facilitator (yours truly) can speak.
- In the second part of the meeting, we want to hear your feedback. We will however have to limit it to max 5 people from a max of 5′.
- In case you need to discuss more after the demo, <PO> will be available for further discussions.
The agenda is the following:
- Intro (myself)
- Demo User Story 1 – <Jane The Developer>
- Demo User Story 2 – <Joe The Tester>
- Demo …
- Compute velocity
- Feedback from participants – 5′ each, up to 5 people
- Closing
After the demo, I will update the board with the next actions resulted from the feedback.
Thank you,
<Your Facilitator>”
The Failed Demo
Maybe your meeting doesn’t last that long, simply because none of the stories work when making the demo.
Look, we all know that software is tricky. It’s tough to make things work. It’s even tougher to make them work consistently.
However, the demo is important. And the facilitator has to make sure that it’s properly prepared. This should be easy, since you’ve created a very nice agenda, so you know exactly who should do what. The first thing you should do is:
Make sure that each person who demonstrates a story has a task assigned on the board (and ideally scheduled in the calendar) to prepare the demo.
Since the stories are split between team members, they can prepare in parallel. So, if your demo is at 15:00 every other Wednesday, make sure that 12:00 – 12:30 everyone checks they can demo their story. Why so early? Easy: to have time to fix the story if it doesn’t work.
The next step is to learn what makes the stories fail. Here are some of the most common reasons we found:
- someone deployed something before the demo
- someone changed something in the code, and the change made other things fail
- the server got upgraded and this made things fail
All these things can be easily fixed with a simple rule:
Do not change anything in the last day / half day before demo
Or, at least:
Anything you change in the last day / half day before demo has to be peer reviewed
Isn’t that easy?
Demo Without Feedback
So you’re doing the demo and things work fine. Some things are not quite done, but the PO is nice enough to let them slip. You congratulate each other and move on. You’ve done a great job this sprint!
Or not?
I know that it’s great to have a feeling of accomplishment. Scrum offers an easy way to measure your accomplishments in a sprint: the story points that add up to the velocity of the sprint. You feel great when these points add up, even if you know that some of them are not done according to the Definition of Done.
But here’s the problem: velocity is typically used to predict the product’s advance. So what happens if your PO lets the not-that-done user stories pass and add up to the velocity? Let’s make a simple simulation:
Total story points for backlog: 100
Sprint 1: 7 sp accepted / 5 sp actual
Sprint 2: 10 sp accepted / 7 sp actual
Sprint 3: 15 sp accepted / 7 sp actual
Average velocity: 10 fake / 6 real
Total sprints to finish the backlog: 10 fake / 17 real
Expected delay: 2 wks * 7 sprints = 14 weeks = ~3.5 months
Care to guess who will have to work harder to meet the schedule in this scenario?
You are trading your short-term happiness for your long term unhappiness (and you shouldn’t).
The solution is to embrace reality, to take feedback seriously and to act on it. Lack of feedback won’t only create more challenges, but it will stop you from improving. The fact that your team finishes the sprint with stories not done is a great input for retrospective. It’s something you can analyze and improve. It’s definitely annoying that you cannot do it now, but here’s the thing: we cannot change the past. The only thing we can do is to change the way we do things from now on. For a more in-depth look at why we need feedback in Scrum, read this article on the topic.
Embrace feedback. Don’t negotiate doneness. Act on the findings.
Time to have a happier demo!
