I had a stand up derailed this morning because of a “demo prep” task.
Some background – the team is new to scrum, sprints are 1 week long. They had 1 story (storyA) carried over to sprint 2. In sprint 2, one of their new stories (storyC) was a report for the carried over story.
The previously decided demo for the carried over storyA was to run some scripts to show something. However by demo-ing storyC it is implied that storyA is done.
Traditionally each story should be able to be completed in isolation – thus demo-ed separately. But as we all know – it does sometimes happen that stories build on each other. I explained why each story should try and be as isolated as possible, but was faced with “that’s impossible”, “never going to happen”, “We’re building a house and I can’t put the roof on until the foundation and walls are there”. This also brought up other issues like why dont we demo as soon as a story is finished? Why do we wait until the end of a sprint? Admittedly the person was playing gremlin – and succeeding in flustering me and derailing the meeting.
I went off to another stand-up and had some time to digest what I actually wanted to say and why.
Lesson for me 🙂
Next time I need to remember to:
- step back and listen
- if this is a thorny issue, ask to move it to the end of the stand up, and first finish the stand up!
- dont defend the scrum artefacts just because
- first understand all the questions and issues
- then – calmly – guide and allow the team to talk through the problems and see why, and how they should go forward.
So what is the purpose of the demo? To me the demo is for the team to show the Product Owner (and anyone else wants to be there) what stories they completed in the sprint. Emphasis on the show part. This should be working software. It also allows the stakeholders to see what has been done and to provide feedback. Lastly it helps the team stay focused on the commitment of the sprint.
Reading this article I saw a few more goals to the demo that I hadn’t thought of – but would love to see:
Goals include informing stakeholders of the system functions, design, strengths, weaknesses, effort of the team, and future trouble spots.
I explained the following to my team:
You, as a team, need to decide what and how you are going to demo – preferably this is a discussion during sprint planning 2, but on the day before the demo things might change depending on what stories you have finished. In this particular case, the team can decide to explain that the demo for storyC (showing the report) is also the demo for storyA – thus you don’t need or have to run the scripts.
What makes a good demo?
From the Scrum Alliance website:
A good sprint review story has the following components:
- A meaningful; relevant theme;
- A sequence of events as the user would experience them;
- Characters and data that is realistic—use examples and names from your user community or members of the development team;
- Is compelling to the people attending the review;
- Is relevant to the people in the review; and
- Is at an appropriate technical level for attendees.
The team should find creative ways to tell the story and demonstrate the interaction and experience with the system. What’s a key word in that sentence? Creative. Have fun with the sprint review; be enthusiastic and interested in what you’ve done. When you tell the story, try to be animated. Use gestures, hands, inflection and change of cadence in your voice and facial expressions. These elements are what bring people into your story and make them feel a part of it. This opens their minds to the reality of what they are seeing and bingo! the quality and quantity of feedback increases.
We will see what next weeks first demo holds 🙂 . The team has set aside some time to sit together and decide what and how they will go about presenting the demo/review.
Another awesome day – another lesson learnt 🙂