Myth 12: The Sprint Review is a Demo

(Netherlands)

February 14, 2018

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).

What did you think about this post?

Share with your network

Comments (6)

Cristiano Cadime

02:59 pm February 14, 2018

Excellent post. Shifting this "demo" mindset is somehow the key to get most of the Sprint Review. Collaboration instead presentation.

Olivier

02:06 pm February 16, 2018

"accepting done work" is an interresting and frequent anti-pattern. It assumed implicitelly that the work of the Dev Team is not "done", even if there is a stringent "Definition Of Done".

JVP

12:41 am February 20, 2018

But it is fair to say that a portion of the Sprint Review can be devoted to demonstrating the increment, right? There's nothing in the Scrum Guide that prohibits that, right? I do agree that a Sprint Review shouldn't just be a demo. Still...the increment is at the heart of things and can be a useful way to drive the review. If the Product Owner wants the review to be demo centered....then that's what the review should be given that it wouldn't conflict with the basic purpose of what the review is for. To the extent that as many stakeholders are there, great. I would also caution against suggesting that it is per se not recommended to show any powerpoints or slides. What a team does, within what is promulgated by the Scrum Guide is up to them. If it works, it works. And fi that includes being a demo in whole or part, me being a PSM, PSD, PST, I say so be it.

Christiaan

08:33 am February 20, 2018

Hi John. Of course the inspection of the increment is at the heart of the Sprint Review. I don't think we've stated otherwise. However, a 'Demo' smells of a Scrum Team trying to 'sell' the increment to the stakeholders, rather than engaging in a process of actively inviting stakeholders to participate in the inspection. The context for writing this post was the observation that, for many Scrum Teams, the Sprint Review has devolved into only a (send-only) demonstration, with very limited opportunities for feedback. So no, a demo is not a problem in itself. And neither are PowerPoint-sheets. As long as the focus lies squarely on inspecting a done increment (working software), together.

JVP

01:29 pm February 20, 2018

I get your point because I bring a lot of my own context to the table. To the person new to Scrum, I think their takeaways would be that demos are pre se bad and are not part of the inspection and adaption process. In fact, the post at no time defines precisely what inspection and adaption is and its contrast with a demo. The post begins its conclusion with: "By treating the Sprint Review primarily as a demo, the purpose of this crucial opportunity for inspection and adaptation is lost." Most will interpret that as meaning we can't inspect and adapt via a demo - and I don't believe that is what your real point is.

If we go to first principles and look to definitions, a demo is an opportunity to offer evidence to establish proof of existence and the truth thereof. Inspect means to examine something to determine if it comports with a standard. A demo is the primary means we inspect software. Feedback is the means by which we can adapt. As the Scrum Master, it's my job to make sure the inspection and adaption process is functional and that the Sprint Review supports that - and that's an important point not made in the post. To that point, there should be an interchange of ideas to be used as fuel for the next Sprint Planning session and its up to the Scrum Master to make sure that happens. And a primary part of that is to discuss work not done, unplanned work that cropped up, etc. Also, collaboration is (or at least should be) an on-going process.

The post ends its conclusion with "In this blog post, we busted the myth that the Sprint Review is about demo-ing the Increment to stakeholders. " Respectfully, this post didn't do that because any good Sprint Review is about inspection and the primary means of doing that is observing how the software works. Most people call that a demo. If somebody where intent on making that an issue, I wouldn't give Scrum much of a chance. In other words, it's not a battle worth fighting. If you want to call it something else like verification, affirmation, etc. - fine. It's a distinction without a difference. If there is no interchange of ideas to inspect and adapt, then that is indeed a dysfunction, but not because a demo was part fo the Sprint Review.

Another Life

05:44 pm February 22, 2018

This is why reading and referencing The Scrum Guide is important. It clearly states the aspects of this event.

The Sprint Review includes the following elements:
Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
The Product Owner explains what Product Backlog items have been "Done" and what has not been "Done";
The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
The Development Team demonstrates the work that it has "Done" and answers questions about the Increment;
The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.

http://scrumguides.org/scru...