Sprint Review Anti-Patterns
An Excerpt from the Scrum Anti-Patterns Guide (8)
Hello everyone!
Welcome to the eighth excursion into Scrum anti-patterns—the Sprint Review.
However, before we delve into these, let’s briefly detour and address the Sprint itself.
The Purpose of the Sprint
The purpose of the Sprint is clearly described in the Scrum Guide—no guessing is necessary:
Sprints transform hypotheses into value.
They are consistent, fixed-length events of one month or less, with new Sprints starting immediately after the previous one ends.
Every activity required to achieve the Product Goal, such as Sprint Planning, Daily Scrums, Sprint Review, and Sprint Retrospective, occurs within Sprints.
Sprints foster predictability by inspecting and adapting progress towards a Product Goal at least every calendar month.
If a Sprint‘s length is too long, the market may invalidate a Sprint Goal; complexity and risk may increase.
Shorter Sprints promote more learning cycles and limit the risk of cost and effort to a briefer time frame, resembling short projects.
Scrum as a framework is mainly tactical; see Figure 05.1. The Sprint is about delivering value to customers, guided by the Sprint Goal, based on previously explored and validated hypotheses. It is all about getting things out of the door, thus closing the feedback loop and starting another round of inspection and adaption.
Besides working on accomplishing the Sprint Goal, a Scrum Team also allocates time to product discovery, aligning with stakeholders, and refining an actionable Product Backlog1.
The Sprint Review
Are we still on track to accomplish the Product Goal?
Answering this question and adapting the Product Backlog in a collaborative effort of the Scrum Team with internal and external stakeholders is the purpose of the Sprint Review.
According to the Scrum Guide, the Sprint Review serves the following purpose:
Evaluate Sprint’s accomplishments: Assess the outcomes achieved during the Sprint and the value delivered to stakeholders in a complex environment.
Reflect on progress towards the Product Goal: Discuss how the outcomes contribute to achieving the Product Goal and explore whether any adaptations are needed.
Plan future adaptations: Identify opportunities for adaptation and learning to enhance the team’s ability to create value and respond to evolving needs.
Consider environmental changes: Understand the impact of any internal or external factors on the team’s value creation and consider these when planning adaptations of the Product Backlog or Product Goal.
Collaboratively decide on next steps: The Scrum Team and stakeholders work together to determine the most appropriate adaptations for the upcoming Sprint based on the insights gathered during the Sprint Review.
Adapt Product Backlog: Update the Product Backlog to reflect new insights, stakeholder feedback, or market changes, ensuring it remains focused on delivering value.
Encourage collaborative discussions: Promote active engagement and open conversations among participants—stakeholders and team members alike—fostering a collaborative atmosphere2.
The Sprint Review is empiricism at work: inspect the Product Increment(s) and adapt the Product Backlog. It is the best moment to create or reaffirm the shared understanding among all participants whether the Product Backlog still reflects the best use of the Scrum Team’s time, thus maximizing the value delivered to customers within the given constraints while contributing to the viability of the organization. It is also because of this context that calling the Sprint Review a “demo” does not match its importance for the effectiveness of the Scrum Team.
The Sprint Review is thus an excellent opportunity to talk about the general progress of the product.
Moreover, the next Sprint can start as the Scrum Team has come full circle.
Now, interestingly, given its importance to make Scrum work as a practice, the Sprint Review is riddled with anti-patterns, from skipping it as the Scrum Team missed the Sprint Goal3 to running an accounting session to boring participants to death with PowerPoint to “demoing” undone work to justify the paycheck or to introducing an approval gate through the backdoor.
Over the coming weeks, I will address many of those anti-patterns and how to counter them in detail. In the meantime, I want to point to two questions I am considering.
Food for Thought
Stakeholders’ ignorance: Is it worth having the Sprint Review when internal and external stakeholders are not attending the event but rely on other means of communication, such as reports? To what extent shall a Scrum Team prioritize convincing stakeholders of the mutual benefits of participating in the Sprint Review? Or could there be an asynchronous Sprint Review format that serves the original purpose outlined in the Sprint Guide?
Forecasting: What effort of the Scrum Team is justifiable to meet the stakeholders’ need for accuracy regarding forecasts? Of course, an “accurate forecast” is an oxymoron; forecasts are inaccurate. However, stakeholders’ requests to better understand the possible availability dates of Increments are legitimate as they need to plan, too. How, then, can we best balance those two conflicting positions: revert to deadline-driven development or continue shrugging shoulders while mentioning that the Increment will be ready when it is ready?
What Sprint Review-related questions are you curious about?
Conclusion
Scrum’s Sprint Review is a critical Scrum event. It answers whether the Scrum Team is still on track to deliver the best possible value to the customers and the organization as envisioned by the current Product Goal. Therefore, avoiding the before-mentioned anti-patterns can significantly improve a Scrum Team’s effectiveness in making your customers’ and users’ lives easier while contributing to a viable organization.
Should your stakeholders be less responsive than your Scrum Team would like them to be, gain their attention and make attending the Sprint Review worth their time. Just avoid (Scrum) dogmatism; if it takes a “Sprint report” sent in advance to stakeholders to get them into the (virtual) room, so be it.
If you have any questions, please let me know.
Best,
Stefan
“Uplifting!” — DIANA LARSEN
“An invaluable treasure.” — JUTTA ECKSTEIN
“I could not recommend it more.” — BOB GALEN
“A cunning companion.” — MAARTEN DALMIJN
“Highly recommended!” — ROMAN PICHLER
“A must-have book.” — JEFF GOTHELF
“Groundbreaking book.”— JORGEN HESSELBERG
Upcoming classes and events:
🖥 💯 🇩🇪 December 13–14 — Live Virtual Class: Professional Scrum Product Owner Training (PSPO I; German)
🖥 💯 🇬🇧 December 18–19 — Live Virtual Class: Advanced Professional Scrum Master Training (PSM II; English)
🖥 💯 🇬🇧 Jan 23–Feb 20, 2024 — Live Virtual Cohort: Product Backlog Management Cohort Class of Jan 23 to Feb 20, 2024 (English)
🖥 🇩🇪 Jan 30-Feb 2 — Live Virtual Class: Professional Scrum Product Owner Training (PSPO I; German)
🖥 🇬🇧 February 6–9 — Live Virtual Class: Advanced Professional Scrum Master Training (PSM II; English)
🖥 🇬🇧 February 15 — Live Virtual Class: Professional Scrum Facilitation Skills Training (PSFS; English)
🖥 🇩🇪 March 5–6 — Live Virtual Class: Professional Scrum Product Owner Training (PSPO I; German)
🖥 🇩🇪 March 12–15 — Live Virtual Class: Professional Scrum Master Training (PSM I; German)
An actionable Product Backlog reflects the continuous effort of the Scrum Team in product discovery in general—developing an informed opinion of which idea may be valuable to the customers—and refining those validated hypotheses into proper Product Backlog items, ready to be taken on in a Sprint. Also, an actionable Product Backlog allows the Scrum Team to run an effective Sprint Planning at a moment’s notice.
Ken Schwaber & Jeff Sutherland: The Scrum Guide — The Definitive Guide to Scrum: The Rules of the Game, 2020
I asked on LinkedIn whether we should run a Sprint Review without stakeholders present. Check out the poll results and comment thread.