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).