(Part 2) Implementing Scrum’s Outer Loop™. How to Wring the Most Value Out of Your Scrum Teams

In Part 1, Scrum’s Outer Loop: Solving the Product Management Gap Between Scrum.org and SAFe, I introduced the product management framework “Scrum’s Outer Loop™ for Periodic Pivot Assessment of the Backlog. ” The post articulated the primary audience (mid-sized firms) and the problem it solved (avoiding diminishing returns by looking at the forest, not just the trees).  I proposed that Scrum’s Outer Loop (SOL) fills an important product management gap between Scrum.org (which has no defined framework for integrating product management activities into sprints), and SAFe’s (whose framework is, IMO, overly heavyweight for all but the largest firms). 

About the Authors

John Miniati, the Director of Product Management at Forte Group	Olindo Alo, Senior Product Owner at Forte Group.

In this blog post, we begin to outline how Scrum’s Outer Loop framework works.  Today’s installment considers how to wring the most out of your Scrum teams, by incorporating the various inputs needed to answer the question, “Can we deliver more value?”.  We introduce the “Discovery Huddle-Up”, discuss when to initiate a sprint that includes Discovery, and outline the topics we plan to include in this series. I’ve invited one of Forte’s Sr. Product Owners, Olindo Alo, to join me in writing this series, as we are using this process together with a number of clients. 

Scrum’s Outer Loop is a process in which the Extended Product Development team organizes, evaluates and coordinates empirical evidence, in preparation to introduce evidence during a handful of collaborative work sessions (we call them “Discovery Huddle-Ups”) that occur during a single sprint.  It is up to you to define who is part of your Extended Product Development Team.

The macro view of SOL is pictured in Figure 1. This view shows that various inputs are gathered throughout the outer loop planning period (say, three months). These inputs include User Feedback (UX research, via support calls, indirectly from client services and sales proxies), Value Metrics (via product analytics and other empirical methods), ideas from within the team (the Scrum team and/or the broader product/ architecture team), tech changes/ tech debt, new business opportunities, and responses to market changes (such as competitive moves).   

Introducing “Discovery Huddle-Ups” 

Discovery “huddle-ups” are work sessions within a single sprint where external outputs from Product Management, Architecture, UX Research, and other sources are explicitly introduced as inputs into the Scrum process.  

SOL complements Scrum.org as  a lightweight mechanism to periodically  introduce discovery and planning activities into scrum, during a targeted sprint. We do not recommend having an entire team spending an entire sprint on discovery and planning. Rather, our approach is to introduce a handful of collaborative workshops that enable the team to take a brief step back from the trees to look at the forest and ask: “are we delivering optimal business value?”  

We propose that the risk of diminishing returns from Scrum’s incrementalism increases over time. This is because Scrum takes an engineering-delivery approach, where every sprint is focused on velocity – or an engineering-centric spike. Our observation is that Scrum (alone) leaves minimal opportunity for significant product pivots to a new minimum viable increment (MVI), because it was designed for “continuous incrementalism”.  Scrum.org focuses on each team’s output and doesn’t have guidelines for scaling.  

In contrast, SAFe, in practice, tends to take ownership away from the product owner and the Scrum team, because it typically leads to a more “top-down” approach (compared to Scrum.org).  We submit that the SAFe approach may create a disconnect between strategy and execution.  SAFe, on the other hand, is a well-defined framework to, well, scale agile with a lot of emphasis on the agile release train (ART).  

The difference between SOL and SAFe is that SOL maintains true product ownership and decision-making authority within the Scrum team while also incorporating synchronous and asynchronous inputs from business, UX research, architects and other stakeholders. In future blog posts we will articulate how SOL can be part of a scaled agile framework that is more structured than Scrum.org yet more lightweight and flexible than SAFe. 

During a sprint with Discovery, an extended Product Planning Team pressure tests and refines the inputs mentioned above.  So, rather than a Product Manager (for example) pushing down “a new roadmap”, a Product Owner evaluates information provided by a Product Manager (and/or other key stakeholders such as a UX Researcher, an Architect, Client Services, etc), and together they hash out a new set of Product Delivery Artifacts.

The Discovery Huddle-Up work session  is the beating heart of Scrum’s Outer Loop and is a topic that we will expand upon in this “How to SOL” series.  

A Sprint with Lightweight Discovery and Planning

We do not advocate dedicating an entire sprint’s capacity to Discovery and Planning. Rather, we propose a handful of cross-functional workshops (Discovery Huddle-Ups) that take accumulated external outputs (from Product Management, Architecture, UX Research, and other sources) as inputs into the Scrum process. Typically, the Discovery sprint will replace a delivery sprint (in whole or in part), so as not to disrupt the existing Scrum cadence.   

Figure 1. Macro view of Scrum’s Outer Loop, where each outer loop defines a periodic planning cycle (for example, every three months)

The macro view of SOL (Figure 1) is a useful visual to show that SOL is an iterative process that “wraps” Scrum and ultimately results in a “major revision” of the product backlog. This view also illustrates the activities involved. This macro view is lacking in two areas: 1) it doesn’t show the Discovery Sprint, and 2) it shows the activities happening sequentially. Rather than try to jam everything into Figure 1, it’s easier to look at a micro view, where the existing Delivery Artifacts, plus the outputs from SOL are the inputs for the Discovery Sprint. See Figure 2. 

Figure 2. A sprint with Discovery – a micro view of Scrum’s Outer Loop, where the various outputs from “outer loop activities,” plus the existing Delivery artifacts are inputs for the Discovery Huddle-Up sessions, whose output is a set of updated Product Development artifacts.

When to initiate a Sprint with Discovery Huddle-Ups  

Ultimately, the answer is “when the current plan is no longer optimal.” SOL is the process that helps a product team monitor for value inflection points and efficiently adjust the delivery plan toward a new minimum viable increment (MVI).  

A value inflection point is when a pivot is needed – the current path is no longer optimal for delivering value. Remember that we define value unambiguously as “solving a critical problem for target users to achieve well-defined business goals (desired outcomes), as measured by specific success metrics.” This Value case study shows how we accelerated time-to-value working with a Financial GenAI client of ours.

But how does a product team know when a pivot may be needed?  There are three approaches: 

1. Periodic discovery: Any defined planning cadence, typically between two and four months. From an organization logistics perspective, this is the most expedient approach.
2. Event-driven: Event-driven Discoveries that are planned such as “after we get significant (specific) user feedback from the MVI we just launched,” “after launch of our current MVI,” or “after we have solved the widget-spark plug interference problem.”
3. Reactive: Discovery sprints are unplanned events that may cause a pivot, including a brilliant idea that needs to be acted upon, unexpected competitive moves, technology changes or other major unexpected events.

Importantly, a print with Discovery is at an inflection point. This is entirely complimentary to the continuous Discovery – the incremental Discovery – that is inherent to Scrum and addressed in refinements to the backlog. We whole-heartedly support Scrum.org. [We just think that it’s incomplete.] 

Scrum’s Outer Loop is explicitly designed to be flexible in numerous ways. One, as demonstrated above, is the timing of a Discovery Sprint. We will point out other dimensions of SOL’s flexibility as we progress in this “How-to SOL” series. 

Product Development Artifacts

The Product Development artifacts are a set of items that collectively are used by the Delivery Team to, well, develop valuable, high-quality software increments.  These Product Development Artifacts typically include: 

• The User Problem: Target Persona(s), key problems and high-value use cases
• Product Goals: The Desired Business Impacts (outcomes), with success metrics and assumptions (hypotheses) 
• Product Vision: (we like to use the Future Press Release framework, but many others exist)

– With product vision articulated for each MVI
– Acceptance Criteria for Business Goals (Definition of Done) for each MVI

• Goal-Oriented Roadmap: a prioritized set of minimum viable software increments (MVI’s)
• Product Backlog: Ideally as a Story Map that has 2-way sync with the team’s development tool (ex: Jira or Azure DevOps)
• Technical Artifacts: Architectural Artifacts and engineering documentation as needed
• Design & Product Artifacts: Clickable models, wireframes, components, style guide 
• Supporting Reference Material that provides design context, as needed:
  Business case, UX Research results, work flows, customer requests, architectural decisions made, etc. 

Topics in upcoming SOL’s “how to implement” series 

Future installments of our “How to Implement Scrum’s Outer Loop” series of blogs will include the topics listed below.  These are subject to change: 

• Roles and responsibilities in Scrum’s Outer Loop
• The beating heart of SOL: The Discovery and Planning Sprint
• Complementing Scrum: Leap-frog vs. incremental value
• Empiricism and product analytics; 
• Integrating Lean UX and Design Thinking into SOL; 
• SOL and SAFe; 
• SOL and Scrum.org; and 
• In the end we hope to pull everything together in a White paper: Scrum’s Outer Loop.

In closing

Today we introduced The Discovery Sprint as the means by which a product team can pivot toward a new Minimum Viable Increment (MVI) based on one of three triggers, and outlined the topics ahead in our journey to share “How to SOL”.

1. A planned event such as an MVI launch
2. A defined planning heartbeat such as every three months
3. A reaction to a significant event such as a brilliant idea). 

We welcome and encourage your comments, questions and suggestions!

Join our Steering Committee to help us define and refine Scrum’s Outer Loop!

We are looking for experienced Product, Scrum, UX and Engineering practitioners to be sounding boards for this “How-to Implement Scum’s Outer Loop” series.