In this post, we address the problem considering that the Sprint Review is primarily an opportunity to ‘demo’ (which is wrong) the increment to stakeholders.
This post is for you if you recognize one or more of these telltale signs⚠️⚠️⚠️:
1️⃣ Stakeholders are easily distinguishable from the Development Team, both occupying their own side 🪓 of the room;
2️⃣ The Sprint Review is a Powerpoint-presentation 🖼️ with screenshots of (supposedly) working software;
3️⃣ None of the stakeholders present are actually using ❌, or going to use, the product;
4️⃣ There is hardly any input from stakeholders🙊 (or they’re not invited to);
5️⃣ The keyboard⌨️ and mouse🖱️ used to click through the product never actually reaches the hands of stakeholders/users during the Sprint Reviews, but remain soundly with the Development Team;
6️⃣ There is applause 👏 after the demonstration completes. Or worse, the Development Team is booed 👎 out of the room;
7️⃣ There is a general air of nervousness 😰 in the Development Team;
8️⃣ The Sprint Review is actually called a ‘Demo 🤦♀️ by the Scrum Team and stakeholders;
By treating the Sprint Review primarily as a demo, the purpose of this crucial opportunity for inspection and adaptation is lost.
“Too many Scrum Teams approach the Sprint Review as their moment to show progress, to give a ‘product update’, to sell what was built to stakeholders or to talk about what *they* did.“
The Purpose of the Sprint Review
The Scrum Guide describes the Sprint Review as an event that
"
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations.
The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment.
Based on this information, attendees collaborate on what to do next.
The Product Backlog may also be adjusted to meet new opportunities.
The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint.
For shorter Sprints, the event is usually shorter.
"
👉"THE SCRUM TEAM SHOULD AVOID LIMITING IT TO A PRESENTATION"
In other words, the collaboration between the Scrum Team and its stakeholders is key 🔑 during the Sprint Review.
In Scrum, we understand that product development is a complex 😩 activity.
As we do the work, both the problem we’re trying to solve and the optimal solution will emerge from what we learn during development.
The Sprint Review is a critical opportunity in Scrum to make this possible by letting insights emerge from the work that was done and building on them to inform the next steps.
Optimally, the Sprint Review has the following characteristics:
1️⃣ Stakeholders and members of the Development Team would be indistinguishable from an outsider;
2️⃣ Participants are actively invited to offer feedback 🗣️, suggestions, and ideas💡;
3️⃣ The Product Backlog has a prominent place during the Sprint Review, and is actively adjusted 📐 as new insights emerge;
4️⃣ Rather than the Development Team presenting the Increment to the Product Owner, the Sprint Review is more about the entire Scrum Team (the Product Owner included) sharing the Increment with stakeholders;
5️⃣ The Product Owner discusses the Product Backlog and communicates likely completion dates based on the progress;
Tips
📢 Reiterate the purpose of the Sprint Review before you start.
🧑 🤝 👩 Pair up with stakeholders.
🖼️ Avoid Powerpoint or screenshots.
🧑 💻 Make sure that all developers attend the Sprint Review.
⚽ Use active formats.
👥 Invite real users to the Sprint Review.
🎬 Change the format.
🗣️ Improve the value (feedback survey).
📧Invite participants.
👷 ♂️ Be open and transparent about undone work.