Are You Focusing on the Right Thing in Your Sprint Reviews?
The Scrum Guide defines a number of events that are supposed to help set a cadence for the team and reduce the need for other meetings. All the scrum meetings have value, but all are easy to do incorrectly, as they are simiar to meetings that non-Scrum teams have.
I've written before about the importance of retrospectives. Another end-of-sprint event that is an important source of feedback and is often misinterpreted is the sprint review.
Sprint reviews provide a forum for improvement, but they are not meant to be intense affairs with lots of preparation. The Scrum Guide explains, "This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration."
The increment is the sum of all the product backlog items completed during the sprint. But the demonstration of these items is not the most important part of the review.
The role of demonstration in a sprint review often takes on more importance than it should, even to the extent that some teams refer to the review as a demo. Ken Rubin explains that the emphasis on the demonstration changes the focus of the review from being on its goal (improving the product) to being on the means to the goal (the additional functionality):
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!
Rubin goes on to explain that the most important part of the review meeting is the conversation about how features went from backlog items to working software, and and as a forum for the team to get feedback (positive and negative) from stakeholders.
By focusing on the demo you risk the review meeting being one where the team is doing all the talking, rather than a two-way conversation between the team and the stakeholders. In some cases, if you have multiple stakeholders, the review can help stakeholders identify interactions that they were not aware of, thus enabling conversation among stakeholders that can help the team.
Considering the role of a demo in a sprint review is expecially important when your team is delivering frequently and the stakeholders have already seen much of the functionality. In these cases it may be best to focus demo time on features completed at the end of the sprint, features that required a lot of discussion to implement, features that supported multiple stakeholders, or features that had the biggest requirements risk.
Even if you can allocate review meeting time to demo all of your work, whatever time you allocate may be best spent taking advantage of the ability to have a conversation about product direction, goals, and the many other elements of project context that can get lost when you begin planning user stories.
Do you do regular sprint reviews? What are the best parts for you?
