Okay I’ll admit it; I believe vocabulary is important. My publisher almost freaked out when I submitted a 22-page glossary to be published in my Essential Scrum
book. But, I felt it necessary to define every relevant agile, Scrum, and software-development term that I used—both as an aid to the reader and also to ensure that I used the terms in a consistent way throughout the book.
The words we use can inform both our understanding and our actions. Which brings me to what I really want to discuss. In my experience working with many Scrum teams, people more often than not refer to the sprint review
as the sprint demo
. This may seem like a simple example of word substitution: “Aren’t review and demo the same thing?”
Mistaking the Means to the Goal with the Goal Itself
No, in my opinion they are not. Calling the review a demo tends to refocus the activity on a means to the goal
instead of on the goal
itself. Giving a demonstration of the working software that the Scrum team just got done is a common practice at most sprint review meetings. But let’s not mistake the goal of the sprint review for a practice we might perform to achieve the goal.
The goal of a sprint review is not to give a demonstration; rather, the goal of the sprint review is to inspect and adapt the product that is being built. In my experience, teams that call the meeting a demo believe that the only goal of the meeting is to give a demo. And, therefore, a successful demo equals a successful meeting! This misses the whole point of a sprint review! Let’s see why.
Anatomy of a Sprint Review
The following picture will clarify how I view the sprint review activity.
You can download a hi-res copy of the Sprint Review and other images from the
Visual AGILExicon® at Innolution.com
At the top of the picture you will see that there can be many participants at a sprint review. On the left of the picture are the inputs: the sprint goal and sprint backlog
, which collectively define what the team planned to do this sprint. The potentially shippable product increment is what the team actually got done.
Now look at the icon in the center of the picture (the two orange arrows with the blue cube in the middle). It represents the sprint review itself. Notice that the focus of the sprint review is to inspect and adapt the product increment that was produced during the sprint. More specifically, we inspect what was just built and, based on the feedback that we get from our stakeholders, we can adapt what we build next by grooming the product backlog, which is shown as an output on the right side of the picture. Large adaptations (pivots) to our target product might also cause us to update our release plan.
Below the sprint review icon I illustrate a common approach for conducting the sprint review meeting. In this approach the first step is to review the goal and committed/forecasted features and compare that to what actually got accomplished during the sprint. Next you’ll see a demonstrate
step. This is where the team members often demonstrate what they built. So, in this picture, giving a demonstration is simply one step of the overall sprint review activity
. The real purpose of the demonstration is to enable the next two steps: discuss and adapt. The demonstration is useful to the extent that it enables a thoughtful discussion on what we just built and its ability to inform any changes we would like to make for what we will build in the future.
To be clear, the most important aspect of the sprint review is the in-depth conversation and collaboration among the participants, not the demonstration. These discussions enable productive adaptations to surface and be exploited. A review isn't a one-way flow of information, where the team is doing all of the showing and telling. It's an opportunity for the Scrum team members to get feedback from customers or users. The sprint review therefore represents a scheduled opportunity to inspect and adapt the product. If you are interested in exploring the sprint review in more detail, I refer you to Chapter 21 of Essential Scrum
Reviews Without Demos
I’ll end with an example to re-emphasize the point that giving a demo is simply one means of enabling the inspect-and-adapt goal. Some teams don’t use demos at all
I work with several game studios. At their sprint review meetings it is often more effective to allow the stakeholders to just play the game instead of team members demoing it (essentially playing it for them). In one instance I recall the team members were all set to give a demo of the new game features and one of the principal stakeholders said, “Move over, I’ll drive. Let me play and see if I think it’s fun!”
So, if you are calling the sprint review the sprint demo, I strongly suggest you stop. Keep in mind that the real goal is not to give a demo, but to inspect and adapt the product. What do you think? Please leave your comments below.