In the previous article, we discussed the Sprint Length and the pros and cons of 1 week versus 2 weeks.
In this article, we’ll talk about the Demo. This is the most fun part of Scrum, showing off. Invite all stakeholder, especially the PO, and even better if you can: customers. Be proud, be energetic, dazzle the audience.
It’s best to have a simple format of Theme, Demo, Data.
Start off with a single slide that outlines what the team got done this Sprint and what you’re about to Demo. This may seem obvious, but it helps setup the crowd for what they’re waiting for. This is super important, because if you don’t start with the agenda, the audience has no idea where you’re going in the demo, and often loses the point.
For example, if I’m leading a demo, I might start off with a slide with 3 bullets on it:
- Social icons
- Drown down menus
- Newsletter widget
And say to my audience, “Thank you for attending today. This Sprint’s theme included 3 major new features. The first feature is social icons – these will help drive traffic to our site through viral marketing. The second feature is drop down menus – this reduces the clutter of the navigation and makes the site easier to navigate. The third feature is a newsletter signup widget that makes it easier for users to notice and should increase sign up rate. Let’s jump in and show you.”
During the demo portion, you may do it with slides if you have to, but it’s much better to do a live demonstration, in production. The slide deck may only be a blank slide the says Demo, and then you move over to the product and demonstrate each point from the Theme slide.
Encourage audience participation. Let them ask questions, and answer by showing them, if feasible. Don’t let it go too far so you don’t run out of time.
You practiced before the demo, right? It’s always a good idea to do a dry run before the demo, to make sure it’s going to go smoothly.
Remember to have fun with it, gleam with pride. The demo is time to show off the fruit of your team’s labor.
Did you read the article on story sizing? Velocity is number of story points completed in a Sprint. You want to show a chart that show estimated, actual and ABS(difference). Absolute value of the difference shows how accurate (or inaccurate) the team was at estimating it’s velocity. Don’t worry if you are not super great at first. Your velocity chart might look like this at first:
4 Week Avg Velocity: 25.25
It’s normal to be inaccurate at first, but then, after about 4 sprints, a team will get very good at knowing their limits.
Even when you’re good, sometimes you nearly finish a big story but fall short. Say it was an 8 point story. Demo time comes, and now you’re chart looks like this:
4 Week Avg: 26
You were doing so well, even pushing for a few more points each Sprint, increasing Velocity, and then blammo. The good news is this is still an 8 point story, and you’ve only got a little bit of work left to do on it. You’re going to pick up those 8 points next sprint with only a couple points worth of actual work. Your team velocity will smooth out next sprint. Whatever you do, don’t compromise quality and deploy early, or try to pull the wool over the eyes of other stakeholders. Be straight forward. Explain that you didn’t finish this 8 point story, but you expect to pick it up and have a stellar sprint next week.
If this is your current situation, your 4 week Avg is 26, but you and the team are confident you can hit 30, plus you have a 8 pointer almost done. The next sprint, you may go for 28 new story points, plus the 8 pointer that’s almost done, for a total of 36 points. Your next chart would then look like this:
4 Week Avg: 28.75
See, a nice recovery! Don’t let one story missed get you off track. At this point, your 4 week average velocity is 28.75. Talk to your team and see if they want to shoot for 32 next Sprint. As the team gets more acquainted with the process, and more time working with each other, it should be getting better and better. Like a sports team that practices every day.
Simple Agile Release Plan (SARP)
It’s good to add to the Data section of demo a slide for SARP.
|Sprint 8||Sprint 9||Sprint 10||Sprint 11|
The purpose of the SARP is to show what’s coming next so stakeholders have an idea on what’s coming next. It’s not set in stone, and it’s just themes, not detail.
If the PO has a presentable Product Roadmap, could show this too to keep everyone on the same page about where the product is headed. A Product Roadmap is more detailed than a SARP and looks further into the future.
Rotate the Lead
It’s important to rotate who leads the Demo around the team. Some members may be hesitant because of social anxiety. Even more reason to make them, so they can get over that and feel more confident presenting. I think you’ll find those that say they don’t want to do it, will actually appreciate being forced. Saying you don’t want to provides a cover for not being good at it, and then doing it provides the practice needed to actually start being good at it. Forcing the presentation allows them to hide behind the cover of not wanting to, an excuse for not being a good presenter. If you’re a Scrum Master or a leader, you may be the best presenter of the group, but it’s your job to advance those around you. Don’t hog the limelight, you’ll get further by helping other succeed.
It’s a good idea to identify who’s turn it is at the start of the sprint, so that person knows they’re on the hook and can prepare the slides and prepare mentally for the presentation.
If you’re doing 1 week Sprint, 30 minutes is likely adequate. I’m speaking from a software or web application standpoint. Scrum is used in many industries, and I’d imagine demo length time may vary depending on the type of product. You certainly want to respect the time of your audience. Don’t drone on, get to the point, show off, leave time for Q&A, and get people back to their day in a time efficient manner. No matter what industry you’re in, people will appreciate a well organized meeting that is run efficiently.
In the next article, will explain how to hold a productive Retrospective and come out with 2-3 SMART goals each time for incremental improvement to your Scrum process.