Search
Close this search box.
Search
Close this search box.
Search
Close this search box.

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:

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