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:

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