So what is Scrum’s Outer Loop? Well, Scrum is a series of engineering delivery activities to efficiently deliver software. Scrum’s Outer Loop is a complementary series of product management activities to efficiently and periodically scrutinize the product backlog, and update it as needed. Why does the product backlog need to be scrutinized periodically (and perhaps overhauled)? Because the value assumptions built into your Scrum team’s current product backlog change more significantly over time than the incrementalism of Scrum can handle. Consider the likelihood that any one of the following occurs over the course of, (let’s say) 2 to 4 months: significant market change, competitor move, significant technological change, new business opportunity, disruptive user feedback or a disruptive idea from within the team. The biggest Achilles heel of Scrum is not seeing changes in the forest because we’re focusing on one or two trees at a time.
Figure 2. SAFe 6.0 “Essential” – this is the simplified version, which is overly complex for any but the largest organizations, in the author’s opinion (source: https://scaledagileframework.com/#)
Periodic Backlog Overhaul is Needed to Avoid Scrum-Fall
One of the primary benefits of Scrum (vs. waterfall) is that valuable software is released in smaller increments, more often, to deliver value to the market quicker. When everything works as planned, the most important items are delivered first, and value is added incrementally along the way. When compared to waterfall, value is front-loaded, and the value-over-time curve is depicted in Figure 3. Scrum vs. Waterfall, value over time.
Figure 3. Scrum vs. Waterfall, value over time
What happens all too often is that the team does not adequately step back and evaluate the market feedback after software release. This leads to “Scrum-fall” (see Figure 4. Scrum-fall), where the team releases (presumably) valuable software, but does not explicitly re-evaluate the core value assumptions from the beginning of the project. So the team misses the feedback loop.
Figure 4. Scrum-fall is when value is delivered often, but the drivers of value (including market feedback) are not re-evaluated on a regular basis
In the ideal case, Scrum enables the team to capture the 80% value from the most important 20% of delivered software – solving the most important problems first, with the minimum viable software increment (MVI, if the world needs another “MVx”). It then moves on to solving the next most important problem, rather than keep solving the first problem. It is typically depicted as shown in Figure 5. Optimal value-capture with Scrum.
Figure 5: Optimal value-capture with Scrum (vs. waterfall), where the drivers of value are re-evaluated and the product backlog is overhauled accordingly