The Sprint Demo (Anti-Pattern)
How many times were you invited to a Sprint Demo? How many times was that demo a presentation of information? Developers telling the Product Owner about stories they completed to get approval? How about reviewing test logs and seeing PowerPoint decks?
If any of that sounds familiar you are missing one of the most powerful aspects of Scrum. You are missing the benefits of the key feedback loop.
The Design of Scrum is to Reduce Risk
Creating new software products involves many types of risk. Risk of not providing the correct solution to customer needs and risk of creating low quality software are two specific types of risk.
To reduce these risks teams leveraging Scrum work in short iterations known as Sprints. Two week Sprints is the most common but it’s not a rule. Teams can experiment to find what duration works best for them but shorter is better from a risk reduction perspective.
When asked what length Sprints should be my response is: “what is the longest the team can afford to go before learning they are off track”? The longer the Sprint, the more money spent before inspection of the results of that Sprint.
Not sure how much is at risk each Sprint? Read my article here.
Gather Feedback, Adapt Accordingly
The correct title for the event in Scrum is The Sprint Review, not The Sprint Demo. The distinction is quite important.
A demo is a one-way push of information. It’s telling rather than listening. It’s presenting rather than asking. The goal is to reflect the current status of the project versus the plan.
A review serves a very different purpose. The goal is to seek information. The goal is to assess value of what the team created and what we plan to create next.
While the team, or the Product Owner, may show some of the new functionality, a better approach is to encourage the customers and stakeholders to get their hands dirty. To test drive the new functionality for themselves.
It’s the difference between reading about, and looking at pictures of, a new automobile and test driving it for yourself. That’s why the first thing a car salesperson will attempt to do is to get you to take it for a spin.
By getting the customers and stakeholders involved, you will get more honest feedback. Don’t only listen to the words, look at the body language and facial expression. Read the room. Do they love it? Are they confused on what it does or how it solves their problems?
Capture their words and reactions. Probe if their responses are unclear. This is when you discover the real requirements.
If they are satisfied, great! Now move on.
If they are not exactly impressed, get the feedback. Then alter the product backlog to better serve their needs. This may be editing existing work items. It may be adding completely new work items, or deleting others. It might even be the beginning of the next Sprint Planning by crafting a draft Sprint Goal.
This is not “scope creep”. Scope creep makes no sense in an Agile environment. Adapting to feedback does. Determine what is necessary and adjust the backlog and future plans based on hands-on feedback. This is powerful risk reduction. Frequent re-targeting and re-forecasting.
If you’re having a demo rather than a review, you are not getting one of the key benefits of Scrum. You are not getting the level of risk reduction that is possible.
Drop the Demo, adopt the Review.
Not Iterative? Why Scrum?
You might be thinking “but we don’t need feedback, we know what to do next”. And in many contexts that can be true. Let’s examine those scenarios.
If your space contains little to no uncertainty or unknowns, meaning you have a finite solution set, the risk of creating the wrong solution is low. The problem and solution are both well understood. Incremental creation is not necessary. Iterating to the correct result doesn’t make sense.
Then I would ask — why are you using Scrum?
Scrum, being a framework, incurs overhead. While it is lightweight compared to other frameworks it does take time away from the team. Time which could be better utilized solving problems and creating solutions.
For a deeper dive on this situation, check out my article on that topic.
If you found this article helpful, please click on 👏 and follow me for more valuable information on Agile, Lean and Book Reviews.
Until next time!
