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:

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