Essence of Scrum: Sprint Review

The Sprint Review is intended to be an opportunity for learning, not a formal product launch presentation.    The Scrum Guide 2017 says that “This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration. […] The Scrum Master teaches everyone involved to keep it within the time-box.”    A Scrum Book even emphasizes that ‘The event should be time-boxed to a maximum of three hours. The focus is on assessing the product. The Development Team should not spend more than about 30 minutes specifically preparing for this event. Too often a team will prop up the product with temporary supporting structures to make it work well for the Sprint Review, or will spend time trying to “impress” the stakeholders with a sophisticated presentation. There is very little opportunity to be convincing here: the product stands on its own. The team demonstrates the product in an environment approximating that of an end user, without any special “demo support,” and without any props that could make the product appear better than it is. A good rule of thumb is: No PowerPoint® (unless your product is PowerPoint).’ ↩︎

The Scrum Guide 2020 says that in the Sprint Review , “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 Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.”    A Scrum Book says that “It is good for the Product Owner to adopt a vulnerable posture and to hear whether the team endorses and trusts the decisions and directions by which he or she is directing the team, particularly with respect to the product direction and dealing with technical debt and product quality. This helps reinforce the Community of Trust.” ↩︎

A Scrum Book suggests that “A Sprint Review is an opportunity for the team to reflect on their accomplishments during the past Sprint, which contributes to growth in Product Pride. A Sprint Review can be a form of celebration if the team reaches a particularly noteworthy goal, or just for the sake of celebrating now and then. A company in Finland would occasionally have a Sprint Review in a sauna, with good food and drink, going late into the evening. The event covered the perfunctory agenda items but the real focus was for the team to celebrate its work together. (Thanks to Jukka Järvelä for this story!).” ↩︎

The Scrum Guide uses the term “Increment ” to refer to “the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.”    To be more precise, A Scrum Book uses the term “Regular Product Increment ”, and LeSS uses the term “Potentially Shippable Product Increment ” (often abbreviated as “PSPI”). ↩︎

Agile for Everybody says that ‘One of the many ways that organizational leaders often accidentally undermine Agile principles is to continue asking only company-centric questions, such as “Are we on time and on budget?” and “Has your manager approved this?” as opposed to customer-centric questions, such as “How do our customers feel about this change to the product?” One immediate and powerful sign that you’re on the right track is that leaders are asking customer-centric questions or, even better, referring directly to customer quotes and insights.’ ↩︎

The Scrum Guide 2020 says that “The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.” ↩︎

LeSS advocates the “Inspect-Adapt and not Inspect-Accept” concept: “The most common mistake in a Sprint Review is to focus on the Product Owner accepting items from the teams. This is a misunderstanding of the purpose of the Sprint Review and moves it away from empirical process control towards finding blame. The Sprint Review is an opportunity for everyone to collaborate about the product.” ↩︎

LeSS advocates a bazaar-style Sprint Review: “The Sprint Review is best conducted using a diverge-converge meeting pattern. During the diverge periods, use a bazaar. This is analogous to a science fair: A large room has multiple areas, each staffed by team representatives, where the items developed by a team are shown and discussed. Stakeholders visit areas of interest. During the converge periods, stakeholders summarize their opinions from the bazaar. A subset of items may be inspected on a common computer projector during this time, also.” ↩︎