Article summary
The demo is one of the most important aspects of the sprint ceremony. At this point, your client has already seen the visual design of new features, but this is their first chance to see features in action.
I’ve been a part of some very successful feature demos, and some that haven’t gone so well. Here are three tips to make your next sprint demo a successful one.
1. Prepare and Practice
I usually spend 15 to 30 minutes preparing my demo before a sprint review. Preparing gives me confidence that the demo will go smoothly when it’s time for the real thing. It also forces me to think about how to order the features that I’m sharing. If a set of features fit into the same workflow, I’ll demo them in the order they appear in the workflow. If they’re mostly unrelated, I will demonstrate the features that I think are most important first.
Another important part of preparation is getting interesting data into the system. Without interesting data, the demo will underwhelm the client. And unless you represent all of the states of the workflow, you may miss out on some opportunities for valuable feedback.
2. Provide Context
As a developer, you have a deep knowledge of the features that you are demonstrating…after all, you did develop them. It’s an easy mistake to dive right into the specifics of the feature. You already have all of this knowledge and context built up in your head, but remember, your client may not. It’s important to share that context so clients can ask good questions and give good feedback.
For example, let’s say you’re demonstrating a feature where a user can download a PDF report of a questionnaire they just completed. In a previous sprint, you completed the work for taking the questionnaire, and now the link appears somewhere in the user’s dashboard.
A bad demo would start with, “OK, so we built this PDF report feature. You can click a link on the dashboard, and it will open a new tab showing you the PDF.”
In a good demo, you might say this instead: “Imagine I’ve just finished completing a questionnaire and the app has taken me back to my dashboard. You can see the entry for that particular questionnaire in the list. You’ll notice that there’s now a link in that entry labeled, ‘Take me to my report.’ I can click that link, and a new tab will open with my questionnaire results.”
The second demo told a story about how we got to the start of the demo. It provided context about the state of the system and the workflows that took the user to that point.
3. Be Conscious of Your Speed
One of the biggest mistakes I see developers make during a demo is flying through the features. It’s important that the client has the opportunity to digest and think critically about each feature. The main purpose of the sprint demo is to get feedback from the client. If you demo too quickly, they may disengage instead of sharing valuable feedback.
One way to slow down your demo is to pause after each feature to take questions. Instead of saying, “Do you have any questions about that?”, ask in a more specific way. If you’ve just finished demoing a feature about a signup workflow, ask, “Do you have any questions about user registration or the confirmation email?”
Another technique I use is to take notes on paper. It takes longer to write these notes, and that gives the customer more time to think about any other feedback they may have.
Demoing your work should be an exciting, even celebratory, experience. It took a lot of hard work to complete this feature, and you should be proud, so don’t come into the demo nervous and unprepared. Prepare, pace yourself, and provide context, and you’ll do a fantastic job.