The Sprint Review is perhaps one of the most difficult elements in the product development with Scrum. When I started out as 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 the results to the Product Owner.
After a while I read the Scrum Guide, and I was amazed as 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 Sprint Review facilitation? It seemed to me that all these steps are simply unrealistic to fit into the two-hour session that takes place 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 exactly as it’s designed in Scrum. And I did it!
Structure of the Sprint Review Canvas
Sprint’s review implements at least three principles: collaboration, inspection and adaptation. Steps marked in blue should help to unite all participants, which is important for building trust. The steps that are designed to inspect increment and product backlog are marked in green. Yellow steps refer to the product development adaptation activities. The adaptation block is the most valuable thing that sprint review participants can take away of the meeting.
Sprint Review Facilitation with Sprint Review Canvas
Attendees includes the Scrum Team and key stakeholders invited by the Product Owner. In the beginning of sprint review why not to ask attendees to create cards and write down their name and role.
Scrum Guide says “key stakeholders”, but it doesn’t mean few of them. Key stakeholders can contribute with valuable ideas. I would recommend product owners to invite more key stakeholders interested in the product. The more fan base the team has, the better. For a long time I was wondering why Manchester United, occupying the sixth place in the season, without getting into the Champions League still shows the best financial result among all the teams in the Premier League?
Those teams that are connected with a larger group of stakeholders will be more successful, even if at some stage the results look so-so. Successful facilitation requires diverse people with different views. As the starting point I’d recommend parity principle: on a team of eight people to invite eight key stakeholders. Such number of key stakeholders can be easily found among real users and product support.
The Product Owner or Scrum Master before the meeting can prepare cards with Product Backlog items that are developed in accordance with 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. Yes, it will not show as valuable increment, but why not tell the stakeholders about this victory, even if they have little understanding of the details? Why not to 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 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 taking into account questions or desires from the previous step. Product owner also have to explain how she sees feedback in terms of priorities. Feedback which is not related to any of existing items should adapt to the product backlog. In this step, it 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 the sales department hasn’t brought users to new features.
Main goal of Scrum is creating 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 decisive voice in setting priorities, but any advice card documented in the canvas should help the Product Owner to make informed decisions.
The last stop of the Sprint Review may be the outcome of the meeting. 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 data generated throughout the meeting.
Where to use Sprint Review Canvas
Sprint Review Canvas as a facilitation tool works great in context when you have someone to facilitate. Few stakeholder in the meeting will turn the whole exercise into a formal status rather than a live discussion. You can try this approach in Sprint before 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 bring stakeholders when the team delivers more value. More stakeholders should help with great sprint review, it inspires a team to increase value, and the more value delivered in the subsequent sprints, the more stakeholders will come to the next sprint review. And a mechanism to improve the product development will be started.