By Bob Schatz
Many of us in the agile community hold a number of things sacred when we are helping others adopt Scrum successfully. I have many of them as I see the intrinsic value of each part as a key to the whole. One of these critical parts is the sprint review. As Ken Schwaber has written previously, “The sprint review is not a presentation, as we have come to know them, nor is it a time of judgment. Some of this is simply learned behavior from our past lives in dreaded project reviews. The applause that we hear is a human reaction of approval.” I have heard this applause in early sprint reviews for new teams—a sense of shock and awe at seeing working software so early.
I have observed and participated in a great number of sprint reviews. I’ve seen some quirky things from the Scrum teams as they attempt to demonstrate the working software and artifacts they have produced in the sprint. Most of them squirm and struggle in the art of telling a story. It’s hard to break the habit of thinking only of the technology and step into the world of the person who will live with the system we build.
An Early Death
We often talk about user stories and use cases in the development of the product backlog items. We want to express features and functions in terms of the end user or system component. We also want to include a statement of a feature’s value. These elements provide the context for the technology and help bridge the communication gap between the developers and the users. These stories help everyone collaborate and discuss the experience that the software needs to provide for the person or persons interacting with it. Unfortunately, in many cases, the story dies once it is implemented, and that makes me sad.
A feature’s implementation is not the end of the story but its birth. Once a story is born it should live for the rest of the project. Its birth is the result of collaboration between the developers and the users in the backlog. It drives discussions through the development of the feature in sprint planning, proves itself as reflected in the acceptance tests, and should spring into action in the sprint review. The story can live on through the operation and maintenance of the system, giving the software a grand purpose in world.
The primary purpose of the sprint review is to demonstrate what has come to life as a result of the collaboration of ideas, to gain a common understanding, and to collect valuable feedback so we can adapt and build better software. Any other purpose is secondary and of lower value to the process. Sure, we can use it to prove how talented our Scrum teams are, to show that we can manage ourselves, to show that we can produce parts of the system early, and prove just how complex the problem we are solving is; but that is not why we do this. It is not a show that needs to be produced.
Breathe Life into Your Sprint Review
The one sure fire way to have a good sprint review is to tell a story. You develop the theme in sprint planning by stringing together backlog items and weaving a plot with the user stories. Then you implement these features, testing them based on the story. Next, you bring that story to the sprint review, giving life to the software. Use real characters and locations; make connections with people and the value that the software provides. A well-developed story will stick with people long after the sprint review.
A good sprint review story has the following components:
- A meaningful; relevant theme;
- A sequence of events as the user would experience them;
- Characters and data that is realistic—use examples and names from your user community or members of the development team;
- Is compelling to the people attending the review;
- Is relevant to the people in the review; and
- Is at an appropriate technical level for attendees.
Then we have to practice as teams to learn how to deliver these stories. Oh, you can just use the excuse that we’re all introverts, but we know this is just nonsense. We all tell stories; it’s one of the oldest forms of communications among humans worldwide. If we’re not engaged in telling the story, then why should we expect anyone else to be interested?
A Tale of Two Sprint Reviews
Here is an example to illustrate the difference between letting a story die and giving it life.
Imagine we have three Scrum teams working on a product release. Each of the teams is focused on a specific functional area of the product. For our example, we’ll use a property management system. Here are a few features that you might see on each team’s backlog:
Asset ManagementThe asset accountant should be able to create an asset record for any capital asset.The asset accountant should be able to settle costs to assets under construction.The asset accountant should be able to depreciate any asset that has been received and capitalized.
Equipment ManagementThe equipment manager should be able to create an equipment master record for any capital or non-capital asset.The system should automatically create an asset record for any capital asset.The equipment manager should be able to loan or lease equipment to other business areas.A user should be able to search for unwanted equipment to find items for re-use.
Equipment DisposalThe equipment disposal manager should be notified of all items ready for disposal.The equipment disposal manager should be able to determine if special handling is required for any item ready for disposal.The equipment disposal manager should be able to tag the item with a valid disposal method.
At the sprint review each team demonstrates the functionality they build going through the backlog items. The team describes each of the features. The users provide feedback on the pieces, which is great, but something is missing.
Now imagine that the three teams have collaborated from the beginning of the sprint and have created a theme for the sprint. Each team is working on a piece of the theme, but all are working toward a living scenario. They think about the types of users they are building software for. They consider who will be involved in the sprint reviews and they begin to write acceptance tests which use actual users’ names, office locations, and real assets that they deal with everyday. Nothing engages users more in a sprint review than seeing their own name, their office, and real world items in the demonstration.
This sprint review begins by the team telling a story as they move through the software features:
Welcome to the Sprint 4 Review. Today we are going to tell you about the day in the life of a critical asset, the Pneumatic Schwaberstopper, in our business.
The Bushwood project places an order for a large, custom-built Pneumatic Schwaberstopper to support the project’s goal to increase production output by 20 percent. Joan Snow, the equipment manager from the Chicago office, logs into the system and chooses to create an equipment record in order to track the asset under construction. Since Joan indicates that this item is to be capitalized, the system automatically creates a corresponding asset record for financial purposes.
As Acme Industrial Supply, the equipment contractor, reports monthly on the cost of the asset, Ted Casey, the asset accountant from New York, records these costs and settles them to the asset under construction account. The asset is delivered and the project team in Houston uses it for several years. Later, Ryan Jessup, the equipment manager in Houston, loans the asset to another area of the business.
After another year passes, the asset is no longer needed. Ryan indicates that the asset is ready for disposal and the system notifies Amy Templeton, the equipment disposal manager. Ted Casey, the asset accountant, then completes the process of fully depreciating the asset. Amy then determines that no special handling is required and tags the item for sale at auction.
Can you imagine how much more compelling a sprint review would be with a little storytelling? Can you visualize how well the story would demonstrate the true intent and functionality of the new features?
Tell Your Story
The team should find creative ways to tell the story and demonstrate the interaction and experience with the system. What’s a key word in that sentence? Creative. Have fun with the sprint review; be enthusiastic and interested in what you’ve done. When you tell the story, try to be animated. Use gestures, hands, inflection and change of cadence in your voice and facial expressions. These elements are what bring people into your story and make them feel a part of it. This opens their minds to the reality of what they are seeing and bingo! the quality and quantity of feedback increases.
So, if you’re not getting the most of your sprint reviews don’t blame the users, stakeholders, or product owners. Get your story straight!
