Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve a complex problem using an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths surrounding Scrum. In this series of posts we — your ‘mythbusters’ Christiaan Verwijs & Barry Overeem — will address the most common myths and misunderstandings. PS: The great visuals are by Thea Schukken. Check out the previous episodes here (1, 2, 3, 4 , 5, 6, 7, 8, 9, 10 and 11).
Myth: The Sprint Review is a Demo
Sigh. It is that time of the Sprint again; the Sprint Review. The Development Team is setting up shop in one of the meeting rooms. While Jim connects his laptop to a beamer, Susan nervously re-arranges the notes of the work the team completed this Sprint. “Shall I demonstrate the new shopping basket?” she asks senior developer John with a hint of uncertainty in her voice. John nods, and - after a pause - adds “Sure. I’ll show the new order review page then”. As the clock hits eleven, the stakeholders start dropping in and awkwardly find spots around the huge table. Mary, the Product Owner, arrives and settles in one of the more comfortable chairs at the head of the table. She turns towards the Development Team and signals the start of the Sprint Review; “Take it away guys”. Forty minutes later, the Development Team has gone through their list of completed items and demonstrated everything worth showing. As the demonstration wraps up, the audience offers a mild applause to the Development Team. As the stakeholders are leaving the room, the Development Team sighs in relief. “Well, that was a great Sprint Review!”, Mary concludes.
In this post, we address the myth that the Sprint Review is primarily an opportunity to ‘demo’ the increment to stakeholders.
This post is for you if you recognize one or more of these telltale signs:
- Stakeholders are easily distinguishable from the Development Team, both occupying their own side of the room;
- The Sprint Review is a Powerpoint-presentation with screenshots of (supposedly) working software;
- None of the stakeholders present are actually using, or going to use, the product;
- There is hardly any input from stakeholders (or they’re not invited to);
- The keyboard and mouse used to click through the product never actually reaches the hands of stakeholders/users during the Sprint Reviews, but remains soundly with the Development Team;
- There is applause after the demonstration completes. Or worse, the Development Team is booed out of the room;
- There is a general air of nervousness in the Development Team;
- 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.
“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 “is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed”. It emphasizes that during the Sprint Review, “the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value”.
“Collaboration between the Scrum Team and its stakeholders is key during the Sprint Review”
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 to build on them to inform the next steps.
The Sprint Review is about making the state of the product (Increment) and the Product Backlog transparent. The Scrum Team and stakeholders then inspect both and share insights on what was learned from that inspection. Together with current market conditions, organizational changes, budget, and timeline, they decide together on next steps. The output of the Sprint Review consists of adjustments to the Product Backlog based on what was learned. In a sense, the Sprint Review is about answering the question: “Based on what we learned this Sprint, what are the next steps?”. This provides valuable input for the Sprint Planning.
Optimally, the Sprint Review has the following characteristics:
- Stakeholders and members of the Development Team would be indistinguishable to an outsider;
- Participants are actively invited to offer feedback, suggestions, and ideas;
- The Product Backlog has a prominent place during the Sprint Review, and is actively adjusted as new insights emerge;
- 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;
- 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. Make sure that people understand that the event is about gathering feedback and navigating complexity together, not ‘selling the product’ or ‘accepting done work’;
- Ask members of the Development Team to pair up with stakeholders and inspect the increment together. Instead of having the developer demonstrate the Increment on a tablet, laptop or desktop, give the keyboard/device to the stakeholder and let them experiment under the guidance of the developer;
- Avoid Powerpoint or screenshots as a means to inspect the state of the Increment. Clicking through working software really is the best way to validate assumptions and interpretations of developers, users and other stakeholders;
- Make sure that all developers attend the Sprint Review. The Sprint Review is an ideal opportunity to gather feedback on the product as improved/extended/updated by developers during the Sprint. Best case, the Sprint Review acts as a great motivating event with stakeholders that are truly engaged with the progress of the Scrum Team and are eager to see and discuss the results;
- Use active formats, don’t sit around a table looking at a screen. Use facilitation techniques (like Liberating Structures) to actively engage all participants. The Sprint Review should be a ‘feedback party’, not a Development Team going through a laundry list of ‘work completed’ while everyone else falls asleep. Use format such as 1-2-4-ALL, Shift & Share or a carousel to break down larger groups into rotating pairs of small groups. Use Impromptu Networking or What, So What, Now What after inspecting the Increment to explore next steps or offer suggestions for the Product Backlog;
- Invite real users to the Sprint Review. These are the people that (will) actually use the product, and are most capable of determining if the product ‘works well’. Do try to avoid turning the Sprint Review into a ‘user acceptance test’ though;
- Change the format. Vary the format of the Sprint Review based on context. Sometimes, it works best to set up different ‘market stalls’ where developers set up to highlight particular aspects of the product. Sometimes a central demonstration with a facilitated discussion afterwards works best. A Scrum Team should continuously search for the best way to gather feedback from stakeholders;
- As part of the closing, ask participants what can be done to (further) improve the value of the Sprint Review based on how it went;
- Invite participants with an e-mail, newsletter or personal invitation to attend, explaining why their presence is important;
- Be open and transparent about undone work. Not all Scrum Trainers agree that sharing undone work is a good idea as it may create false expectations. But we feel that valuable insights can emerge from inspecting the work that was not completed. It may tell us something about impediments, bottlenecks or other issues. Focus on identifying these issues during the Sprint Review, but leave their resolution to the Sprint Retrospective;
Closing
In this blog post, we busted the myth that the Sprint Review is about demo-ing the Increment to stakeholders. Although a demo certainly can be part of a Sprint Review, it fails to capture what the Sprint Review is actually about: a collaboration between the Scrum Team and stakeholders to inspect the increment and progress to date and decide on the most valuable next steps.
What do you think about this myth? Do you recognize the Sprint Review being only a demo? What are your lessons learned?
Want to separate Scrum from the myths? Join our Professional Scrum Master or Scrum Master Advanced courses (in Dutch or English). We guarantee a unique, eye-opening experience that is 100% free of PowerPoint, highly interactive, and serious-but-fun. Check out our public courses (Dutch) or contact us for in-house or English courses. Check out the previous episodes here (1, 2, 3, 4 , 5, 6, 7, 8, 9, 10 and 11).