Handling Scope Change During a SAFe PI

How do you handle a scope change in a program increment? Specifically when it comes to switching one feature for another? And what’s the impact on PI Objectives and Predictability Score?

A lot of people somehow get the notion that SAFe advocates for “limiting/controlling changes during the PI”. The main source of this notion is that we “Plan the Program Increment” and commit to a set of PI Objectives as part of PI Planning.

But remember one of the key SAFe principles is “Assume Variability- Preserve Options”. This applies within a PI as well. While it makes sense to create a baseline plan for the Program Increment, we should also be prepared for adjustments. After all we want to “Welcome changing requirements, even late in development.”, remembering that “Agile processes harness change for the customer’s competitive advantage. “

So let’s say Product Management is considering a change. They have a Feature that wasn’t in the original Program Backlog or was and there’s something that changed about it. Product Management should use WSJF to consider what to do. The Cost of Delay and Job Size of these suggested changes should be compared to Cost of Delay and (remaining) Job Size of existing PI Scope. And if at this point the WSJF score for the considered change is higher than continuing down the current path then it makes sense to go for the change.

Some people are worried about the Predictability Score — “We would lose points since we won’t tackle some of our planning PI objectives and won’t get credit for them”. Yes some PI objectives won’t be achieved but new objectives should be added or objectives can be changed to align with the changed scope. (Think for example we didn’t manage to hit the “Deploy MS Teams” but we added “Enable all clinicians to provide telehealth meetings using Zoom” as a change made in a PI during the first couple of months of the covid19 pandemic)

Another important question: how do we run a PI in which it is relatively easy to switch some features midway?

We do it by following strong priorities, pulling small batches into the PI, and limiting the number and size of features in progress in early iterations so that lower-priority Features / PI Objectives are kept as options rather than already started.

The goal is to avoid situations where we want to change direction but there’s already sunk cost since we already started the low priority Feature. We don’t take the sunk cost into consideration when prioritizing, but it will mean that continuing down the planned path will win the WSJF more often. Might be easier for the ART but isn’t necessarily maximizing value delivered.

Even more important than the mechanics of the answer is the mindset. If a question like this comes up — go back to the principles. Lean, Agile, SAFe principles will help you think about the situation and what might be the right systemic way to address it.

Connecting OKRs to SAFe portfolio governance is one of the most common integration challenges I help organizations solve. Explore SAFe and OKR advisory or let’s talk.