A 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 when I read 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 to me that all these steps are simply unrealistic to fit into the two-hour session that takes place between 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.
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 important for building trust. The steps that are aiming to inspect increment and product backlog are marked as green. Yellow steps refer to the adaptation activities. The adaptation block is the most important thing that sprint review participants can take away of the meeting.
Sprint Review Facilitation with Sprint Review Canvas
Attendees
Attendees includes the Scrum Team and key stakeholders invited by the Product Owner. In the beginning of 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 "few" of them. Key stakeholders can contribute with valuable ideas and 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 while occupying the sixth place in the season and without getting into the Champions League still shows the best financial result among other 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 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.
“Done” Increment
Before the meeting a product owner or scrum master 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.
Team Voice
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 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.
Demonstration
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.
Backlog Product
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 or he sees feedback in terms of priorities. Feedback which is not related to any of existing Product Backlog items should be somehow reflected in 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.
Increment Value
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 ther weren't introduced to new features.
Stakeholder’s Voice
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 decisive voice in setting priorities, but any advice documented in the canvas should help the Product Owner to make informed decisions.
Summary
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 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 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 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 organized properly it turns into positive self-reinforcement loop improving overall product development with Scrum.
