Many of our clients initially believe that the Sprint Review and Sprint Demo synonymous. In fact, they are not. There are several steps to running an effective Sprint Review, but the Demo portion is just one. I recently wrote about this in How to Run an Effective Sprint Review.
In this article, I will shift focus to the Demo portion of the Sprint Review, providing general guidelines as well as a detailed framework to help make your demo awesome.
Key aspects of the Sprint Demo
Demonstrations are a powerful and important part of effective Sprint Reviews. I’ve found that the most effective demonstrations are given to stakeholders directly by the Development Team. There are three key aspects for the Development Team to remember to deliver a great Sprint Demo:
- Be present and engaged: The Sprint Demo is the Development Team’s opportunity to interact directly with stakeholders of the product. It is important that members of the Development Team put their best foot forward, so take at least a little time to prepare.
- Talk in terms of business value: Stakeholders want to know that the Development Team understands the business impact of what they are building. The more they speak in language familiar to stakeholders while demonstrating the product, the more likely the Scrum Team is to unlock a treasure trove of valuable business context and feedback crucial for the product’s success.
- Avoid reacting to feedback or questions defensively: The Development Team has worked hard and may have an immediate reaction to tough feedback. Stay curious and ask open-ended questions and try your best to not become defensive if stakeholders do not immediately connect with what you are doing or building. As soon as you feel overly defensive, you’ll miss the gems of insight stakeholders can provide.
Putting work in the context of value is an overarching theme of effective Sprint Reviews and demonstration of the working product increment. That said, many members of the Development team have not been afforded the opportunity to interact with business stakeholders, so focus and attention to developing those new communications “muscles” are necessary. Development Teams who are not practiced in communicating directly with Stakeholders and effective demonstrations may find it useful to leverage a scripted framework for communicating with stakeholders to explain the value delivered as a result of the Sprint.
Sprint Demo Framework
|Introduction to the Development Team
|“Hello, This is the team, this is who we are, and this is what we do…”
|Establish a personal connection between the Development Team and Stakeholders. Repeat when new stakeholders are in attendance.
|“Today we will demonstrate [new experience, new capability, new functionality] in order to achieve [insert goal].”
|Connect the “business why” to the priority and goal of the work.
|“To achieve this, we [insert new…”
Example: “The new registration experience begins here. A new customer does X, then Y, and saves results here.”
|Demonstrate the product increment in understandable terms.
Pro Tip: No need to talk about specific backlog item details, i.e., JIRA ticket numbers. The flow may naturally cover several items.
|“Here’s a quick synopsis of the results….”
“We learned that….”
|Reveal the quantitative value of the work delivered against the business goal and any learnings.
|“What do you think?”
“What questions can we answer about what we just shared?”
“How well did we meet your expectations?”
|Ask open-ended questions to engage the stakeholders in dialogue on the value the Development Team delivered.
|“Let’s move on to … [insert next capability to demonstrate]
|Keep the demonstration flowing and moving on to the next capability.
As Scrum teams become more comfortable with the structure of the demonstration and the overall Sprint Review, they often abandon the framework for what flows naturally. I would recommend that the team even do some dry runs in advance of the Sprint Review to ensure that the time with stakeholders is highly productive. This is a good and progressive step in their Agile journey.
A strong partnership between the Development Team and Stakeholders often makes the difference between success and failure. It’s worth the time and effort to review with the Development Team the key aspects of demonstration, talk in terms of business value, and avoid defensiveness. Get your team together to reinforce the purpose of the demonstration, list questions you already know you’d like to pose to the stakeholders, give examples of how to handle critical feedback with probing curiosity rather than defensiveness and maintain a cadence for your demos so your stakeholders trust that they will have regular conversations about the solution they are building.
Prepare your Development Team in advance, and use the scripted language in the framework above to practice strengthening their communication skills until a strong working relationship and rapport becomes natural.