By Bob Schatz
The sprint review in Scrum is a critical part of the inspect and adapt cycle. Having worked with many teams and organizations, I have noticed an overall reluctance (and in some cases fear) to do them in the way they were intended.
First, let’s understand what the purpose of the sprint review is. As my friend and mentor Ken Schwaber writes in his first two books, the sprint review is “a 4-hour informational meeting for the team to present to management, customers, users, and the Product Owner the product increment that is has built during the Sprint.”
Focus on the End User
Some companies are reluctant to involve their end users for fear of “scope creep,” others feel they aren’t allowed to ask the end users to be involved, and certain others don’t even know who the end user is! Whatever your reason for not involving them, find a way to do it.
That’s what we did at Primavera when we adopted Scrum back in 2003. We started off demonstrating mostly to our product managers, but we knew something was missing. So we kept thinking about how to increase the value of feedback we were getting, then the obvious solution emerged—we should involve our actual customers! Customer collaboration, remember? So, we started by inviting some of the customers we had always worked closely with and began to expand it little by little.
We had our own challenges to deal with in involving end users. For one thing, we had about 15 Scrum teams all working on the same release of our software. To help keep end users focused, we started using themes for each sprint. Each team had some piece of work that related to the Sprint theme. Having a theme helped end users tailor their feedback towards the theme for the sprint.
Our sprint reviews could best be described as being like science fairs at school. Each team set up a station where they demonstrated what they worked on. The end users, stakeholders, and a few others from our company formed small teams. Each reviewer team started at a different station. We ran 15-minute iterations moving reviewer teams from station to station. It was an environment of high-energy, excitement, and fun.
Involve the Product Owner
You’ll notice that the product owner was not part of our reviewer teams. Instead, the Product Owner was actually responsible for presenting the project. This deviation from the original book definition of a sprint review greatly improved the dynamics of our sprint review.
Too many companies and projects set up their sprint review so that the team is presenting to the Product Owner, as if he should grade them or judge them on their work. This is nonsense! The Sprint Review is not an inquisition or a court of law; it is a way to get feedback from the customer. Instead of presenting to “Judge Product Owner,” teams should instead work with the Product Owner during the sprint to review each story as it’s completed.
Then, when it’s time for the sprint review, the Product Owner should be the first person to stand up, welcome people, and give an overview of the state of the project. The Product Owner should discuss what the overall goals were for the Sprint, what was achieved/not achieved, the quality level of the product, and the release/product burndown. He should then let the reviewers know what they should be looking for and how to provide the feedback. After setting the stage, the Product Owner turns the “show” over to the Scrum teams for the demonstration of functionality.
Understand Group Dynamics
Changing the sprint review audience from a lone product owner to a team or teams of stakeholders and end users dramatically alters the group dynamics. Let’s look at how these roles change once the product owner is part of the presenting team.
Product Owner: The Product Owner is put in a position where he now is acting as a true owner of the product. He has the responsibility and accountability, as part of the overall team, to present the results of their decision-making to the end users and stakeholders. He stands up and presents the product increment and gives insight into the state of the project. Knowing he must do this at the sprint review enforces the discipline to maintain a product/release burndown and know the quality level of the product. Another byproduct of this approach is that any discrepancies between the Product Owner’s representation of the end users’ needs and the actual needs of the end users will surface immediately.
Scrum Team: The Scrum team is now in a better position to present what they’ve done in the sprint with a sense of pride. They get time with the end user, in the best cases face-to-face time. The best way to develop good software that provides the most value to the end user is to know the end user. The team learns how to take feedback, and with every sprint they get a better appreciation for the people they are developing the system for. Another ancillary benefit is that presenting to the end user takes away the feeling of being graded or judged by the Product Owner. Instead, the team leaves the review motivated and energized for the next sprint.
Company Executives/Stakeholders: When executives and stakeholders are invited to the review, they not only get a great view of the real status of the project, they also get to see their teams in action. Additionally, they get time with the end users to hear directly about their needs. Perhaps most importantly, they learn how to behave themselves. It’s amazing how different the dynamics are when customers are around. Instead of the criticizing and bickering that usually goes on, everyone is on their best behavior, so the review becomes much more productive and motivating.
End Users/Customers/Partners: The end users are the stars of the sprint review. They get valuable face time with the people that are developing the software. They come to feel like they are part of the development team. They are engaged. Because they have been so involved in the product’s development, once it is released and put into production, they are usually the product’s biggest supporters inside their own companies. Having knowledgeable advocates for the product at the customer site can also help reduce the usual flood of support calls that are typical immediately after release.
ScrumMaster: The ScrumMaster’s sole role in a sprint review is to facilitate. She makes sure the environment is set up for all of this great stuff to happen—that the right people, supplies, and facilities are there. And she makes sure the pizza is ordered. This may seem like a small detail, but don’t forget to feed people. Food is a great collaboration tool. We had some great conversations in the times where we shared some food.
Remember, this is not a ScrumMaster show. During the review, the ScrumMaster should support the teams, make sure the end users are welcomed and made to feel like part of the team, ensure that they get a chance to be heard, and stay behind the scenes.
Be Courageous
If you want to master the art of feedback, the first step is to create an environment that allows it to happen. It can be scary to involve the end users in the process but remember: it’s better to hear the feedback early and have time to make adjustments than to go down a long path only to find out it was the wrong one. Still afraid of scope creep? Let it go. First, the Product Owner will make the decisions on what trade-offs will be made after each sprint review; and second, you may find out more about what the end users don’t need, which will stop overproduction of features that may never be used.
Focus on the end user, create energy and excitement, and make your sprint reviews an event that your customers want to be there for. All you have to do is create a review that has direct value for them. Then just sit back and listen. You may be surprised by what you learn.
