Handling scope change during a SAFe Program Increment (PI)

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

How do we handle Scope Changes in a SAFe Program Increment?

A question about handling scope changes in SAFe was posed recently on a forum I’m participating in (The SAFe Community Forum). This is a question posed regularly in training and on ARTs I’m coaching so I thought I’d provide my thoughts here.

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

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 is how do we run a PI in which it is relatively easy to switch some features midway?

We do it by following strong priorities and small batches going into the PI and limiting the number and size of features in progress in early iterations so 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 the 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, and SAFe principles will help you think about the situation and what might be the right systemic way to address it.

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 the Cost of Delay and (remaining) Job Size of the 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 is how do we run a PI in which it is relatively easy to switch some features midway?

We do it by following strong priorities and small batches going into the PI and limiting the number and size of features in progress in early iterations so 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 the 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, and SAFe principles will help you think about the situation and what might be the right systemic way to address it.

Subscribe for Email Updates:

Categories:

Tags:

Daily Scrum
Agile Techniques
PI Objectives
SAFe Release Planning
BDD
Operational Value Stream
Coaching Agile Teams
Agile Outsourcing
Agile Development
Development Value Streams
Legacy Enterprise
Scrum Master Role
ATDD
Software Development Estimation
Scrum With Kanban
Product Management
Agile Product Development
Effective Agile Retrospectives
SA
Lean Agile
Limiting Work in Progress
Atlassian
speed @ scale
Story Slicing
RSA
SAFe
Scrum
Professional Scrum Master
Planning
Agile Delivery
Agile Testing Practices
Agile Assembly Architecture
Kanban Basics
Lean Budgeting
Nexus and SAFe
Agile
Kanban Kickstart Example
agileisrael
Lean Agile Basics
SAFe DevOps
Introduction to Test Driven Development
Professional Scrum with Kanban
TDD
Atlaassian
Engineering Practices
Scrum Primer
AI Artificial Intelligence
Legacy Code
Certification
Agile Israel
Scrum.org
Agile Community
Lean Risk Management
Lean-Agile Software Development
Advanced Roadmaps
Lean Agile Leadership
Games and Exercises
Nexus
Reading List
Scrum Values
Spotify
Certified SAFe
An Appreciative Retrospective
Kanban
Agile Risk Management
Frameworks
ART Success
Agile Mindset
Hybrid Work
Manage Budget Creation
Jira Plans
LAB
Lean Startup
Nexus vs SAFe
Systems Thinking
Professional Scrum Product Owner
predictability
speed at scale
Lean and Agile Principles and Practices
GanttBan
lean agile change management
LPM
Change Management
System Integration Environments
Risk-aware Product Development
WIP
Jira
Scrum and XP
Accelerate Value Delivery At Scale
Risk Management on Agile Projects
Test Driven Development
Agile Release Management
Covid19
LeSS
Presentation
Lean Agile Organization
Agile Project Management
Continuous Planning
ScrumMaster Tales
Kanban Game
Lean-Agile Budgeting
Agile Release Planning
Managing Risk on Agile Projects
Program Increment
What Is Kanban
Value Streams
Process Improvement
Continuous Deployment
ATDD vs. BDD
The Kanban Method
Agile Product Ownership
AgileSparks
Video
Lean and Agile Techniques
System Archetypes
Enterprise DevOps
ROI
RTE
Kanban 101
ALM Tools
Perfection Game
Continuous Delivery
QA
IT Operations
Agile India
Managing Projects
Kaizen Workshop
Release Train Engineer
AI
The Agile Coach
PI Planning
Business Agility
Implementation of Lean and Agile
SPC
Scrum Guide
Scaled Agile Framework
Quality Assurance
Risk Management in Kanban
POPM
Agile Marketing
Applying Agile Methodology
Continuous Integration
Nexus Integration Team
Large Scale Scrum
Slides
Acceptance Test-Driven Development
Pomodoro Technique
Scrum Master
DevOps
Agile Games
Implementing SAFe
Agile Games and Exercises
Agile for Embedded Systems
Tips
Lean Software Development
Built-In Quality
A Kanban System for Software Engineering
Agile Contracts Best Practices
Lean Agile Management
Elastic Leadership
Releases Using Lean
NIT
Self-organization
Product Ownership
Iterative Incremental Development
Tools
Agile Exercises
Portfolio for Jira
Continuous Improvement
EOS®
Software Development
ARTs
Sprint Planning
Jira admin
Agility
Kaizen
Sprint Iteration
Rapid RTC
Agile and DevOps Journey
Entrepreneurial Operating System®
Agile in the Enterprise
Code
Agile Program
Amdocs
Sprint Retrospectives
Artificial Intelligence
System Team
Nexus and Kanban
Webinar
Agile Basics
Agile Israel Events
Jira Cloud
RTE Role
Agile Project
Principles of Lean-Agile Leadership
Introduction to ATDD
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart