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:

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