Bringing Customers into the Sprint Review - Part 3

In the previous two blog posts in this series, we discussed the significant benefits of bringing your customers into your Sprint Reviews and some anti-patterns to watch out for when you do so. Wrapping things up on the topic of bringing customers into the Sprint Review, let’s talk about some different formats you may want to consider for your Sprint Reviews.

If you have lots of teams working in the same location on the same product and you have a good number of customers who are willing to visit your office for a Sprint Review, conducting your Sprint Review in a science fair format is a highly interactive method of interacting with your customers and your internal stakeholders. Remember when you were in school growing up as a child of participating in or attending the school’s science fair? Like in a science fair, you can set up each Scrum team in a different room or in a different part of a very large gathering area in your office. You then divide a mix of your attending customers and internal stakeholders into different groups,, with the number of groups equaling the number of teams that you have. Each group spends 10-15 minutes with one of the scrum teams, with the team sharing the highlights of what they’ve added to the product during the sprint as well as any relevant learning. Keeping the individual groups small allows for a give and take of questions and discussion between the team, your customers, and your internal stakeholders. At the end of the 15 minutes, each group moves on to the next team on their list. This format encourages detailed and intimate discussion and feedback, and keeps people focused by having them move every 15 minutes, As always when you gather people in your office, you should provide food to add to the excitement of the event and to provide another place for conversation and camaraderie. The biggest obstacles to this approach are that people aren’t traveling as much anymore, many teams are not located in the same office, and many teams are not going into the office anyway. Disadvantages of the science fair approach is that a team doesn’t get to hear about what other teams have accomplished during the sprint and that each team needs to hold multiple sessions of sharing their accomplishments, one for each group. One modification that addresses all but the multiple sessions per team is holding the “Science fair” Sprint Review over whatever web conferencing platform you use and recording the sessions for anyone internally who wants to view sessions they could not attend or to review the feedback received in their sessions.

Another format that one frequently sees is where everyone in attendance gathers together, whether physically in one place or virtually through web conferencing, Each scrum team takes a turn sharing the value that they created during the sprint, with the product owner speaking first to bring everyone up to date on the context of the work undertaken during the sprint. Customers, internal stakeholders, and other scrum teams ask questions and provide feedback, as appropriate, during each scrum team’s sharing session. The logistics of this approach are simpler and you don’t have the issue of the scrum teams missing out on what their colleagues accomplished on the other scrum teams. Food works just as well for this approach too with the same benefits. The biggest drawback to this approach is that there are more people in the room, physically or virtually, which means that there are many voices that you would have heard from in the science fair approach that you won’t hear from with the “everyone together” approach.

I’ve also seen a supplement of this approach where someone in the organization opens up the Sprint Review by sharing a parable or story, perhaps tying in some of the themes that were worked on in the sprint and even current events or industry trends. This serves two purposes - providing a familiar, low-key transition into the Sprint Review and additional context for customers and internal stakeholders to consider as they learn about the value added to the product or service during the sprint.

One question that often comes up is what role the Product Owner should play in the Sprint Review and what the role the Developers on the Scrum Team should play. Note that when I refer to Developers in this context, I mean anyone on the Scrum Team beyond the Product Owner and the Scrum Master. While I don’t think there is one right answer to this question, I think most would agree that both the Product Owner and the Developers have contributions to make during the Sprint Review and both should participate. The Product Owner is usually in the best position to talk about product goals, and business context, and they likely have spent the most amount of time with the customers, so having them “set the scene” for customers prior to the Developers sharing the highlights of their work often makes sense. Since the Developers are the ones that have not only completed the work but also took ownership and accountability for completing the work, they should be the ones to share their work with the attendees. Given that the most important goal of the Sprint Review is to get feedback from customers and internal stakeholders, whatever combination of Product Owner and Developer participation results in the most complete feedback provided to the entire team is what you should aim for.

Finally, if you aren’t getting the participation, feedback, or results that you want from your Sprint Reviews, please experiment with changes to your Sprint Review format until you find the right format for your teams and your customers. Learn and adapt until you get the feedback you need from your Sprint Reviews.