SAFe Anti-Patterns: The Importance of Sprint Reviews

Scaled Agile anti-patterns and how to avoid them. Why the System Demo does not replace the Sprint/Iteration Review

Tom Boswell
Lean-Agile Mindset
5 min readFeb 16, 2023

--

Photo by Jason Goodman on Unsplash

A common anti-pattern that I have observed at organizations using SAFe is Scrum teams that don’t do Sprint Reviews*. Whilst, this phenomenon is unfortunately hardly unique to SAFe enterprises it can be exacerbated by misunderstanding the purpose and nature of the System Demo (a SAFe event).

In this article, I look at:

  • What is a Sprint Review? What is a System Demo?
  • Why do Scrum teams using SAFe sometimes drop the Sprint Review?
  • What are the key differences between the Sprint Review and the System Demo?
  • What might happen if Scrum teams don’t hold Sprint Reviews?

*Note: Scaled Agile refers to Sprints as Iterations, both are describing fixed-length timeboxes. SAFe also has Iteration Reviews rather than Sprint Reviews. For this article, I’m generalizing both as team-level reviews to inspect the outcome of a Sprint/Iteration and make adjustments.

What is a Sprint Review?

According to the 2020 Scrum Guide, “The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations”.

During this event; the Scrum Team and stakeholders:

  • Review what was accomplished in the Sprint and what has changed in their environment
  • Collaborate on what to do next
  • Adjust the Product Backlog to meet new opportunities (if necessary)

Key characteristics of the event:

  • The Sprint Review is a working session
  • The Scrum team should avoid limiting the Sprint Review to a presentation
  • The Sprint Review is the second to last event of the Sprint (before the Sprint Retrospective)
  • Timeboxed at a maximum of four hours for a one-month sprint (usually shorter for shorter Sprints)

What is a System Demo?

Scaled Agile define the System Demo as “a significant event that provides an integrated view of new Features for the most recent Iteration delivered by all the teams in the Agile Release Train (ART). Each demo gives ART stakeholders an objective measure of progress during a Program Increment (PI).” © Scaled Agile, Inc.

During this event; members of the ART, Business Owners, sponsors, stakeholders, and customers:

  • Briefly review the business context and PI Objectives
  • Describe and demo new features
  • Identify current risks and impediments
  • Have an open discussion including questions and feedback
  • Summarize progress, feedback, and action items

Key characteristics of the event:

  • Demo using a staging environment
  • Minimize preparation and presentation time. Demo screen snapshots and pictures where appropriate
  • Timeboxed to one hour

Note: There is a System Demo at the end of every PI (Program Increment) where the outcome of the entire PI is inspected. There is no similar event in Scrum.

Why do Scrum teams using SAFe sometimes drop the Sprint Review?

Scrum teams working with SAFe tend to drop the Sprint Review because they think the events serve the same purpose and they are often overloaded with meetings, so cancelling the team event seems to make sense.

It is understandable to think the events have the same purpose, as they certainly have similarities:

  • Both events broadly review the outcome of the Sprint/Iteration and focus on making adjustments as a result of this inspection
  • The events share the same cadence (i.e. they occur at the end of the Sprint/Iteration)
  • The events are usually a similar duration (I have found in practice that most Scrum teams doing two-week Sprints reserve one hour for Sprint Reviews)

However, as I outline below, the events actually have very different purposes and audiences.

What are the key differences between Sprint Reviews and System Demos?

Sprint Reviews are team-level events. The attendees are the team and key stakeholders (let’s say roughly a dozen people, eight team members plus four stakeholders). System Demos are ART-level events. The attendees are the entire ART (typically 50–125 people) plus stakeholders etc.

The Sprint Review is four hours (or less) for the Scrum team to inspect what was accomplished in the Sprint and adjust the Product Backlog. The System Demo is one hour for all of the teams on the ART to demo delivered features and discuss progress within the PI. Typically this means each team has about five minutes.

The Sprint Review is a working session for the team to inspect the outcome of the Sprint in detail. While the System Demo is more about providing a high-level overview across the ART.

What happens if Scrum teams don’t hold Sprint Reviews?

When Scrum teams substitute System Demos for Sprint Reviews they are reducing the opportunity for inspection and adaption (they are also not actually doing Scrum).

Some common negative outcomes of dropping the Sprint Review include:

  • Sprint Retrospectives are less effective as the team has a weaker understanding of the outcome of the Sprint
  • Sprint Planning is less effective or more stressful as the Product Backlog has not been adapted in the Sprint Review
  • Teams may have a less empirical, data-driven perspective, as the Sprint Review is often one of the events that teams use to review data

Summary

It’s important to note that Scaled Agile does not suggest that the System Demo should ever replace the Sprint Review (both are clearly visible on the SAFe Big Picture). But, it is interesting to note that this is a common misconception. I find the cause is usually a poor understanding or facilitation of both events.

There is an important clue in the recommended duration of the events. If a team is only spending five minutes to collectively review two weeks of work, then vital insights and learnings will be missed.

  • Sprint Reviews are an event for the Scrum team and a small group of engaged stakeholders to inspect the Sprint outcome in-depth
  • System Demos are an event for the entire ART and stakeholders to gain high-level alignment on delivered features and PI progress
  • Scrum teams in an organization using SAFe should be doing both these team and program (ART) level events as they have different purposes and audiences

Thanks for reading my article 😀

Please connect with me at www.linkedin.com/in/tom-boswell/ if you want to chat about SAFe or Agile.
You can also reach me via www.tomboswell.com

If you want to read more of my articles about SAFe, Agile, and Scrum please follow me on Medium here https://blog.tomboswell.com and/or subscribe to my newsletter.

--

--