A Sprint Review is perhaps one of the most challenging elements in the product development with Scrum.
When I started out as a Scrum Master, I didn’t attach much importance to this meeting. Therefore, during the first three years in this role, all my sprint reviews were limited to showing sprint results to the Product Owner.
After a while, when I read the Scrum Guide, it turned out that I did not understand the purpose of this meeting. Since then, the Sprint Review became something special to me.
8 Steps of Sprint Review
Do you know that Scrum Guide describes at least 8 steps of the Sprint Review? It seemed that all these steps are simply unrealistic to fit into the two-hour session between the scrum team and the group of stakeholders. That’s why I came up with Sprint Review Canvas, a facilitation tool that helps me to drive Sprint Reviews precisely as it’s designed in Scrum.
Structure of the Sprint Review Canvas
Sprint review implements at least three principles: collaboration, inspection, and adaptation. Steps marked in blue should help to unite all participants, which is essential for building trust. The steps that are aiming to inspect increment and product backlog are marked as green. Yellow steps refer to adaptation activities. The adaptation block is the most remarkable thing that sprint review participants can take away from the meeting.
Sprint Review Facilitation with Sprint Review Canvas
Attendees include the Scrum Team and key stakeholders invited by the Product Owner. At the beginning of the sprint review, the facilitator can ask attendees to create cards and write down their names and roles.
Scrum Guide says key stakeholders, but “key” doesn’t mean just a “few” of them. Key stakeholders can contribute valuable ideas, and I would recommend product owners invite more key stakeholders interested in the product. The more fan base the team has, the better. For a long time,
I wondered why Manchester United, while occupying sixth place in the season and without getting into the Champions League, still shows the best financial result compared to other teams?
Those teams connected with a larger group of stakeholders will be more successful, even if the results look so-so at some stage. Successful facilitation requires diverse people with different views. As the starting point, I’d recommend the parity principle: on a team of eight people to invite eight stakeholders. I can easily qualify real users and product support as key stakeholders; therefore, it shouldn’t be a problem to find people for Sprint Review.
Before the meeting, a product owner or scrum master can prepare cards with Product Backlog items that are developed following the definition of “Done.” During the meeting, the Product Owner briefly explains to the stakeholders what’s new in the increment.
Before a meeting, the development team can prepare cards to highlight the difficulties and victories when it makes sense. For example, the team implemented testing automation, which doesn’t show as a valuable increment. But why not tell the stakeholders about this victory, even if they have little understanding of the details? Why not explain how automation will help the team with further development.
For an engaging demonstration, I’d mix the development team members with the stakeholders and split them into smaller groups of four. In small groups, developers will have less stress to demonstrate what they did in the current sprint. Stakeholders can park their questions and desires into the Sprint Review Canvas. Such a dynamic demonstration takes no longer than 30 minutes.
After the demonstration, the product owner shows priorities for the next sprint considering questions or desires from the previous step. The product owner also has to explain how she or he sees feedback in terms of priorities. The input that is not related to existing Product Backlog items should be somehow reflected in the Product Backlog. This step would be a good idea to show the stakeholders a forecast for the next release using Release Burn-Down Chart or any other suitable tool.
In this step, the facilitator can offer stakeholders to work on insights. Did any of the stakeholders see new opportunities for the product? What is the bare minimum to do to realize these opportunities in the market? Very often, the product remains undervalued by users just because it is little studied. I’ve seen quite a few cases where customers don’t use valuable functionality because they weren’t introduced to new features.
The main goal of Scrum is to create a valuable product. And who, as not stakeholders can give the team useful inputs for the next sprint. Of course, only the Product Owner has a strong voice in setting priorities, but any advice documented in the canvas should help the Product Owner to make informed decisions.
Perhaps the revealed facts will require adaptation of budget, forecasts, risks. The facilitator may ask participants to create cards describing what else requires adaptation considering the meeting’s data.
Where to use Sprint Review Canvas
Sprint Review Canvas as a facilitation tool works great in context when you have a good number of people with different views and backgrounds. One stakeholder in the meeting will turn the whole exercise into a formal status rather than a live discussion. You can try this approach in a sprint before the production release.
Stakeholders always have more motivation to participate when they have something to see. Well, for the Product Owner, it is much easier to invite stakeholders when the team delivers more value. More stakeholders should help with a great sprint review, which inspires the team to increase delivered value. And the more value delivered in the following sprints, the more stakeholders will be willing to attend a sprint review. When sprint review is organized properly, it turns into a positive self-reinforcement loop improving overall product development with Scrum.
Slava Moskalenko, CEO of Agile.Live
This article was first published on Scrum.org