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.

Categories:

Tags:

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

AgileSparks Newsletter

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

academy@agilesparks.com

WELCOME

to our new website

WELCOME

to our new website

This website uses Cookies to provide a better experience
Shopping cart