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

The difference between Planned vs Actual vs Actual Actual Business Value when it comes to SAFe PI Objectives

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

Actual is a relative term when it comes to business value delivered by a SAFe PI Objective. We had a discussion about this a couple of weeks ago in an Implementing SAFe class and I promised a blog post about this. Here it goes.

UPDATE: I’ll be talking about this concept and related Business Agility themes at the SAFe Summit 2019 in San Diego 

Planned Business Value – Making sure Business Owners and the Agile Team are on the same page

Let’s start from the basics though. PI (Program Increment) Objectives are used as a “back briefing” mechanism by Agile Teams on an Agile Release Train to share their plan for the PI and validate that they are indeed focusing on the highest priorities and are planning to deliver objectives that will be valuable for the business.

Business Owners (Business Executive, Product Management, System Architect) circulate between teams during PI Planning and score each PI Objective on a scale of 1..10 based on the business value they ASSUME will be delivered in case this PI Objective is accomplished in the PI.

This becomes the “Planned Business Value (BV)” for that objective.

Actual Business Value – Assessing Business Value based on a Demo of a real solution

Later on, during PI Inspect & Adapt (or earlier during System Demos) the same Business Owners circulate between the teams and score each of these PI Objectives again, this time on “Actual Business Value (BV)”.

What does Actual mean here? Well, in most cases the evaluation is based on seeing a demo of a working solution and still making ASSUMPTIONS about what the actual value would be when the solution meeting this objective will be released and available to real users/customers.

Sorry, but while being much closer, that’s still not ACTUAL business value.

ACTUAL Actual Business Value – Based on released solutions and the outcomes they deliver in the real world

ACTUAL business value delivered can be evaluated only AFTER the solution is released.

On most Agile Release Trains / SAFe contexts the PI I&A is too early to make this evaluation so you could understand why we’re still making assumptions at that stage.

But if we really care about outcomes and delivering value, we shouldn’t close the books on these PI Objectives and the PI at that point. We should get back to it later on and Inspect and Adapt based on real business value delivered.

Adjusting the SAFe Inspect & Adapt to track ACTUAL actual Business Value

If you’re with me, you’re probably asking what can we do about this. What is the right timing to get back and assess the ACTUAL actual Business Value? From a cadence perspective, there are two main ways to do this.

The simplest is to take advantage of the Inspect and Adapt PI System Demo to review the ACTUAL business value delivered by the objectives in the PREVIOUS Program Increment. E.g. if we’re now finishing PI 5, we’re assessing actual business value delivered by the objectives in PI 5 that will be released sometime during PI 6, as well as PI 4 objectives that hopefully got released during PI 5.

More to read:

How do we handle Scope Changes in a SAFe Program Increment?

Could the INVEST criteria Bill Wake came up with for evaluating User Stories help us come up with effective PI Objectives in SAFe as well?

SAFe includes Scrum – so how come many Scrum practitioners and thought leaders consider it unsafe?

AgileSparks Services

Achieving Business Agility By Implementing Agile at the Organizational level

For each one of these PI 4 objectives, now should be a reasonable time to talk about things like – Have customers started to use this solution? Are they happy with it? Did it achieve the impact we had in mind for it? Did we stop incurring the cost of delay we had in mind when prioritizing this? At this point, the 1..10 scores should be data/evidence-driven.

If we AREN’T able to evaluate the actual business value at this point – that means there’s a short-circuit in our empiric feedback loop that we should work on fixing.

If we haven’t released the solution yet, then we should keep the actual score for this objective empty and get back to it in the next PI. This objective should still be a “work in progress” from our perspective.

It’s not DONE until we evaluated the ACTUAL Business Value

You might guess what’s the next aspect of this. Mentioning Work in Progress should be an obvious clue. The Program Kanban has a role in helping us out here as well. Features on the Program-level Kanban shouldn’t be considered DONE until we collected this feedback and evaluated the ACTUAL actual business value on them. They should hang out on the board – may be in an area called “Feedback” or whatever you prefer.

I’ve been recommending this sort of Program-level Kanban Board structure for a long time now. Some of my enterprise-level clients have improved their Product Management practices dramatically through the accountability and follow-through that this practice encourages.

Just think about the impact on Product Management, Business Owners, and Salespeople asking for features, if they know they are accountable for the outcomes from these features after they’re released.

Who’s accountable for delivering the actual business value?

This brings us to an interesting question. Who’s accountable for delivering actual business value? Who’s accountable for delivering ACTUAL actual business value? Is it the Agile Team? Product Management? Business? Sales?

I’ve seen way too many teams frustrated when they deliver the objectives according to what they presented as the plan, and yet the actual business value score is lower than the plan because the Business Owners don’t think as much value will be actually delivered. When we’re moving from assumed actual to actual actual the gap can be even bigger. On one hand, in the spirit of transparency and being focused on value and outcomes rather than output, this is the right way to score the business value. It’s about value delivery rather than tracking to plans. On the other hand, you can probably understand the frustration here.

The way I see it, the only way out of this is to understand that the PI Objective plan vs actual vs ACTUAL isn’t an indication of the individual performance of either one of these roles. It’s an indication of the performance of the whole development value stream including the upstream activities related to choosing and prioritizing features and the downstream activities related to selling the solution, convincing users/customers to use it,  implementing it in the field, and operating/supporting it.

That, together with Lean/Agile Leadership that emphasizes principles such as Assuming Variability, Objective evaluation of working delivered systems, and relentless improvement of the whole value delivery cycle, is the key to focusing on learning from these surprises whether they are systemic or repeating or rare exceptions.

A relentlessly improving organization would inspect what’s the trend when it comes to plan vs actual vs actual actual for the whole program and per specific PI Objectives and try to see what it can learn from when the value gap happens and does it happen for a specific type of objectives or in a specific area of the program/business.

It’s all about Value

Value is the goal of Lean and the fast delivery of value is the goal of SAFe. If we’re serious about that, We should raise our game when it comes to managing value as a first-class citizens in SAFe. Business value on PI objectives is the perfect place for doing exactly that.

So, Next time you have PI Inspect & Adapt, don’t just look at the PI you’re finishing just now, take a look at the objectives from the previous PI as well. And on your Program-level Kanban only consider features done after evaluating actual business value delivered, ideally based on quantifiable metrics.

I love it when discussions in class drive me to write up some of my experiences, tips, and tricks for the blog. Awesome kudos to my students, now SPCs off to implement a healthy and value-oriented SAFe in their organizations!

Subscribe for Email Updates:

Categories:

Tags:

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