Agile myth! Misunderstanding of sprint review | it’s really not a demo show

Time:2021-12-28

Scrum is designed as a simple but sufficient framework for complex product delivery. Scrum is not a panacea or a complete methodology. Instead, Scrum provides minimal boundaries within which teams can self-organize and solve complex problems using empirical methods. This simplicity is its biggest advantage and the source of many misunderstandings and misunderstandings around scrum.

Myth: sprint review is a demonstration

It’s time to sprint again. The development team is demonstrating in one of the conference rooms. When Jim connected his laptop to the projector, Susan nervously rearranged the team’s work record of completing the current sprint. “Shall I show the new shopping cart?” She asked John, a senior developer, in an uncertain voice. John nodded, then paused and added to the shopping cart. “Then, I will display the new order review page”. With the clock set at 11 o’clock, stakeholders began to enter the conference room and clumsily found a place around the huge table. Mary, the product leader, arrived and sat down in a more comfortable chair at the head of the table. She turns to the development team and signals the start of the sprint review; “Break up the meeting”. Forty minutes later, the development team reviewed the list of completed projects and showed everything worth showing. With the end of the demonstration, the audience extended warm applause to the development team. When the stakeholders left the meeting room, the development team breathed a sigh of relief. “Well, this is a great sprint review!” Mary concluded.

In this article, we have solved a misunderstanding that “sprint review” is mainly an opportunity to “demonstrate” the increment to stakeholders.

If you are aware of the following signs, it is for you:

  • Stakeholders are easily separated from the development team and occupy their own rooms;
  • Sprint review is a PowerPoint Presentation containing (allegedly) screenshots of the software;
  • None of the present stakeholders actually use or intend to use the product;
  • Stakeholders have little input (or are not invited);
  • During the sprint review, the keyboard and mouse used to click on the product were never handed over to stakeholders and users, but they were impeccable in the development team.
  • There will be applause after the presentation. To make matters worse, the development team was hushed out of the room.
  • The development team is generally nervous;
  • The sprint team and stakeholders actually refer to the sprint review as a “demonstration”;

By treating the sprint review mainly as a demonstration, the purpose of important opportunities for inspection and adjustment is lost. Too many scrum teams use sprint reviews as a time to show progress, provide “product updates”, sell built products to stakeholders or talk about what they have done.

“Too many scrum teams use sprint reviews as a time to show progress, provide ‘product updates’, sell products to stakeholders or talk about what they are doing.”

Purpose of sprint review

The scrum guide is described as a sprint review of “events held at the end of sprint to check increments and adjust the product to-do list”. “This emphasizes that during the sprint review,” the scrum team and stakeholders collaborate on what sprint does. Based on this and any changes made to the product to-do list during sprint, participants will collaborate on the next steps that can be taken to maximize value. “

“Collaboration between the scrum team and its stakeholders is critical during the sprint review.”

In other words, collaboration between the scrum team and its stakeholders is critical during the sprint review. In scrum, we learned that product development is a complex activity. As we work, the problems we want to solve and the best solutions will emerge from the knowledge we have learned in the development process. Sprint review is a key opportunity in scrum, which can be made possible by generating insights from the work done and providing advice on subsequent steps based on it.

Sprint reviews are designed to make product status (incremental) and product backlog transparent. The scrum team and stakeholders then examine both and share the knowledge learned from the examination. Together with the current market situation, organizational changes, budget and timetable, they jointly decide the next step. The output of the sprint review includes adjustments to the product backlog based on the knowledge learned. In a sense, the sprint review aims to answer the following questions: “based on what we have learned about sprint, what is the next step?” This provides valuable advice for the sprint program.

A good sprint review has the following characteristics:

  • Stakeholders and members of the development team cannot be distinguished from outsiders;
  • Actively invite participants to provide feedback, suggestions and ideas;
  • Product to-do items occupy an important position in sprint review and are actively adjusted with the emergence of new ideas;
  • The sprint review does not introduce the development team to the product owner, but the entire scrum team (including the product owner) shares the increment with stakeholders;
  • The person in charge of the product shall discuss the product to-do items and convey the possible completion date according to the progress;

Tips

  • Before you begin, please reiterate the purpose of the sprint review. Please make sure people understand that this activity is about collecting feedback and solving complex problems together, not “selling products” or “accepting completed work”;
  • Ask development team members to “pair up” with stakeholders and check the increment together. Do not let developers demonstrate incremental on tablets, laptops or desktops, but hand over the keyboard / device to stakeholders and let them experiment under the guidance of developers;
  • Avoid using PowerPoint or screenshots to check incremental status. Practical software is the best way to verify the assumptions and interpretations of developers, users and other stakeholders.
  • Ensure that all developers participate in the sprint review. The sprint review is an ideal opportunity to collect product feedback on developer improvements / scaling / updates during sprint. At best, the sprint review is an event with stakeholders who are really involved in the progress of the scrum team and are eager to see and discuss the results.
  • Use a valid format and don’t sit at your desk and look at the screen. Use coaching techniques to engage all participants.
  • The sprint review should be a “feedback party” rather than the development team browsing the “completed work” list when everyone else is sleepy.
  • Invite real users to the sprint review. These are the people who (will) actually use the product and are most capable of determining whether the product “works well”. However, please try to avoid turning sprint review into “user acceptance test”;
  • Change the format. Change the format of sprint review according to the context. Sometimes, it’s best to set up different “market stalls”, in which developers will be set to highlight specific aspects of the product. Sometimes it is most effective to focus on the presentation and then have a convenient discussion. The scrum team should constantly look for the best way to collect feedback from stakeholders;
  • At the closing ceremony, ask participants how to (further) improve the value of sprint review according to the progress;
  • Invite participants through e-mail, newsletters or personal invitations, and explain why participants are so important;
  • Be open and transparent to unfinished work. Not all scrum trainers agree that sharing unfinished work is a good idea. Because this may lead to wrong expectations. However, we believe that examining the unfinished work can produce valuable insights. It can tell us some information about obstacles, bottlenecks or other problems. Focus on identifying these problems during sprint review, but leave their solutions to sprint review;

end

In this blog post, we broke the misunderstanding of “sprint review” about demonstrating incremental to stakeholders. Although the presentation can certainly be part of the sprint review, it does not capture the true meaning of the sprint review: the collaboration between the scrum team and stakeholders to check the increment and progress so far and determine the most valuable next step.

Discussion area

  • How was your sprint review conducted?
  • Are stakeholders invited?
  • What do you think of this misunderstanding?
  • Do you realize that sprint reviews are more than just a demonstration?
  • What have you learned?

Welcome to leave a message for discussion.

This article started on Bob Jiang’s blog. For reprint, please contact Bob Jiang