The Liberators
Published in

The Liberators

Yay, time for a Feedback Party!

Myth: The Sprint Review is a Demo

  • 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;

“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 the Sprint Review

“Collaboration between the Scrum Team and its stakeholders is key during the Sprint Review”

  • 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 afterward 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 valueof 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 PBI’s that were 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

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Christiaan Verwijs

I liberate teams & organizations from de-humanizing, ineffective ways of organizing work. Passionate developer, organizational psychologist, and Scrum Master.