The Sprint Demo is one of the most important meetings on the sprint calendar. So why are so many sprint demos so poor?

Firstly, why is the Sprint Demo so important? I think for several reasons:

• It makes the progress (or, where applicable, lack thereof) of the team transparent (to management, to other teams, to themselves…).
• It gives the team an opportunity to show what they have achieved and a forum to celebrate their accomplishments.
• Ticking things off a list is fun!

I’ve had to sit through many exceedingly poor sprint demos, most of which could have easily been far better. Here are a few points or tips that I think can help get the most out of a sprint demo.

• There should be an agenda. If you are demoing with multiple scrum teams at once, it should be clear in what order the teams are demoing. Each team should also have an agenda of which stories from the sprint backlog will be demoed.
• There should be a demo computer in the demo room with an agreed and consistent configuration which connected to a demo environment. What is not able to be demoed on the demo computer isn’t demoed – this means no demoing from the developer’s local computer or any other temporary test environments. (Note: the demo computer configuration should ideally match one of your key users.)
• The Product Owner should accept a story as done in the demo, or return it to development (ie, to the product backlog).
• The Product Owner should remember to provide a bit of background to each story as its being demoed – specifically, what the business value for the story is, what problem the story is solving, what benefit there will be, and so on.
• All issues discussed in the demo should be recorded and transferred to either the product backlog or to the bug tracking system. Some teams might like to appoint someone to be the meeting scribe, or the QA people may enter new defects raised directly into the bug system.
• Stories should have passed a certain agreed defintion of ‘done’ before they are eligible to be presented.
• Never cancel the demo. If the team has no stories to show, then display no stories at the demo – but never cancel it. Canceling the demo sets a bad signal to the team that demos aren’t important.
• There shouldn’t be any surprises in the demo, and teams should prepare adequately for the demo if they want it to be a good one.

The demo is the chance to shine and celebrate for you and your team… make it count!