SAFe Coaches Handbook - Packt

SAFe® Coaches Handbook
Copyright © 2023 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval
system, or transmitted in any form or by any means, without the prior written
permission of the publisher, except in the case of brief quotations embedded in
critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of
the information presented. However, the information contained in this book is sold
without warranty, either express or implied. Neither the author(s), nor Packt
Publishing or its dealers and distributors, will be held liable for any damages caused
or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the
companies and products mentioned in this book by the appropriate use of capitals.
However, Packt Publishing cannot guarantee the accuracy of this information.
Group Product Manager: Alok Dhuri
Publishing Product Manager: Uzma Sheerin
Senior Editor: Nisha Cleetus
Content Development Editor: Rosal Colaco
Technical Editor: Jubit Pincy
Copy Editor: Safis Editing
Project Coordinator: Manisha Singh
Proofreader: Safis Editing
Indexer: Sejal Dsilva
Production Designer: Nilesh Mohite
Business Development Executive: Puneet Kaur
Developer Relations Marketing Executives: Deepak Kumar and Mayank Singh
First published: June 2019

Production reference: 1300623
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham
B3 2PB, UK.
ISBN 978-1-83921-045-7
www.packtpub.com
This book is dedicated to Liz, for your unwavering support, endless love, and
remarkable ability to make me laugh, even on the toughest of days. Your
constant encouragement and belief in me have been the driving force behind
my successes. You give me the strength to push through the most challenging
times and to never give up on my dreams. And, oh, your sense of humor! Your
infectious laughter and witty quips always manage to brighten up my day and
bring a smile to my face. You are my rock, my confidant, and my soulmate. I
am so grateful for every moment we share, and I cannot imagine going
through life without you by my side. So, with all my heart, I dedicate this book
to you, Liz. Thank you for being my everything.
- Lindy Quick
To my wife, Joanne, who has constantly supported me on my career journey
and been my loving partner throughout our joint life journey. And to our
children, Alex and Tamsin, who make us proud every day.
- Darren Wilmshurst
Contributors
About the authors

Darren Wilmshurst is the UK director of Cprime, a leading global Agile, product,
and technology solutions provider, delivering transformations. Having spent almost
30 years in the corporate world, first in retail banking and then later in the IT
industry, he moved to consulting to help organizations in both the private and public
sectors to be more effective and efficient. He is a SAFe® Practice Consultant
Trainer (SPCT) and is also recognized as a SAFe® Fellow. He co-authored the BCS
book Agile Foundations – Principles Practices and Frameworks, was a contributor
and reviewer of The ART of Avoiding a Train Wreck, and was a reviewer of Valuing
Agile: The Financial Management of Agile Projects.
Lindy Quick is the owner and principal at LNQ Consultants. She has more than 15
years of federal government IT experience and 10 years of SAFe® and Lean-Agile
consulting and Coaching experience. Lindy has Coached and trained numerous
individuals, teams, ARTs, and solutions, delivering both software and highly
complex cyber-physical solutions. Lindy is a SAFe® Practice Consultant Trainer
(SPCT) and holds a Bachelor of Science in Computer Science and German and a
Master of Business Administration (MBA).
About the reviewers

Alex Gray is a professional, versatile, fun, and enthusiastic Certified Scrum
Trainer®, Path to CSP Educator®, LeSS Friendly Scrum Trainer, ICAgile
Authorised Trainer, and leader of Lean/Agile practices. He has been delivering
CSM® training since 2016 and uses his 25+ years of experience working in
technology teams and 15+ years of experience working in agile transformations to
the class’s benefit.
Alex has experience working in banking and financial services, medical, gaming,
telecoms, and other industries. His work involves training and guiding
organizations on aspects of Lean Agile transformations, from team-level agility and
scaled agility through to business-wide agility and agile leadership.
Glenn Smith is a respected business agility consultant and Scaled Agile

Framework (SAFe) SPCT. He works internationally, blending his consultation,
Coaching, facilitation, and training skills to empower his clients. Described by
clients as having the superpower to make the complex seem simple, he supports
organizations in improving their bottom line in delivering and operating their
products and services.
Patrick Campbell is a veteran of 20+ years of Project and Program leadership and
management, as a Program Manager as well as a practice director while working at
Digital Equipment, Compaq, and Hewlett Packard. Since 2006, Pat has been
practicing, implementing, teaching, and Coaching in agile and lean principles and
frameworks, and has helped multiple Fortune 500 companies discover their
benefits. Originally certified by Ken Schwaber, one of the creators of Scrum, Pat
brings a combination of background and experience to facilitate teams in the
discovery of delivering Business Value. Pat holds a PMP (’99) and ACP (’14)
certification from PMI, and is a certified ScrumMaster, a certified Product Owner,
and a certified SAFe® Program Consultant.
Tim Jackson is an experienced SAFe® Practice Consultant Trainer (SPCT) with

over 20 years of experience in digital. He began his career as a full-stack developer
building intranets before discovering his passion for product management. Tim
worked in various agencies around London before becoming a director in a
pharmaceutical company where he began exploring the world of SAFe. He then led
the transformation at a large airline, where he found his true calling as a
transformation architect using SAFe.
Tim is a respected expert in his field, and his contributions to the industry have
been significant. His expertise has been instrumental in the success of many
organizations, and his passion for SAFe® has helped him to achieve great things
throughout his career.
Table of Contents
Preface
Thriving in the Digital Age

The five Technological Revolutions
Casualties of the digital age
The Dual Operating System
Core Competencies of Business Agility
Team and Technical Agility (TTA)
Agile Product Delivery (APD)
Enterprise Solution Delivery (ESD)
Lean Portfolio Management (LPM)
Organizational Agility (OA)
Continuous Learning Culture (CLC)
Lean-Agile Leadership (LAL)
Values and principles
Lean
Agile
SAFe® Core Values
SAFe® Lean-Agile Principles
Summary
Further reading
Part 1: Agile Teams
Building the Team

What is an Agile Team?
Agile Team Roles and Responsibilities
Product Owner
Scrum Master/Team Coach
Team Responsibilities
Team Types
System Team
Shared Services
Summary
Further reading
Agile Team Iteration and PI Execution

Day-To-Day within an Iteration
Iteration Events and the Product Owner
Iteration Events and the Scrum Master/Team Coach
Iteration Activities and the Agile Team
Day-To-Day within a PI
PI Events and the Product Owner
PI Events and the Scrum Master/Team Coach
PI Events and the Agile Team
Summary
Further reading
4
Team Backlog Management
The Team Backlog
What is a User Story?
Types of Stories
Why do we have different types of Stories?
Estimating User Stories
Story Splitting
User Story Prioritization
Getting your Team Backlog to Flow
Kanban Team Stories
Team Backlog preparation for PI Planning
Summary
Further reading
Team Iteration Events

SAFe® Scrum Team Events
Iteration Planning
Team Sync
Backlog Refinement
Iteration Review
Iteration Retrospective
Iteration System Demos
SAFe® Kanban Team Events
Planning
Team Sync
Retrospective
Team artifacts
Definition of Done
Definition of Ready
Working Agreements
Summary
Further reading
Part 2: Agile Release Trains
Building the Agile Release Train

Why your Train isn’t your department
How should we build our ART?
How identifying the Correct Value Stream impacts
the ART
How should we identify our Value Streams and what
happens if we don’t?
Release Train Engineers, Product Management, and
the System Architect – Senior Leaders
The Troika
The Release Train Engineer (RTE)
Responsibilities of a Release Train Engineer
Product Management
System Architect
Do we need a System Team?
What is a System Team?
Summary
Further reading
Release Trains Day-to-Day

Synchronization and Cadence
The Continuous Delivery Pipeline
What is the CDP?
Who is responsible for the CDP?
Why do we need a CDP?
Integrate Often and Early
Tooling
Day-to-Day – Product Management
ART Events and Product Management
Product Management and ART Backlog Refinement
Product Management and Preparing for PI Planning
Ongoing Activities for Product Management
Day-to-Day – System Architect
ART Events and the System Architect
Ongoing Activities for the System Architect
Day-to-Day – the Release Train Engineer
Keeping the Train (ART) on the Tracks
Facilitating the Events
General Responsibilities of the RTE
The RTE and Agile Tools
The RTE and preparing for PI Planning and I&A
Get Help!
The Innovation and Planning Iteration
IP Iteration Schedule
Measure and Grow Assessments
Responsibilities in the IP Iteration
We don’t need an IP Iteration
Summary
Further reading
ART Backlog Management

The ART Backlog
What is a Feature anyway?
Enablers
Capacity Allocation
Feature Sizing
What about Points?
Feature splitting and combining
Feature prioritization
Why WSJF?
Applying WSJF
Backlog preparation for PI Planning
Summary
Further reading
Events for the Train

The syncs
Coach Sync
PO Sync
ART Sync
The Technical Sync
The Troika Sync
Release Management Sync
Scheduling the syncs
Bonus sync recommendations
Don’t skip the ART Board
What is the ART Board?
Iteration System Demo
How to execute an Iteration System Demo
Considerations for the Iteration System Demo
Summary
Further reading
10
PI Events
PI Planning
The RTE and PI Planning
Preparing for PI Planning
Executing PI Planning
Day 1 kick-off
Presentations
PI Objective tips and tricks
Team breakouts
Draft Plan Reviews
Management Review and Problem-Solving
Day 2
Remote/Distributed PI Planning
The I&A Event
The PI System Demo
Quantitative and Qualitative Measurement
The Retrospective and Problem-Solving Workshop
Summary
Further reading
Part 3: Portfolio
11
Enterprise Strategy
What is Enterprise Strategy?
Strategy Agility
How is Enterprise Strategy different from Portfolios?
Summary
Further reading
12
Building Your Portfolio

Starting with education for the Leaders
Painting your Portfolio with color
Value Stream Identification (VSI)
Pre-work and preparation
Step 1 – Identifying the OVS
Step 2 – Identifying the solutions the OVS use or
provide to customers
Step 3 – Identify the people who develop and
support the solutions
Step 4 – Identify the DVS that build the solutions
Step 5 – Realize DVS into ARTs
Summary
Further reading
13
Establishing Lean Budgets

Seeing the horizons
We fund Value Streams, not Projects
Story from the real world
Participatory Budgeting
Summary
Further reading
14
Portfolio Backlog Management

Portfolio Epics
The Portfolio Kanban
The Funnel
Reviewing
Analyzing
The Portfolio Backlog
Implementing
Done
Lean Portfolio Management events and governance
The Portfolio Sync
The Strategic Portfolio Review
Participatory Budgeting (PB)
Summary
Further reading
15
Measuring Progress
Leading and Lagging Indicators
Domain 1 – team health
Domain 2 – quality
Domain 3 – productivity
Domain 4 – predictability
Summary
Further reading
16
Leadership Alignment
Moving from a fixed mindset to a growth mindset
Leading by example
Insatiable learning
Authenticity
Emotional Intelligence
Courage
Growing others
Decentralized decision-making
Leading an Agile organization
Step 2 – creating a powerful guiding coalition
Other important steps to implement organizational
change
Steps 3 and 4 – developing and communicating the
vision and strategy
Step 6 – generating short-term wins
Step 7 – consolidating gains and producing more
wins
Step 8 – anchoring new approaches in the culture
A Continuous Learning Culture (CLC)
Summary
Further reading
17
Embracing Agility and Nurturing

Transformation
Appendix A
Appendix B
Glossary
Index
Other Books You May Enjoy

Preface
We often meet organizations and the conversation starts along these lines:
Organization: “We want to go Agile.”
Us: “Great!”
Organization: “And we want to adopt SAFe®.”
Us: “Even better because we are pretty good at SAFe®. But first, can we ask why
you are doing so?”
Organization: (long pause) “Because other big organizations are doing it!”
Generally, that is not a good reason to undertake a significant change within your
organization. The goal is not to be Agile or SAFe® but to make your organization
more effective using lean Agile and to utilize a supporting scaling framework such
as SAFe® to support that goal.
We see a lot of ill-informed commentary on various social media platforms about

SAFe®, including a video that was described as a “candid and unscripted
conversation about SAFe®” with two people that declared that they had no
experience of SAFe® and all their thoughts were based on anecdotal evidence. As a
consequence, it was littered with misinformation.
So, let’s start here.
SAFe® is not a prescription or a rule book, it is a Framework!
A standard definition of a Framework is as follows: “A framework is a supporting

structure around which something can be built.”
Every time we have implemented SAFe® in an organization, we have implemented

it differently because each organization is different and the appetite for change and
disruption varies significantly.
You can not implement SAFe® in an algorithmic way; you need to implement it in
a heuristic way. That is, you have to implement it with your brain switched on! You
cannot just follow a book.
That said, there are certain foundations that need to be in place; if you bake a cake,
then there are certain ingredients that you must use, while fillings and decoration
can certainly vary.
SAFe® is like a wonderful toolbox but you have to know what tools to use in the
right circumstances. If I am putting a picture on a wall, I will use a hammer and a
nail; I don’t need a chainsaw! And a chainsaw in the wrong hands can be very
dangerous.
SAFe® for Lean Enterprises is a knowledge base of proven, integrated principles,
practices, and competencies for achieving business agility using Lean, Agile, and
DevOps. (© Scaled Agile, Inc.)
Let’s break that down! It is not based on some folks sitting in Colorado and coming
up with ideas; the 10 versions since 2011 have all been built on feedback from
practitioners (like the authors) and from organizations that have implemented
SAFe®.
Moreover, it is underpinned by some genuine thought leadership from Deming,

Reinersten, Kotter, Moore, Ward, and many more.
Now that we have got that off our chest, who is this book for?
Who this book is for
This book is not a reference guide it is a handbook. A reference guide would be far
too long but critically you have the Framework site, which is the most
comprehensive knowledge base of all things SAFe®.
We have aimed this book at those newly qualified SAFe® Practice Consultants
(SPCs) who have maybe just completed and passed the 4-day Implementing
SAFe® class.
Certified SPCs are change agents who combine their technical knowledge of
SAFe® with an intrinsic motivation to improve the company’s software and
systems development processes. They play a critical role in successfully
implementing SAFe®.
As we all know, there is a world of difference between attending a class and passing
an exam to actually implementing SAFe® in an organization.
One of our colleagues used to say “Would I get on a plane with a pilot that has just
read a book and passed an exam?” For those that drive, there is a world of
difference between passing your theory test and actually learning to drive. And who
remembers that first solo drive?
However, this book is not just for newly qualified SPCs. Are you an SPC trying to
get SAFe® to work in your organization? Are you a Scrum Master/Team Coach or
Release Train Engineer wondering why SAFe® is hard? Are you a Product Owner
or Product Management and need to help your teams deliver? Are you an Architect
and wondering what your role is? Are you a team member and just want to know
why you are doing these crazy ceremonies? This is also the book for you.
Whether you are new to SAFe®, or you’ve struggled with how to make it work in
the real world, this book is for you. It is also helpful for new Agile Coaches, or
teams without the benefit of an experienced Agile Coach.
Are there any prerequisites?

You should have some experience with SAFe®. We’re not going to cover the
basics; we’re going to explain why SAFe® says to do it a certain way. If you’ve
been through a Scaled Agile Framework® class, or have equivalent experience with
working in a SAFe® environment, but still have questions about how to
successfully put the concepts into practice or why they are the way they are, then
this is the book for you. It’s also useful when you begin to adapt and adjust SAFe®
to your particular work environment, and you aren’t sure what you can safely
change and what needs to be done “by the book.”
What this book covers
The book has been divided into three sections:
Part 1 focuses on the Team level
Part 2 focuses on coordination at the ART level
Part 3 concentrates on the Portfolio level
Because it is structured in this way, it does mean that you don’t have to read the
book in order. If you are a Scrum Master then maybe Part 1 is all you need to read,
although it might be helpful to understand the coordination at the ART level. If you
are an RTE, then you definitely need to read Part 2, but having insight at the team
level will certainly be valuable. If you are a senior leader or a portfolio Manager,
then it will come as no surprise that Part 3 is for you.
Here is a summary of the chapters:
Part 1, Agile Teams
Chapter 1, Thriving in the Digital Age, sets the foundation for why SAFe® and the
value it brings to organizations.
Chapter 2, Building the Team, delves into the structure and key roles of the Agile
Teams.
Chapter 3, Day to Day with a SAFe® Team, looks at the day-to-day operation of
these teams.
Chapter 4, Team Backlog Management, looks at why backlogs are important for
surfacing, prioritizing, and tracking the work of the team and how they should be
managed to be most effective.
Chapter 5, Team Iteration Events, examines how the SAFe® events (sometimes
called ceremonies) work best and what happens when we try to do them a different
way, or even eliminate them altogether.
Part 2, Agile Release Trains
Chapter 6, Agile Release Trains, helps you understand some of the key
considerations when you are launching your first ART, recovering an ART, or
maturing an ART.
Chapter 7, Release Trains Day to Day, looks at making sure ARTs operate correctly
so that they are successful.
Chapter 8, ART Backlog Management, looks at what the ART backlog is and how it
differs from other backlogs. It also discusses how to create and manage the backlog
and ensure it is the right size.
Chapter 9, Iteration Events for the Train, looks at the various activities and events
that occur each iteration for an ART, including all the Syncs, the ART Board, and
the Iteration System Demo.
Chapter 10, PI Events, looks at the several key events that happen as part of the PI
boundaries and that only occur once in a PI.
Part 3, Portfolio
Chapter 11, Enterprise Strategy, considers what Enterprise Strategy is and how
Enterprise Strategy for an organization needs to adapt in the same fashion that the
teams do.
Chapter 12, Building Your Portfolio, looks at the various tools to help build out and
define your portfolio and the critical task of Value Stream Identification.
Chapter 13, Establishing Lean Budgets, looks at how we move from traditional
Project cost accounting to lean Agile budgeting.
Chapter 14, Portfolio Backlog Management, in a similar fashion to the ART

Backlog, explores how a Portfolio Backlog should be managed to be most effective.
Chapter 15, Measuring Progress, looks at the metrics that help determine whether
the ARTs within your portfolio are performing well and also considers some
additional Portfolio Measures as well.
Chapter 16, Leadership Alignment, looks at how to equip your leaders for this new
environment.
This book covers some of the common pitfalls that people encounter when they
adopt and customize SAFe® for their organization. Whether as development team
members, Product Owners or Product Managers, Release Train Engineers, System
Architects, DevOps practitioners, or other Stakeholders, this book will help you
understand why SAFe® works, and how to customize it for your needs safely.
Remember this is a handbook, not a reference guide, so we only cover 80% of what
you will encounter day-to-day. For example, we have specifically not included large
solutions because the first rule of scaling is DON’T!
Darren taught Implementing SAFe® back in 2017 with one of the leading lights in
SAFe®. At the time, that person had launched 50 ARTs and only 2 were large
solutions; one was because it was a genuinely large solution, and in the other case,
the organization insisted! We see too many examples of large solutions that are not
warranted.
Remember Agile principle number 10: “Simplicity—the art of maximizing the

amount of work not done—is essential.”
Scaling brings a level of complication and coordination. If you don’t need to scale,
then keep your implementation as simple as possible.
We have tried to cover the most common challenges that you will encounter with
our collective experience with a number of pro tips, stories from the real world, and
cautions. Our hope is that these will help with your implementations and also
provide some great anecdotes if you decide to teach a class.
Download the example code files

You can download the example files for this book from GitHub at
https://github.com/PacktPublishing/SAFe-Coaches-Handbook. If there’s an update,
it will be updated in the GitHub repository.
We also have other code bundles from our rich catalog of books and videos
available at https://github.com/PacktPublishing/. Check them out!
Download the color images

We also provide a PDF file that has color images of the screenshots and diagrams
used in this book. You can download it here: https://packt.link/7Q2FV.
Conventions used
There are a number of text conventions used throughout this book.
Bold: Indicates a new term, an important word, or words that you see onscreen.
Here is an example: “We need four things when we look at WSJF:
1. User Business Value: How important is this to our businessor customer?”
TIPS OR IMPORTANT NOTES

Appear like this.
Get in touch
Feedback from our readers is always welcome.
General feedback: If you have questions about any aspect of this book, email us at
[email protected] and mention the book title in the subject of your
message.
Errata: Although we have taken every care to ensure the accuracy of our content,
mistakes do happen. If you have found a mistake in this book, we would be grateful
if you would report this to us. Please visit www.packtpub.com/support/errata and
fill in the form.
Piracy: If you come across any illegal copies of our works in any form on the
internet, we would be grateful if you would provide us with the location address or
website name. Please contact us at [email protected] with a link to the
material.
If you are interested in becoming an author: If there is a topic that you have
expertise in and you are interested in either writing or contributing to a book, please
visit authors.packtpub.com.
Share your thoughts

Once you’ve read SAFe® Coaches Handbook, we’d love to hear your thoughts!
Please click here to go straight to the Amazon review page for this book and share
your feedback.
Your review is important to us and the tech community and will help us make sure
we’re delivering excellent quality content.
Download a free PDF copy of this book

Thanks for purchasing this book!
Do you like to read on the go but are unable to carry your print books everywhere?
Is your eBook purchase not compatible with the device of your choice?
Don’t worry, now with every Packt book you get a DRM-free PDF version of that
book at no cost.
Read anywhere, any place, on any device. Search, copy, and paste code from your
favorite technical books directly into your application.
The perks don’t stop there, you can get exclusive access to discounts, newsletters,
and great free content in your inbox daily
Follow these simple steps to get the benefits:

2. Scan the QR code or visit the link below
https://packt.link/free-ebook/9781839210457
3. Submit your proof of purchase
4. That’s it! We’ll send your free PDF and other benefits to your email directly
1
Thriving in the Digital Age

One of the most influential books for SAFe® 5.x and SAFe® 6.0 is Product to
Project: How to Survive and Thrive in the Age of Digital Disruption with the Flow
Framework by Mik Kersten.
The following quote from his book could not be more appropriate following the
Covid-19 Pandemic:
“A period of frenzied growth is turning into a mass extinction event for those
companies that do not learn how to connect business operations to software
delivery.
Those that master digital business models and software at scale will thrive.
Many more, unfortunately, will not.” (Project to Product, Mik Kersten)
So, welcome to the age of software and digital—an interconnected, real-time world
in which every industry is dependent on technology and every organization (at least
in part) is a software company. To remain competitive, enterprises need to
transform their operations, business solutions, and customer experience into a
digital interface. The larger challenge in many enterprises is that their current
business models, organizational hierarchies, and technology infrastructures can’t
keep pace with the rapid change required.
In this chapter, we will consider the following key topics:

The Technological Revolutions that have changed society
Some of the casualties of the Digital Age
The dual operating system for Business Agility
The seven Core Competencies of Business Agility
Lean, Agile, and SAFe® Values and the 10 SAFe® Lean-Agile Principles
The five Technological Revolutions

In Technological Revolutions and Financial Capital, [1] Carlota Perez plots the
evolution of societal, industrial, and economic capital based on Technological
Revolutions that occurred over the last few hundred years. She opines that these
disruptive trends happen every generation or so.
It started with the Industrial Revolution in the 1770s, followed by the Age of Steam
and Railways in the early 19th Century, then the Age of Steel and Heavy
Engineering in the late 19th Century bringing us to the Age of Oil and Mass
Production in the 20th Century. We conclude with the current Age of Software and
Digital into the 21st Century (see Figure 1.1):
Figure 1.1 – The five Technological Revolutions, adapted from Technological Revolutions and
Financial Capital by Carlota Perez ( © Scaled Agile Inc.)
Each revolution has a regular sequence of three distinct phases:

Installation Period: New technology and financial capital combine to create a “Cambrian explosion” (a
geological term for a relatively short time over which a large diversity of life forms appeared) of new
entrants
Turning Point: Existing businesses either master the new technology or decline and become relics of the
last age
Deployment Period: The production capital of the new technological giants starts to take over
Carlota also explains that she has observed from history that during the Installation
Period, while there is an influx of financial capital to support the new entrants, this
is followed by some form of “crash” or multiple crashes.
If we consider the Age of Oil and Mass Production, we had the Roaring Twenties,
but in 1929, we had the Wall Street Crash, which affected markets around the
world. We then encountered the longest Turning Point in history, which is often
when we see a period of political uncertainty, and in the 1930s, we saw the rise of
fascism in Europe through to the conclusion of the Second World War in 1945.
Those that survived took advantage of the biggest boom in history, with the likes of
Toyota coming to the fore in car manufacturing.
If we turn to the Age of Software and Digital, we had the Dotcom crash that peaked
in 2000 and the global financial crash in 2008. Carlota was on stage in Paris in
2019, presenting at Sogeti’s Utopia for Beginners’ Summit about our Digital Future
[2], and she said:
“Maybe we will have another crash ahead, but after that, we should have the
possibility of a sustainable global information technology Golden Age.”
(Carlota Perez, 2019)
Bearing in mind this was in 2019, and then in March 2020, we had the
unprecedented Covid-19 Pandemic. It was as if Perez predicted this months earlier.
PRO TIP
Watch the video of Carlota Perez on stage in Paris in 2019 because it will help with a great narrative
if you are teaching lesson one in Leading SAFe®. You will find the link in the Further reading section
[2].
Post Covid-19 Pandemic, it is clear that we are now firmly in the Deployment
Phase of the Age of Software and Digital.
We often get asked, “What is the next Technology Revolution?” We are neither
Futurists, nor Clairvoyants. That said, we know that the rise of new technologies
comes with the decline of the previous technology. We then have a period of bubble
prosperity with financial capital supporting the new entrants.
If we follow the current financial capital, then we will see investment in Artificial
Intelligence (AI), Big Data, and the Cloud.
Research by PWC found 72% of executives believe that AI will be the most
significant business advantage of the future.
The company Snowflake, which provides data warehouse-as-a-service, was the

biggest software Intellectual Property Office (IPO) in 2021 and implied five-year
sales growth of 819%. In the cloud, there are three or four major providers, and the
worldwide end-user spending on public Cloud services was forecast to grow to
$332.3 billion in 2021.
The future is ABC – AI, Big Data, and the Cloud, which is reflected in SAFe® 6.0,
where all three elements are represented in the Big Picture.
CAUTION
In a survey, only 9% of respondents strongly agree that their companies have Leaders with the skills
needed to thrive in digital workplaces. Therefore, if we are going to survive the next Technological
Revolution, we need to upskill our Leaders, fast!
Casualties of the digital age

There is no doubt that we are in the deployment stage of the Age of Software and
Digital following the devastating effect of Covid-19 not only on businesses but also
on people’s lives and loved ones.
Part of your narrative when teaching SAFe®, running a workshop, or talking to
Leaders is to remind them of some of those business casualties. The examples
provided are UK based, but you will need examples that reflect your region and
even industry.
Primark, a European fashion retail store, was forced to close all 375 stores 12 days
after the initial Covid-19 lockdown in March 2020. They did not reopen for six
months and reportedly lost £800m in revenue because they could not sell online.
Two years later (yes, two years), in October 2022, Primark announced a trial of a
click-and-collect service across just 25 stores. While Primark has survived, they
still do not have full e-commerce capability.
The same cannot be said for Sir Philip Green, an analog man in a digital world, who
saw his retail empire turn to rags (no pun intended).
The statement “no one will buy fashion online” has been attributed to various
people over the years, but it is difficult to pinpoint a single source, although
reportedly Sir Philip Green did say it regarding ASOS – a British online fashion
and cosmetic retailer.
In the early days of e-commerce, many people were skeptical about the idea of
buying fashion items online, as they felt that consumers would want to try on
clothes and see them in person before making a purchase. However, as online
shopping has become more common and technology has improved, many people
have changed their tune.
Sir Philip Green’s Arcadia Group went into administration (a precursor to try and
avoid Bankruptcy) on November 30, 2020, an early casualty of Covid-19. The irony
is that early in the following year, ASOS was in “exclusive” talks to buy Arcadia’s
Topshop, Topman, Miss Selfridge, and HIIT brands out of administration, though it
only wanted the brands, not the shops.
And in February 2021, ASOS bought the Topshop and Miss Selfridge brands for
£330m.
Arcadia was not the only retail casualty, on December 1, 2020, Debenhams
announced it was going into liquidation. On January 13, 2021, it announced the
closure of six stores in England due to the Covid-19 Pandemic. On January 25,
2021, Boohoo acquired Debenhams for a reported £55m after Debenhams
announced it would shut its remaining stores by May 15, 2021, closing the door on
more than 200 years of trade on UK high streets having been founded in 1778. At
its height, Debenhams was the largest department store chain in the UK and even,
for a large part of the 20th Century, owned by Harvey Nichols of Knightsbridge.
Announcing the final closures, Debenhams said in a statement:

“Over the next 10 days, Debenhams will close its doors on the High Street for
the final time in its 242-year history. We hope to see you all one last time in
stores before we say a final goodbye to the UK High Street.”
In April 2021, Boohoo relaunched its website as Debenhams.com.
PRO TIP
There are many examples of business casualties that did not survive the Turning Point of the Age of
Software and Digital; always try and make your examples relevant to your audience and context.
The Dual Operating System

Over the years, we have had the opportunity to work with a number of founders of
start-up companies or those Leaders that started a new business unit. Surprisingly,
we have a very similar conversation with them, and it often goes something like
this:
Founder: “I really loved it when we were a small start-up company. I had a small
team around me, I knew everything that was going on, I was able to direct them all
in the right direction, and conversations and collaboration were really easy. But
then we became successful, and we grew the organization to the point that we had
to introduce a hierarchy. And while I recognized that we need to be more
‘corporate’ and we needed this hierarchy for stability and, to some extent,
efficiency, I now find that this hierarchy just gets in the way. It is now more difficult
to get things done because I feel that I have to navigate the hierarchy and the
functions within the hierarchy to achieve anything. So, can we get rid of the
hierarchy, and I can go back to run my small team?”
Our response is always the same – “NO!” At this stage, we take comfort in the
words of Dr. John Kotter and from his book Accelerate [3]:
“The solution is not to trash what we know and start over but instead to
reintroduce, in an organic way, a second system - one which would be familiar
to most successful entrepreneurs.”
- John Kotter, Accelerate
We have been doing this for years. We have a functional hierarchy and from that
hierarchy, we create Project teams. By their very nature, Project teams are
temporary organizations with people “loaned” from the hierarchy.
In Chapter 2, we will discuss in more detail about team formation. But for now,
let’s accept that as we form a team, they go through Tuckman’s five stages of
development – Forming, Storming, Norming, Performing, and then Adjourning. At
the point that the team is high-performing, the Project is now completed, and then
we crash and burn the team, returning them to the hierarchy to wait for an
assignment to another Project team. The fifth stage is known as “Adjourning” or
sometimes called “Mourning” because the Project team member really liked
working with that Project team, and it is a form of “grieving” that they left a really
great team and potentially now have to work with another team that they are not
relishing.
“Disbanding high-performing teams is worse than vandalism: it is corporate
psychopathy.” (Allan Kelly, Project Myopia)
So, rather than creating temporary teams around Projects, we want to create long-
lived teams around products. These are long-lived, stable, persistent teams that
cannot be static because people move on, and the nature of the product will change
over its lifespan from a skills and funding perspective. And when we say product, it
could be a product, a service, or even a system that we often call collectively a
solution.
The concept is not widely different from a Project; the difference is that we create
long-lived teams from the hierarchy that are aligned around a product rather than a
Project. We call this complex adaptive network a Value Stream, and SAFe® is the
operating system for this Value Stream network (see Figure 1.2):
Figure 1.2 – SAFe® as the second organizational operating system (© Scaled Agile Inc.)
The ability to respond quickly with innovative business solutions—what we call

Business Agility—is the deciding factor between success and failure. Therefore,
enabling Business Agility is a mission-critical goal for every organizational leader.
Achieving Business Agility requires this dual operating system and a significant
degree of expertise across SAFe’s seven Core Competencies. So, let’s have a look
at these Core Competencies next.
Core Competencies of Business Agility

First, let’s accept that every business is a software business – even BMW no longer
regards itself as a car manufacturer but rather software on wheels. In a premium car,
there are now over 100 million lines of code; in an autonomous car, over 1 billion
lines of code.
So achieving a state of Business Agility requires the entire organization and
everyone involved in delivering business solutions to use Lean and Agile practices.
Historically, Lean and Agile have just been applied to IT teams, and while Business
Agility requires technical agility, it also needs a business-level commitment to
product and Value Stream thinking.
There is no point in having super-efficient IT teams if it takes the team four months
to procure a new piece of kit that is required for their product. There is no point in
having super-efficient IT teams if it takes the team six months to replace a team
member that has left and is part of their agreed headcount.
Business Agility requires not just development and operations but also Finance,
People, Sales and Marketing, and Legal to all come together to use Lean and Agile
practices. To achieve Business Agility, the organization requires a significant
degree of expertise across seven Core Competencies. While each competency can
deliver value independently, they are also interdependent in that true Business
Agility can be present only when the enterprise achieves a meaningful state of
mastery of all competencies.
The seven Core Competencies are as follows (see Figure 1.3):

Lean-Portfolio Management (LPM)

Figure 1.3 – SAFe® Core Competencies (© Scaled Agile Inc.)
Each core competency has three dimensions. We will briefly describe each Core
Competency and it’s associated three dimensions:

Team and Technical Agility focuses on the technical aspects of the solution within
the context of a high-performing Agile Team. It emphasizes the need for the teams
to have a strong technical foundation and the ability to deliver high-quality, reliable
solutions for their customers:
Agile Teams: An Agile Team is the collective capabilities, skills, and behaviors of the cross-functional
teams that are responsible for executing the work and delivering value within an Agile organization. Agile
Teams are at the heart of SAFe® and play a crucial role in driving the success of Agile implementations.
Team of Agile Teams: Agile Teams operate in the context of a SAFe® Agile Release Train (ART). It is a
long-lived, self-organizing team of Agile Teams that work together to define, build, and deliver value in
the form of solutions. The ART aligns the efforts of multiple Agile Teams towards a common mission and
is the primary value delivery mechanism in SAFe®.
Built-in Quality: All Agile Teams have the necessary technical practices in place to produce solutions that
are reliable, maintainable, and scalable.

Agile Product Delivery focuses on the practices and techniques needed to
continuously deliver valuable, high-quality solutions. APD ensures that teams can
quickly and reliably release products and services in increments to customers and
gather feedback for iterative improvement:
Customer Centricity and Design Thinking: Emphasizes the importance of understanding customer
needs, delivering value, and leveraging design thinking principles to create customer-centric solutions.
Develop on Cadence, Release on Demand: Focuses on achieving a balance between predictable,

timeboxed development cycles (cadence) and the flexibility to release software solutions when needed
(on-demand). This competency helps organizations establish a rhythm for development while enabling
frequent and timely delivery of value to customers.
DevOps and the Continuous Delivery Pipeline: Emphasizes the integration of development (Dev) and
Operations (Ops) practices to enable faster and more frequent releases. It includes continuous exploration,
continuous integration, and continuous delivery. DevOps and Continuous Delivery Pipeline allow the
deployment of solutions into production quickly and reliably, reducing time-to-market and improving
feedback loops.

Enterprise Solution Delivery focuses on the ability to deliver large and complex
solutions in a coordinated and efficient manner. This competency enables
organizations to align their efforts, teams, and resources to deliver value at the
enterprise level:
Lean Systems Engineering: Focuses on applying Lean principles to system engineering activities to
optimize the development process and deliver high-quality systems.
Coordinating Trains and Suppliers: Focuses on establishing effective collaboration and coordination
between ARTs and external suppliers or vendors. This competency helps organizations optimize the flow
of value across the Value Stream by integrating and aligning the activities of multiple ARTs, including
those from external suppliers.
Continually Evolve Live Systems: Emphasizes the importance of ongoing improvement and adaptation
of live systems to meet evolving customer needs and business objectives. This competency focuses on the
continuous delivery of value by continuously enhancing and supporting systems throughout their life
cycle.

Lean Portfolio Management focuses on aligning strategy, execution, and investment
decisions to optimize the flow of value across the portfolio of initiatives and ensure
Business Agility:
Strategy and Investment Funding: Focuses on aligning strategic objectives with investment decisions to
maximize value creation. This competency ensures that the organization’s investment decisions are driven
by a clear understanding of business goals and objectives.
Lean Governance: Focuses on establishing a lightweight and effective governance framework that
enables agility and accountability while ensuring compliance and risk management. It emphasizes the need
for governance practices that support the Lean-Agile principles and values.
Agile Portfolio Operations: Focuses on optimizing the flow of value across the portfolio of initiatives and
ensuring effective execution and delivery. It involves aligning and coordinating the activities of ARTs and
providing operational support to drive Continuous Improvement.

Organizational Agility focuses on developing the capability to rapidly adapt, learn,
and respond to changing market conditions, customer needs, and emerging
opportunities. It encompasses the ability to embrace change, foster innovation, and
continuously improve the organization’s practices and processes:
Lean-Thinking People and Agile Teams: Focuses on developing individuals and teams with a Lean
mindset and Agile capabilities. This competency aims to empower people to think Lean, embrace Agile
values, and work collaboratively to deliver value effectively.
Lean Business Operations: Emphasizes the application of Lean principles in various aspects of business
operations to drive efficiency, quality, and value delivery to support the business’s products and services.
Strategy Agility: Focuses on the organization’s ability to sense and respond to changing market
conditions, customer needs, and emerging opportunities. It involves aligning strategy with execution,
fostering innovation, and continuously adapting the strategic direction of the organization.

Continuous Learning Culture focuses on fostering a culture of learning,
collaboration, and improvement at all levels of the organization. It recognizes that a
learning organization is better equipped to adapt to change, innovate, and deliver
value effectively:
Learning Organization: Focuses on creating an environment where continuous learning, improvement,
and innovation are valued and encouraged at all levels of the organization. It aims to foster a culture of
learning and adaptability, enabling the organization to respond effectively to change and drive sustainable
growth.
Innovation Culture: Focuses on fostering an environment that encourages and supports innovation
throughout the organization. It recognizes the importance of innovation in driving growth, competitive
advantage, and the ability to respond to changing market dynamics.
Relentless Improvement: Emphasizes the continuous pursuit of improvement in all aspects of the
organization’s operations. It encourages a culture of ongoing reflection, learning, and enhancement to
drive increased efficiency, quality, and value delivery.

Lean-Agile Leadership focuses on developing Leaders who can effectively guide
and support the organization’s Agile transformation. It involves adopting a
leadership style that promotes the principles of Lean-Agile development and
supports the success of Agile Teams and initiatives:
Mindset and Principles: Focuses on adopting the Agile mindset and embracing the guiding principles that
underpin the framework. This competency emphasizes the importance of mindset and values in driving
successful Agile transformations and achieving Business Agility.
Leading by Example: Focuses on the role of Leaders in modeling and embodying the desired behaviors,
values, and practices of an Agile organization. It recognizes that leadership plays a critical role in shaping
the culture, mindset, and behavior of teams and individuals.
Leading Change: Focuses on equipping Leaders with the knowledge and skills to effectively lead and
navigate organizational change during the Agile transformation. It recognizes that change is inherent in
adopting new ways of working and that effective leadership is crucial for successful change management.
PRO TIP
If you are teaching Leading SAFe®, only provide a brief overview of the seven Core Competencies
because the competencies are covered in more detail in the various lessons that follow the opening
lesson.
We will explore these competencies in more detail in the following chapters, in

particular, Part 1, Team and Technical Agility, Part 2, Agile Product Delivery, Part
3, Lean Portfolio Management, and Chapter 16, Lean Agile Leadership.
CAUTION
If you are teaching Leading SAFe®, only three of the seven Core Competencies are covered - Lean-
Agile Leadership (LAL), Team and Technical Agility (TTA), and Agile Product Delivery (APD), plus
part of Lean Portfolio Management (LPM). As a consequence, you need to remind your learners that
they will only be examined on these competencies.
However, you should encourage your learners to explore the other competencies in the framework.
Values and principles

SAFe® is a knowledge base of proven, integrated principles, practices, and
competencies for achieving Business Agility by implementing Lean, Agile,
DevOps, System Thinking, and Design Thinking at Scale.
SAFe’s® roots are underpinned by Lean Product Development and Agile

Development, so we should really have a brief reminder of these principles.
Lean
In SAFe® 6.0, the SAFe® House of Lean was deprecated in favor of adopting Lean
Thinking [5] from the book of the same name and is a combination of beliefs,
assumptions, attitudes, and actions and is summarised by five principles. To help
you explain them if you are teaching a SAFe® course, we have provided a brief
summary of each:
Precisely specific value by product: Focus on delivering value to the customer by understanding their
needs and preferences and creating products and services that meet or exceed their expectations.
Identify Value Stream for each Product: Identify the Value Stream, which is the entire process of
delivering a product or service, and eliminate any steps that do not add value or that create waste.
Make value flow without interruptions: Ensure that the Value Stream flows smoothly, without
interruptions, delays, or bottlenecks, by reducing variability, improving communication, and synchronizing
activities.
Let the customer pull value from the producer: Create a pull system where products and services are
produced based on customer demand rather than pushing them into the market or storing them in
inventory.
Pursue perfection: Strive for Continuous Improvement by relentlessly pursuing perfection in all aspects
of the Value Stream, using feedback, data analysis, and experimentation to identify and eliminate waste
and inefficiencies.
PRO TIP
Pursue perfection feels slightly incongruous with Agile thinking when we talk about “good enough,”
especially when we want fast feedback. I try to remind the class that I would consider this principle as
Relentless Improvement.
Agile
The other significant historical body of work is the Agile Manifesto [6], when 17
thought Leaders from the software industry got together in February 2001 at The
Lodge at Snowbird ski resort in the Wasatch Mountains of Utah.
They wanted to try to find common ground, and what emerged was the Agile
Software Development Manifesto with representatives from Extreme Programming,
Scrum Dynamic System Development Method (DSDM), Adaptive Software
Development, Crystal, Feature-Driven Development, Pragmatic Programming, and
others sympathetic to the need for an alternative to documentation driven,
heavyweight software development processes convened. The values of Agile can be
seen in Figure 1.4:
Figure 1.4 – Manifesto for Agile Software Development
CAUTION
Even experienced software developers will misread the manifesto by replacing “over” with “instead.”
For example, “Working software INSTEAD of comprehensive documentation.”
You will often hear, “We don’t do documentation or planning because we are ‘agile.’” Well, that is
clearly not the case. People never read the last sentence at the bottom of the values:
“That is, while there is value in the items on the right, we value the items on the left more.”
If you have ever worked in the medical industry, then you will know that the Food and Drug
Administration (FDA) will not approve your device unless you have the documentation to support it.
They won’t care that you did it in an Agile way!
I would also contend that we do more planning in Agile than in any other software process; in Scrum,
we plan every iteration, and you could argue every day at the Team Sync.
SAFe® Core Values

SAFe® has four Core Values [7]. These tenets are so fundamental to the practice of
SAFe® that without them, the practices in the framework will inevitably fail to
deliver the intended business results that prompted the decision to “go SAFe.”
These core values are briefly described here:
Alignment: This value emphasizes aligning all teams and Stakeholders around a common goal and vision.
It involves developing a shared understanding of objectives, priorities, and dependencies across the
organization.
Transparency: This value emphasizes the importance of transparency and visibility at all levels of the
organization. It involves creating an environment where everyone has access to the same information and
can work collaboratively towards common goals.
Respect for people: This value emphasizes the importance of treating people with dignity, trust, and
compassion. This principle recognizes that people are the most valuable asset in any organization and that
their creativity, expertise, and engagement are essential to achieving organizational goals.
Relentless improvement: This value emphasizes the importance of continuously striving to improve all
aspects of the organization, from processes and systems to products and services. The value of Relentless
Improvement lies in its ability to drive innovation, increase efficiency, and enhance customer satisfaction
while reducing waste, errors, and inefficiencies.
These represent the foundational beliefs that are key to SAFe’s® effectiveness.
These tenets help guide the behaviors and actions of everyone participating in a
SAFe® Portfolio. Those in positions of authority can help the rest of the
organization embrace these ideals by exemplifying these values in their words and
actions.
PRO TIP
When describing these values, try and relate with a story of a leader that you know demonstrated
these values.
SAFe® Lean-Agile Principles

Like the Agile Manifesto, the SAFe® Principles have not changed much over the
years; however, more recently, there have been a couple of evolutions; originally,
there were 9 principles, then a 10th was added in version 5, and in version 6.0
principle 6 was changed to “Make value flow without interruptions.” The full 10
principles are shown in Figure 1.5:
Figure 1.5 – SAFe® Lean-Agile Principles ( © Scaled Agile Inc.)
We do not intend to go through all the 10 principles in this book but instead, refer
you to an article on the SAFe® Framework [8]. However, it is vital that as a Coach,
you fully understand these principles because, as Deming puts it so eloquently:
“A common disease that afflicts management and government administration
the world over is the impression that ‘Our problems are different.’ They are
different, to be sure, but the principles that will help to improve the quality of
product and service are universal in nature.” (W. Edwards Deming, Out of the
Crisis [9])
One of our very experienced Coaches, when a new Release Train Engineer (RTE)
asks her a question about a particular challenge, will always answer, “What do the
principles advise us to do?” And that should always be our go-to source for any
problem or challenge that we are going to solve.
PRO TIP
The lesson on Lean Agile Leadership (LAL), which contains all the values and, in particular, the 10
SAFe® Principles, is a long lesson and can be very theoretical. Therefore, it is important that as a
trainer, you need to bring color to the principles.
I have a hypothesis that in our personal lives, we apply these principles all the time without thinking,
but when we step inside our corporate walls, suddenly, these principles feel completely alien. This is
in no small measure attributable to the legacy policies and the view “this is how we do things around
here” and have done for the last 20, 30 years. We certainly need to remediate these legacy policies
for the digital world.
So, when I teach the SAFe® principles, I bring color to the lesson by relating them to some of my
personal experiences so that the learners can consider how they could match a similar mindset with
their organization.
Summary
We have covered a lot of ground in this opening chapter, from the five
Technological Revolutions to some of the casualties of the current Age of Software
and Digital. We also considered the Dual Operating Model for Business and the
Core Competencies that enable Business Agility. Finally, we considered some of
the roots of SAFe®, including Lean Thinking, the Agile Manifesto, and then
SAFe®’s own Core Values and Principles.
Now that we have established the foundation, we are now in better shape to explore
teams in more detail in Part 1, the ART in Part 2, and finally, the Portfolio in Part
3.
But first, time to get a coffee.
Further reading
Technological Revolutions and Financial Capital, Carlota Perez
Sogeti “Utopia for Beginners” Summit Paris 2019: https://www.youtube.com/watch?v=GrFoaqDrgEU
Accelerate, John Kotter

Business Agility: https://scaledagileframework.com/business-agility
Lean Thinking, James P. Womack and Daniel T. Jones
Agile Manifesto: http://agilemanifesto.org/
SAFe® Core Values: https://scaledagileframework.com/safe-core-values/
SAFe® Lean-Agile Principles: https://scaledagileframework.com/safe-lean-agile-principles/
Out of the Crisis, W. Edwards Deming

Part 1: Agile Teams
Agile Teams are the foundation for success for many organizations. They consist of
a group of people working together to achieve a common collective goal. Over the
next few chapters, we will take a look at what an Agile Team is and how to
effectively build long-lasting teams that will ultimately drive organizational
success.
This part has the following chapters:

Chapter 2, Building the Team
Chapter 3, Agile Team Iteration and PI Execution
Chapter 4, Team Backlog Management
Chapter 5, Team Iteration Events

2
Building the Team

In today’s fast-paced business environment, building an effective Agile Team is
crucial for success. Just like in sports, teamwork is key to achieving goals and
delivering results. The Covid-19 pandemic has highlighted the importance of social
connections and collaboration, and this has translated into the workplace as well.
In this chapter, we will delve into the essential components of an Agile Team, the
roles that each team member plays, and the various types of Agile Teams that can
exist in an organization. We will explore the characteristics that make Agile Teams
unique and examine how they operate within an Agile Framework.
In this chapter, we’ll cover the following topics:

Agile team roles and responsibilities
Team types
Additionally, we will provide practical tips and best practices for building and
managing Agile Teams, as well as the challenges that can arise in the process. By
the end of this chapter, you will have a comprehensive understanding of what it
takes to create a successful Agile Team in your organization.

An Agile Team is a group of individuals working toward a collective goal. It
typically consists of 10 members or less that together have the skills to deliver
value to the customer. This includes the ability to define the work, build or do the
work, test the work, and ultimately, release or deliver it to the customer.
This is a cross-functional team as they have all the necessary skills to complete and
deliver the work. There is often a perception with a cross-functional team that
everyone on the team needs to be able to do everyone else’s job. That, however,
isn’t the case; we are looking for the team to have the skills, not each individual.
As we consider high-performing teams, we are looking for individuals to be able to

flex and help in other areas outside of their primary expertise to ensure long-term
team success. An example would be a person who primarily develops code but
could help develop test scripts or execute tests. We would then consider this person
to be T-Shaped. A T-Shaped individual has a deep area of expertise, and knowledge
in other areas, although not as deep as their primary competency.
When we build our teams, we want to optimize them to allow for effective
communication and to deliver value each iteration. Often when building a team,
you will need individuals from different parts of the organization to work together.
This helps improve communication and reduces handoffs and thus waste.
A second consideration when creating a team is that they are self-organized and
self-managed. This doesn’t always mean that teams get to do what they want when
they want, but that they are aligned toward delivering value and are organized in a
way that allows them to be largely self-sufficient and, over time, become self-
managing.
PRO TIP
Can the teams really be self-organized? If you haven’t read Sandy Mamoli’s book Creating Great
Teams: How Self-Selection Lets People Excel [11], then I suggest that you add it to your reading list.
However, you must read the Pretty Agile Blog of Team Self-Selection with SAFe® and Structuring the
ART [1]. This is a practical example of how this can be achieved with an ART.
When we establish teams, they don’t naturally work together seamlessly from day
one. All teams, including professional sports teams, mature to become high-
performing teams. Tuckman [2] has defined four stages of group development that
teams progress through to become high performing. Tuckman later refined his
theory in 1975 and added a fifth stage to the Forming, Storming, Norming,
Performing model: Adjourning. This is also referred to as Deforming and
Mourning.
Figure 2.1 – Tuckman’s stages of team dynamics (© Scaled Agile, Inc.)
Our high-performing teams know each other, their strengths, and their weaknesses,
and work together on a daily basis for as long a period of time as possible. Long-
lived teams are key to long-term success as this allows the team to progress through
the stages to achieve high performance.
As an organization, it is important to create a working environment for the teams to
work together. This may involve investing in infrastructure and tooling, supporting
team formation (for example, supporting social time or team building events),
establishing working agreements, and rewarding teams and not just individual
performance.
To ensure success, Agile Teams have two key roles that are members of the team:
the Product Owner (PO) and the Scrum Master/Team Coach (SM/TC).
Agile Team Roles and Responsibilities

As mentioned previously, we have two specialty roles on our Agile Teams. These
two individuals work together to help the team become high-performing and to
deliver value to the customer in small incremental batches.
PRO TIP
In SAFe® 6.0 the Scrum Master role has been retitled to Scrum Master/Team Coach to reflect that
SAFe® embraces not just Scrum but also Kanban and other team execution methodologies.
Figure 2.2 – Scrum Master/Team Coach and Product Owner Responsibilities (© Scaled Agile, Inc.)
Due to the importance of each of these roles, let’s take a look at each in more detail
as well as outline the responsibilities for our Agile Teams.
Product Owner
The PO role is a particularly challenging role in that it often requires both business
and technology knowledge and experience. The individual has to manage numerous
relationships including with the team, with customers, and with product
management at a minimum.
There are some key characteristics you will want to consider when identifying a PO
for your Agile Team:
Vision: A PO contributes to the vision of what the product should be and what it should achieve. This
vision should align with the company’s goals and should inspire the team to work toward that vision.
Effective Communication Skills both Written and Oral: A PO must be able to communicate effectively
with different Stakeholders. This includes the Agile Team, management, customers, and other parts of the
organization. They should be able to convey ideas clearly, listen actively, and respond appropriately.
Ability to Understand Customer Wants and Needs: A PO must have a deep understanding of the
customers’ wants and needs. They should be able to identify customer pain points and prioritize stories
that address those issues. They should also be able to communicate customer feedback to the team.
Good Business Sense: A PO should have a good understanding of the business side of the product. They
should be able to identify the market opportunity, competition, and potential revenue streams. They should
also be able to balance customer needs with business goals.
Technical Knowledge: A PO should have a good understanding of the technical aspects of the product.
This includes knowledge of the software development life cycle, software architecture, and design
principles. They should be able to communicate technical requirements to the team.
Good Negotiation Skills: A PO should be able to negotiate effectively with Stakeholders. This includes
customers, team members, and management. They should be able to resolve conflicts and reach
agreements that benefit everyone.
Trust: A PO should be trusted by the team and other Stakeholders. They should be able to build and
maintain relationships based on mutual respect and trust.
Courage: A PO should have the courage to make tough decisions. This includes making decisions that
may not be popular or may require taking risks. They should also be able to take responsibility for the
outcomes of their decisions.
PRO TIP
Often, organizations consider the Product Owner role as a “staff-level” position as there is a
perception that they just write User Stories. Consider the characteristics outlined previously and the
responsibilities outlined as follows and look at individuals who are currently in management roles to
become your Product Owners. To be an effective Manager, they likely already possess the
characteristics we are looking for and may already be informally serving in this role when providing
and guiding existing team or individual work.
In SAFe® 6.0, responsibility wheels have been introduced for each role. Let’s look
at the responsibilities of the PO in Figure 2.3, starting at the top right:
Figure 2.3 – Product Owner Responsibilities (© Scaled Agile, Inc.)
Connecting with the Customer: A PO is responsible for connecting with the customer to understand their
wants, needs, and pain points. They should gather customer feedback and use it to inform the product
strategy in conjunction with Product Management.
Contributing to the Vision and Roadmap: A PO is responsible for contributing to the ART Vision and
Roadmap. They should ensure alignment with the priorities and help communicate the Roadmap to the
teams and Stakeholders.
Managing and Prioritizing the Team Backlog: A PO is responsible for managing and prioritizing the
team backlog. They should collaborate with the team to ensure that the team backlog items are clear,
concise, and achievable. They should prioritize the team backlog based on customer needs, business goals,
and technical dependencies.
Supporting the Team in Delivering Value: A PO is responsible for supporting the team in delivering
value to the customer. They should be available to answer questions, provide guidance, and remove
obstacles that prevent the team from delivering high-quality work.
Getting and Applying Feedback: A PO is responsible for getting and applying feedback from various
sources. They should gather feedback from customers, Stakeholders, and the team and use it to
continuously improve the product. They should also be open to constructive criticism and willing to make
changes based on feedback.
PRO TIP
The PO role is a challenging and essential role and isn’t a part-time activity. To ensure the best
possible success, we recommend a single 100% dedicated PO for each Agile Team. Finding a PO
and ensuring they are set up for success will go a long way in creating a high-performing team.
Scrum Master/Team Coach
The Scrum Master/Team Coach (SM/TC) is the servant leader and Coach for the
team. They facilitate the team events, processes, and practices, and support the team
in delivering value.
There are a few key characteristics a Scrum Master/Team Coach should possess:
Servant Leadership: A Scrum Master/Team Coach should embody servant leadership, which means they
prioritize the needs of the team above their own. They should listen actively, support team members, and
help remove obstacles that prevent the team from being successful.
Understands and Empathizes with Others: A Scrum Master/Team Coach should have a deep
understanding of the team members’ perspectives, strengths, and weaknesses. They should be able to
empathize with the team members and help create a safe and collaborative environment.
Encourages and Supports the Development of People and Teams: A Scrum Master/Team Coach should
encourage and support the professional development of team members. They should help identify areas for
improvement and provide opportunities for growth. They should also foster a culture of continuous
learning and improvement within the team.
Uses Influence over Authority: A Scrum Master/Team Coach should rely on influence rather than
authority to get things done. They should build relationships based on trust and respect and use their
influence to facilitate collaboration and alignment within the team and with external Stakeholders.
Thinks Beyond Day-to-Day Activities: A Scrum Master/Team Coach should be able to think beyond
day-to-day activities and focus on the long-term goals of the team. They should help the team to
continuously improve by identifying areas for improvement and experimenting with new approaches.
Helps Without Diminishing the Commitment of Others: A Scrum Master/Team Coach should be able
to help the team without taking over or diminishing the commitment of others. They should provide
guidance and support when needed but should also empower team members to take ownership of their
work.
Protects the Team: A Scrum Master/Team Coach should protect the team from external distractions and
disruptions. They should help create a safe and collaborative environment where team members feel
comfortable sharing their opinions and ideas without fear of reprisal.
PRO TIP
Often, organizations consider the Scrum Master role as an entry-level position. Consider a
professional sports team – would you select someone who hasn’t Coached before as the head
Coach? Probably not. Make sure you don’t overlook the importance of this role. Many organizations
have “Team Leads.” These individuals may be good candidates for a Scrum Master/Team Coach as
they have already demonstrated the desire already in that type of role.
The following Scrum Master/Team Coach responsibility wheel outlines five key
responsibilities of an Scrum Master/Team Coach, in Figure 2.4:
Figure 2.4 – Scrum Master/Team Coach Responsibilities (© Scaled Agile, Inc.)
Facilitating PI Planning: The Scrum Master/Team Coach facilitates the PI Planning Event, ensuring that
the team understands the goals and objectives of the upcoming PI and that the PI plan aligns with the
overall business strategy.
Supporting Iteration Execution: The Scrum Master/Team Coach helps their teams to plan and execute
iterations effectively via the team events. They help the team identify and resolve any impediments that
may prevent them from achieving their goals.
Improving Flow: The Scrum Master/Team Coach continuously seeks to improve the flow of value
through the team. They identify and eliminate bottlenecks and impediments to ensure that the team can
deliver value quickly and efficiently.
Building High-Performing Teams: The Scrum Master/Team Coach helps to build high-performing teams
by facilitating team-building activities and promoting collaboration and communication. They also
encourage the team to continuously improve their processes and practices.
Improving ART Performance: The Scrum Master/Team Coach works with the ART to continuously
improve performance. They facilitate collaboration, build trust with Stakeholders, help the teams inspect
and adapt, and facilitate Continuous Improvement events.
The Scrum Master/Team Coach role is critical to the success of the team and their
ability to deliver. SAFe® recognizes that this can be a part-time or full-time job
depending on the size of the team, maturity of the team, responsibilities, and
context. Consider your organizational constraints and the experience and training of
each Scrum Master/Team Coach when having them support multiple teams or
deliver work for the team.
PRO TIP
Organizational constraints may influence and push compromises for key Agile Roles and look to have
the PO or Scrum Master/Team Coach be a single role or to even have one person fill both roles. You
will want to avoid a single individual serving both roles at all costs. It is a conflict of interest and,
ultimately, will hamper the team’s ability to reach high performance. The compromise I would be
willing to make would be to Train and have team members rotate the responsibilities of the Scrum
Master/Team Coach; this comes at a cost as the team won’t be able to deliver as much work each
iteration. As teams mature and are kept together as long-lived teams, the need for a full-time Scrum
Master/Team Coach may diminish.
Team Responsibilities
Just like the PO and Scrum Master/Team Coach have specific responsibilities, our
Agile Teams have five key responsibilities, as depicted in Figure 2.5.
Figure 2.5 – Responsibilities of an Agile Team (© Scaled Agile, Inc.)
Connecting with the Customer: Agile Teams are responsible for building products or delivering services
that meet customer needs. They need to connect with customers regularly, to gather feedback, and
incorporate it into their work to ensure customer satisfaction.
Planning the Work: Agile Teams are responsible for planning their work, breaking it down into smaller,
manageable tasks, and estimating the effort required to complete the work. They create a backlog of work
items and prioritize them with the PO.
Delivering Value: Agile Teams are responsible for delivering value frequently, typically in small batches
within short iterations. They need to ensure that their work integrates with others and meets the Definition
of Done (DoD).
Getting Feedback: Agile Teams are responsible for getting feedback on their work from different
Stakeholders, including customers, POs, and other members of the organization. They use this feedback to
improve their work and ensure that it meets customer needs.
Improving Relentlessly: Agile Teams are responsible for continuously improving their work processes,
tools, and techniques. They need to identify areas of improvement, experiment with new approaches, and
incorporate best practices to improve their performance over time.
PRO TIP
Task switching, also known as context switching, is the act of switching between different teams
and/or tasks. When it comes to team members that are not full-time on a team, task switching can be
costly in terms of productivity and efficiency.
The cost of task switching with a team member can be significant. When team members are
constantly switching between teams and tasks, it can lead to the following:
1. Reduced productivity: It takes time to switch between tasks and get back into the right mindset.
This can slow down progress and reduce productivity.
2. Increased errors: When team members are constantly switching between teams and tasks, it can
be easy to make mistakes or overlook important details.
3. Increased stress: Task switching can be stressful, especially if team members feel like they are
constantly juggling multiple responsibilities and being pulled in different directions by different teams.
4. Reduced creativity: When team members are constantly switching between team tasks, it can be
difficult to get into a state of flow and tap into their creativity.
People are often unaware of the cost of task switching so here is a simple exercise that I get an
individual to run.
I ask the individual to horizontally create the following pattern on a flip chart:
I time the whole process. I then ask them to do exactly the same but this time, concentrating on one
element at a time:
I compare the timings of the first run with the second; the results are significant. On average, the first
run takes about 45 to 50 seconds. The second run was less than 30 seconds. For a simple task, this
is a 30% to 40% improvement when not task switching between numbers, alphabet, and Roman
numerals.
Now that we understand what an Agile Team is, who is on it, and the
responsibilities of an Agile Team, let’s look at the types of teams and how we can
organize them in our companies.
Team Types
When we create our Agile Teams, we want to ensure they are organized to deliver
value. As described in the book Team Topologies [7], there are four primary ways
to organize our Agile Teams, as shown in Figure 2.6:
Figure 2.6 – Team Topologies (©Matthew Skelton and Manual Pais from Team Topologies)
Stream-Aligned Team – This team is organized around the flow of work and can deliver value directly to
the customer or end user. This is the most common type of Agile Team. Stream-Aligned Teams are
empowered to build and deliver value as quickly, safely, and independently as possible. Stream-Aligned
Teams are responsible for building and delivering customer value with minimal dependencies on other
teams and should be cross-functional and long-lived, developing knowledge and creating efficiencies over
extended periods.
Complicated-Subsystem Team – This is organized around specific subsystems requiring deep specialist
skills and expertise. They build and maintain specialized system components, safety-critical systems
elements, specialty algorithms or business rules, or parts of a cyber-physical system. Complicated-
Subsystem Teams collaborate with Stream-Aligned Teams, maintain their level of expertise, and take
responsibility for built-in quality, performance, and architectural robustness.
Platform Team – This is organized around developing and supporting platforms that provide services to
other teams. They provide internal services for Stream-Aligned Teams, reducing their cognitive load and
increasing their autonomy. Platforms are treated as products, and Platform Teams should focus on
usability, incremental development, and collaboration with Stream-Aligned Teams. Their services should
be well-documented, easy to use, narrow in scope, and offer reuse opportunities.
Enabling Team – This is organized to assist other groups with specialized capabilities and help them
become proficient in new technologies. Enabling Teams are teams that provide support and guidance to
other teams, assisting them in gaining new skills and expertise around specific technical or product
management areas. They are an essential construct in organizations that regularly integrate new practices
and technologies, as they help teams get up to speed with emerging technologies. Examples of Enabling
Teams include the System Team, which assists Agile Release Train (ART) teams in building and
supporting the Continuous Delivery Pipeline (CDP), and specialized teams that provide support in areas
such as DevOps, testing, and security. The responsibilities and behaviors of Enabling Teams include
identifying opportunities for improvement, collaborating proactively, communicating regularly, and
promoting a Continuous Learning Culture.
SAFe® has a specialized Agile Team, which is the System Team, and has specialty
roles and services needed for ART success, which is Shared Services. Let’s briefly
explore both of those.
System Team
The System Team [8] is a specialized Enabling team that supports the ART in
building and maintaining the underlying infrastructure that supports the delivery of
value. The team’s focus is on the CDP, the development and deployment
environments, and release management. The System Team has several
responsibilities, including building and evolving the CDP, developing and
maintaining the shared development and test environment, supporting the release
management process, and identifying and implementing improvements to the
system’s architecture and design. They work closely with other ART teams to
ensure that the underlying system infrastructure is reliable, scalable, and secure. For
more information on the System Team, their responsibilities, and how they support
an ART, check out Chapter 6.
Shared Services
We recognize that Shared Services [9] isn’t a team per se; they are important in
providing support to the Agile Teams but are not dedicated full-time. Shared
Services are centralized groups that provide specialized technical or business
services to the teams. They help to eliminate redundancy and promote consistency
across the organization, allowing teams to focus on their core competencies. Shared
Services can also provide economies of scale, reduce costs, and improve quality by
consolidating resources and standardizing practices. Examples of Shared Services
include HR, finance, and legal.
Summary
In this chapter, we learned that an Agile Team is a cross-functional group of
individuals who collectively possess the skills necessary to deliver value. We
discovered that teams progress through stages of group development to become
high-performing and that long-standing teams are critical to long-term success.
We also learned about the importance of self-organized teams that are largely self-
sufficient and self-managing. The chapter outlined the key roles of the Product
Owner and the Scrum Master/Team Coach in helping the team become high-
performing and deliver value in small incremental batches.
Finally, we learned about different types of Agile Teams, and we now have a
comprehensive overview of the key elements necessary for an Agile Team to
succeed. Let’s next take a look at what an Agile Team does day-to-day.
Further reading
1. Pretty Agile Blog: https://prettyagile.com/2016/12/preparing-for-team-self-selection-with-safe-structuring-
the-art/
2. Tuckman’s Stages of Team Dynamics (1977)
3. Agile Teams: https://scaledagileframework.com/agile-teams/
4. Remote Teams: https://scaledagileframework.com/working-successfully-in-agile-with-remote-team-

members/
5. Product Owner: https://scaledagileframework.com/product-owner/
6. Scrum Master/Team Coach: https://scaledagileframework.com/scrum-master-team-Coach/
7. Pais, M., & Skelton, M. (2019). Team Topologies: organizing business and technology teams for fast flow.
IT Revolution Press.
8. System Team: https://scaledagileframework.com/system-team/
9. Shared Services: https://scaledagileframework.com/shared-services/
10. Team Topologies: https://scaledagileframework.com/organizing-agile-teams-and-arts-team-topologies-at-

scale/
11. Sandy Mamoli, David Mole (2015). Creating Great Teams: How Self-Selection Lets People Excel.
Pragmatic Bookshelf.
3
Agile Team Iteration and PI Execution

You have an Agile Team; now what? As a Coach, you have an exciting role in
working with teams. Too often, the teams get overlooked by Coaches who focus on
the ART, or even the organization and leave the teams on their own.
You are likely familiar with the quote:

You can’t scale crappy code (or hardware, or anything else).
- Dean Leffingwell, Creator of SAFe®
The part “or anything else” absolutely applies to your teams. If your teams are
crappy, then your ART will be crappy, and so on.
In this chapter, we are going to take a look at how we ensure we have a successful
team by looking at the following:
Day-to-Day activities of a Product Owner, Scrum Master/Team Coach, and Agile Team within an Iteration
Day-to-Day activities of a Product Owner, Scrum Master/Team Coach, and Agile Team within a PI
Day-To-Day within an Iteration

Let’s take a look at the events we hold at the team level as it will provide the
foundation for what we largely replicate in a fashion at the ART level. We will look
at the events role by role to ensure we align with the basic expectations for teams
on the ART.
Iteration Events and the Product Owner

As we discovered in Chapter 2, the Product Owner (PO) is critical to the team. The
PO spends a lot of time working with Product Management, Stakeholders, and
customers to understand the direction the ART is headed, and then with the team to
identify, plan, and coordinate that work. It’s a constant balance of today’s versus
tomorrow’s work.
Figure 3.1 outlines the key responsibilities of the PO; however, let’s look at how the
PO executes these responsibilities through the various team events.
Figure 3.1 – Product Owner Responsibilities (© Scaled Agile, Inc.)
During the iteration, it’s important that the PO is present and involved with the team
every day.
The Product Owner and Iteration Planning

Iteration Planning is one of the most important events for the PO. The PO helps the
team understand and select the most important work that needs to be accomplished,
and in return, gets a commitment on what will be completed at the end of the
iteration.
The PO will provide clarity about the stories or Acceptance Criteria and,
collectively with the team, establish the Iteration Goal.
The PO will need to prepare for this event and the preparation is a key part of their
responsibilities. As we saw in Figure 3.1, Managing and Prioritizing the Team
Backlog is a key responsibility, and the Team Backlog is the primary input into
Iteration Planning.
The Product Owner and the Team Sync

At the Team Sync (formerly known as the Daily Stand-up or DSU), the PO should
actively participate; answering questions, providing clarity, understanding when
items are ready for review. We encourage the PO to attend the Team Sync every day
as they are a member on the Agile Team with a speciality role.
The Product Owner and Team Backlog Refinement
Backlog Refinement, just like Iteration Planning, is critical for the PO. The PO will
want to ensure that they are capturing the conversations and questions from the
team, and then get answers to those questions. The PO will need to provide
clarification and feedback on every story or connect the team with customers and/or
Stakeholders to get direct answers.
The Definition of Ready (DoR) helps hold the PO and Agile Team accountable for
the quality of the stories.
The PO may need to work with Technical Leads or the System Architect on Enabler
Stories and also ensure that the Backlog has the right balance (Capacity Allocation)
of Enabler versus Stories.
PRO TIP
If you are finding that your teams are struggling with their Iteration Planning, it is a sign that you might
need more effective Backlog Refinement.
The Product Owner and the Iteration Review

At the Iteration Review, the PO will share with the Stakeholders the Iteration Goal
and the progress the team has made toward that goal. The PO will then solicit
feedback from the Stakeholders on the work done by the team and share the work
likely to be planned for the next iteration.
This is also an opportunity for the PO to seek help from the Stakeholders on
challenges the team might have.
The Product Owner and the Iteration Retrospective

The PO needs to be at the Iteration Retrospective as they are a member of the team
and are also responsible for helping the team to continuously improve. The PO can
contribute ideas to improve the team’s effectiveness just like any other team
member. The PO should help the team incorporate the improvement items into the
next Iteration Backlog or Team Backlog.
PRO TIP
I am often asked, “Does the PO need to be at the Retrospective?” This is a clue that there may be
some challenges within the team and, most often, the quality of the stories (also known as we aren’t
following or don’t have an agreed upon Definition of Ready), or the PO is wearing multiple hats and
isn’t available. The team usually then takes the opportunity to complain about the PO rather than
working together to relentlessly improve.
As a Coach, you will often get what seems like an innocuous question; ensure that you dig in a little
bit to understand the real root cause of the question.
Iteration Events and the Scrum Master/Team
Coach
It’s critical for the Scrum Master/Team Coach (SM/TC) to be involved with the
team every day, especially new teams. The Scrum Master/Team Coach carries a lot
of the burden in ensuring that the teams are successful and executing effectively.
Figure 3.2 captures the key responsibilities the Scrum Master/Team Coach is
responsible for; however, like the PO, the devil is in the details when it comes to the
everyday interactions with the team.
Figure 3.2 – Scrum Master/Team Coach responsibilities (© Scaled Agile, Inc.)
The Scrum Master/Team Coach never has two days that will be the same. The team
is constantly evolving, the work is changing, dependencies need to be resolved, and
the systems are updating. The one constant is that the Scrum Master/Team Coach is
the glue that keeps it all together.
There is a common misperception that the Scrum Master/Team Coach is the team
administrative assistant, often because the Scrum Master/Team Coach typically
schedules and facilitates the Team Events. While the latter is true, without the
support and drive to relentlessly improve from the Scrum Master/Team Coach, the
team will stagnate.
The Scrum Master/Team Coach and Iteration

Planning
The Scrum Master/Team Coach is the facilitator for Iteration Planning. The Scrum
Master/Team Coach should help ensure that the PO and the team are ready for
planning and with a prioritized Team Backlog. As the facilitator of the event, the
Scrum Master/Team Coach will need to pay close attention to the time and help
capture and follow up on any new questions that arise.
The Scrum Master/Team Coach often works with the team ahead of time to
understand any planned leave that needs to be accounted for in the team’s capacity.
The Scrum Master/Team Coach will often have to help the team to make sure they
don’t over-plan or commit to more work than they can deliver.
The Scrum Master/Team Coach should ensure commitment to the plan at the end of
the event.
The Scrum Master/Team Coach and the Team Sync

The Scrum Master/Team Coach facilitates the Team Sync (formerly the Daily
Stand-up or DSU). Facilitation activities in this event include the following:
Ensuring everyone participates
Ensuring the event keeps to time (typically 15 minutes)
Ensuring the team is tracking their progress to the Iteration Goal and adapting plans if necessary
Providing the team with a way of running in the absence of the Scrum Master/Team Coach
Providing the team with a mechanism to capture impediments and address them in a Meet-After session
After the Team Sync, the Scrum Master/Team Coach will need to facilitate the
resolution of the captured impediments the team raised.
Some pitfalls an Scrum Master/Team Coach will want to avoid are as follows:
Ensuring this event is such that it doesn’t turn into a status meeting
Not following up and closing out impediments
The Scrum Master/Team Coach and Backlog

Refinement
The Scrum Master/Team Coach facilitates Backlog Refinement in conjunction with
the PO. The Scrum Master/Team Coach will want to make sure that the PO is
prepared for Backlog Refinement, help track the items that have been or need to be
discussed, ensure questions are captured and followed up on, and generally provide
support to the PO and team during the event.
The Scrum Master/Team Coach and the Iteration

Review
The Scrum Master/Team Coach should ensure that the team is prepared and ready
to present their work at the Iteration Review. The Scrum Master/Team Coach may
need to work with the team ahead of time to identify how to best present the work.
The Scrum Master/Team Coach will need to work with the PO to determine which
Stakeholders should be invited and to create an agenda highlighting the work that
the team has completed.
The Scrum Master/Team Coach is a cheerleader at this event, ensuring success is

acknowledged and kudos given to the team.
Lastly, the Scrum Master/Team Coach will need to facilitate the preparation and
sharing of the iteration metrics and progress toward PI Objectives with the
Stakeholders.
The Scrum Master/Team Coach and the Iteration

Retrospective
The Iteration Retrospective is where the Scrum Master/Team Coach creativity gets
to bloom by using and creating different retrospectives to garner insights from the
team. At the retrospective, the Scrum Master/Team Coach needs to create a safe
environment for the team to be vulnerable and share their challenges, as well as
celebrate their wins from the last iteration.
Capturing and following up on Improvement Items every iteration should not be

overlooked, and the Scrum Master/Team Coach is responsible for driving these
items within the team.
PRO TIP
It is important that the Iteration Retrospective doesn’t become stale by running the same format
iteration after iteration. By a similar token, you don’t want to make the Iteration Retrospective super
silly. The Scrum Master/Team Coach should focus the retrospective on key areas for improvement
encountered with the iteration: for example, topics such as people, interactions, processes, tools,
assumptions made, and the Definition of Done. A great reference is Agile Retrospectives by Diane
Larsen and Esther Derby [9].
Iteration Activities and the Agile Team

As we look at the responsibilities of an Agile Team in Figure 3.3, we can see that
they largely revolve around the work, whom it is for (customer), figuring out what
the team will do (planning), doing the work, validating the work (feedback), and
relentlessly getting better at the work.
Figure 3.3 – Responsibilities of an Agile Team (© Scaled Agile, Inc.)
To ensure success, there are some key events that we look to the team to participate
in. Regardless of how the team is executing (Scrum or Kanban), every team needs
to maintain alignment with itself and the ART. We will look at each event in the
iteration and the associated responsibilities and activities.
The Agile Team and Iteration Planning

Both Scrum and Kanban teams will participate in planning. Chapter 5 provides a
more in-depth look at the process. Scrum Teams will do this once per iteration,
whereas a Kanban team may often plan more frequently than a Scrum Team, but for
shorter durations.
The entire team needs to be present for planning to ensure alignment, provide input,
and commit to the plans.
The Agile Team and Team Sync

Team members need to ensure they attend the Team Sync every day and that they
are inspecting progress towards their Iteration Goal, adapting their Iteration Plan if
necessary, raising any impediments, and planning their next 24 hours of work.
The Agile Team and Backlog Refinement

All Agile Teams need to be involved in the refinement of the Team Backlog so that
they understand the backlog items in order to be able to develop the solution in the
iterations. This will involve conversations with the PO and the Stakeholders to gain
enough information to split items into small vertical slices that meet the Definition
of Done.
The Agile Team and the Iteration Review

The Iteration Review is primarily used by Agile Teams as an opportunity to get
feedback from Stakeholders and inspect the outcomes and compare them to the
Iteration Goals they have committed to. The Agile Team should present the actual
work that was completed that met the Definition of Done. It’s an opportunity for the
team to celebrate their successes and to identify and address any challenges and/or
stories that were not completed.
PRO TIP
Avoid doing PowerPoint presentations; try showing the actual solution that the team has built.
The Agile Team and the Iteration Retrospective

To ensure relentless improvement, it’s important that teams are holding regular
retrospectives, and this includes Kanban teams. Many Kanban teams will hold their
retrospectives on the same cadence as the ART.
All team members need to participate and provide insight and input into how the
iteration went and how to improve moving forward. After all, it’s the team that is
ultimately responsible for themselves.
Day-To-Day within a PI
SAFe® is a fractal model; everything we do at the team level, we effectively
replicate at the ART level, although the frequency might be different. Figure 3.4 is
one of our favorite images from SAFe® because it shows that correlation.
Figure 3.4 – ART events (© Scaled Agile, Inc.)
In this chapter, we need to explore how the PO, Scrum Master/Team Coach, and
Agile Team participate in these ART events; however, a more detailed explanation
of these events is contained in Part 2. Once you have read Part 2, it might be a
good idea to revisit this chapter.
PI Events and the Product Owner

While the PI Event itself isn’t an everyday occurrence, there are activities
throughout the PI that involve the PO.
The Product Owner and the PI Planning Event

The Team Backlog is the primary input the PO is responsible for ensuring is
prepared for the PI Planning Event. During the event, the PO is critical. In addition
to the Team Backlog, the PO is also responsible for ensuring that the team is staying
aligned with the priorities outlined by Product Management.
The PO has content authority for the Team Backlog; as the teams are planning their
work, questions will often arise, particularly for items in the later iterations, and the
PO needs to be available to answer, go get an answer, or provide enough
information so that the team can plan the work.
The PO and the Scrum Master/Team Coach often work very closely together at PI
Planning, helping to keep the team moving forward with their plans, sequencing the
stories, and crafting the PI Objectives.
The Product Owner and PO/ART Sync

The PO needs to attend the PO Sync or ART Sync. This allows the PO to help keep
the team aligned with the other teams, reorganize the backlog as new information or
dependencies come to light, and share progress toward goals and commitments.
Often, the PO or ART Sync is used to outline the Iteration System Demo based on
the work that was completed in the last iteration.
The Product Owner and Iteration System Demos

The PO should be prepared and work with the team to ensure their work is
integrated with all of the work from the other teams. The PO should be prepared to
help the team show their work within the context of the ART and ensure that
Product Management is aware of the work the team is completing and the feedback
the team needs from Stakeholders or customers.
The PO and the team should consider what feedback they need or work they want
to share each iteration. This can be a good conversation at Iteration Planning.
The Product Owner and the PI System Demo

The PO has a responsibility to make sure the team’s contributions are integrated
into the PI System Demo. The PO may even be asked or work with their team to
show the work they delivered in the context of the solution.
In the same fashion as the Iteration System Demo, the PO and team can identify in
advance what key functionality or feedback they would like to highlight or receive,
and the PO can work with Product Management to ensure it is incorporated into the
demo.
The Product Owner and the Innovation and Planning

Iteration
During the Innovation and Planning (IP) Iteration, the PO will likely be involved
with final adjustments to the Vision and Roadmap for the next PI, which includes
ART Backlog Refinement.
The IP Iteration is the last opportunity for the PO to socialize the Features so that
the teams can create candidate stories in the Team Backlog for PI Planning.
The PO may also work with the team on a hack-a-thon or even attend training with
the teams.
PI Events and the Scrum Master/Team Coach

While the Scrum Master/Team Coach works daily with the team, when in a scaled
environment, there are additional key events and interactions the Scrum
Master/Team Coach participates in.
The Scrum Master/Team Coach and the PI Planning

Event
The PI Planning Event is an extremely hectic event for the Scrum Master/Team
Coach. We’ve included some key activities that the Scrum Master/Team Coach
usually helps with, which, while not comprehensive, will help create a successful
event.
In preparation for the PI Planning Event, the Scrum Master/Team Coach should do
the following:
Calculate Team Capacity for each of the iterations for the PI based on up-to-date Team Velocity taking into
account any planned holidays/vacations
Set up team space with appropriate supplies
Work with the PO to prepare the Team Backlog and stories
Help RTE to ensure a successful event
This is what the Scrum Master/Team Coach should do during the PI Planning
Event:
Keep the team engaged and on track
Participate in Coach Syncs
Adhere to Time Boxes
Keep Boards (Team, ART Planning, and Risks) up to date
Manage Dependencies
This is what the Scrum Master/Team Coach should do after the PI Planning Event:
Help clean up the space
Make sure that plans are captured in your Agile Tool or whatever method you choose to use
It’s important that the Scrum Master/Team Coach is prepared for the event and
understands how the event flows, their responsibilities, and how to help the ART be
successful.
The Scrum Master/Team Coach and Iteration System

Demos
The Scrum Master/Team Coach helps the team ensure they are integrating their
work with the other teams on the ART at each iteration. The Scrum Master/Team
Coach partners with the PO to ensure the team members attend and participate in
the Iteration System Demo, that their completed work is incorporated into the
Iteration System Demo, and that the team receives any feedback from the Iteration
System Demos.
The Scrum Master/Team Coach and the Coach

Sync/ART Sync
The Scrum Master/Team Coach meets and shares with other Scrum Masters/Team
Coaches or ART members the current progress toward delivering the PI Objectives,
discusses dependencies between the teams to ensure alignment, and raises and helps
to resolve any impediments.
The Scrum Master/Team Coach and Inspect & Adapt

(I&A)
Often, the Scrum Master/Team Coach is called upon by the RTE to help with the
various I&A activities.
Like the Iteration System Demo, the Scrum Master/Team Coach will want to work
with the PO to ensure the work is represented at the PI System Demo. Additionally,
the Scrum Master/Team Coach may need to help coordinate schedules for dry runs
of the demo, help ensure the team is prepared, and celebrate the success with the
team.
The RTE may request the Scrum Master/Team Coach to pull and compile various
metrics that will be presented in the Quantitative and Qualitative Metrics section.
The Scrum Master/Team Coach may also facilitate the Competency Assessments
for their teams.
The Scrum Master/Team Coach is often an excellent candidate to facilitate one of

the groups for the Problem-Solving Workshop. A success pattern we recommend is
that the RTE facilitate a workshop with the Scrum Master/Team Coach prior to the
event so that the Scrum Master/Team Coach understands their role in the workshop
and how to best facilitate the activity.
PRO TIP
When a Scrum Master/Team Coach helps to facilitate a Problem-Solving Workshop, they often don’t
get a chance to fully participate in the problems and then the solutions. As a recommendation, if you
have other ARTs within your organization, consider using a Scrum Master/Team Coach from the
other ARTs to help facilitate, so that the incumbent Scrum Master/Team Coach can fully participate in
their ART Problem-Solving Workshop.
Innovation and Planning Iteration and the Scrum

Master/Team Coach
In conjunction with the PO and the team, the Scrum Master/Team Coach will help
the team with the activities they are undertaking, whether that is holding a hack-a-
thon, organizing or attending training, or addressing technical debt.
Also, they will support the RTE with the final preparation for PI Planning,
including ensuring that the PO and the team have a Team Backlog ready for PI
Planning.
PI Events and the Agile Team

When we scale, we need to ensure that we maintain alignment. There are several
activities and events that the teams are involved with during the PI. Let’s take a
look at the key events.
The Agile Team and Iteration System Demos

The team will work with the other teams to ensure their work is integrated and
demoed at every Iteration System Demo. The team members should also attend and
participate in the Iteration System Demo for understanding and alignment with the
other teams. This is a great opportunity for the team to hear directly from
Stakeholders and get real-time feedback on the entire solution.
The Agile Team and the PI System Demo

In the same fashion as the Iteration System Demos, the teams will need to integrate
and demo their work that was completed over the course of the PI. Participation at
this event is necessary and continues to build alignment and trust across the ART.
The Innovation and Planning Iteration and the Agile

Team
During the Innovation and Planning (IP) iteration, the Agile Team often engages in
various activities that are not directly related to delivery but are focused on
improving the team’s productivity and effectiveness. Some typical activities include
the following:
Conduct research on emerging technologies to inform future decisions
Review and refine the team’s processes. Review and adjust the DoD, DoR, Working Agreements, and so
on
Engage in team-building activities to improve collaboration and communication among team members
Develop and improve skills and knowledge through training and education
Collaborate with other teams and Stakeholders during PI Planning
Hold a hack-a-thon to create prototypes or proofs of concept to validate assumptions or explore new ideas
Address technical debt or other areas of improvement that may have been previously identified
The team will want to work closely with the Scrum Master/Team Coach and PO to
identify and determine the activities they are undertaking during the IP Iteration.
Summary
We have discovered the importance of having cadenced-based and synchronized
events for the teams in an ART, regardless of its type (Scrum, Kanban, etc.). These
events serve as checkpoints for the team’s progress and are crucial for effective and
efficient delivery, as well as achieving high performance. We delved into events
such as Iteration Planning, Team Sync, Backlog Refinement, Iteration Reviews,
Iteration Retrospectives, and Iteration System Demos. We looked at both SAFe®
Scrum and SAFe® Kanban Teams. Lastly, we now understand that how the PO,
Scrum Master/Team Coach, and Agile Teams participate in the ART Events
including PI Planning, IP Iteration, PI System Demo, the Syncs.
Further reading
1. Product Owner: https://scaledagileframework.com/product-owner/
2. Scrum Master/Team Coach: https://scaledagileframework.com/scrum-master-team-Coach/
3. Agile Teams: https://scaledagileframework.com/agile-teams/
4. SAFe® Scrum: https://scaledagileframework.com/safe-scrum/
5. SAFe® Team Kanban: https://scaledagileframework.com/safe-team-kanban/
6. Team Flow: https://scaledagileframework.com/team-flow/
7. Team Backlog: https://scaledagileframework.com/team-backlog/
8. Team and Technical Agility: https://scaledagileframework.com/team-and-technical-agility/
9. Derby, E., & Larsen, D. (2006). Agile Retrospectives: Making Good Teams Great. The Pragmatic
Bookshelf.
4
Team Backlog Management

As we have learned, our Product Owner (PO) is responsible for managing and
prioritizing the Team Backlog on a continuous basis; however, there’s more to it
than that. In this chapter, we are going to take a look at the following:
What is the Team Backlog?
User Stories
Estimation, Story Sizing, and Splitting
Flow, Kanban, and Backlog preparation for PI Planning
Let’s get started!
The Team Backlog

The Team Backlog is an ordered list of all the possible work that an Agile Team can
undertake to enhance or deliver the solution. It comprises User Stories, Enabler
Stories, Improvement Stories, and all other work items. Unlike the Iteration
Backlog, the Team Backlog represents a list of wants, allowing for flexibility and
ownership by the team in determining the order and timelines for delivery.
Although the PO is primarily responsible for the Team Backlog, any team member
can contribute an item, help refine it, and prioritize it.
Three primary inputs contribute to the Team Backlog: the ART Backlog, team
contributions, and requests from Stakeholders as depicted in Figure 4.1.
Figure 4.1 – Input sources for a Team Backlog (© Scaled Agile Inc.)
The ART Backlog serves as a crucial contributor as its Features are decomposed
into User Stories and Enablers Stories for the Team Backlog.
The team also contributes to the Team Backlog by capturing stories related to
refactoring, maintenance, or technical debt reduction.
On the other hand, Stakeholders may request work from the team, posing
significant challenges to the PO, which can include dependencies, commitments
supporting the ART and its PI Objectives, feedback from System Demos, or Spikes
and future research.
Additionally, Non-Functional Requirements (NFRs), depicted at the bottom of the

Team Backlog icon, are constraints or restrictions that the team must consider for
each item. To ensure that they are not overlooked, teams may automate testing of
NFRs and include the requirements in their Definition of Done (DoD).
The Iteration Backlog serves as a subset of the Team Backlog and captures the
committed work that the team has agreed to for the current iteration. Throughout
the iteration, the team works systematically to complete and deliver the committed
stories.
PRO TIP
Too often, POs have a backlog that is a single long list that they are constantly reordering, which is
the Team Backlog. Help your POs by creating a Kanban Board that emulates the Portfolio Kanban
Board to track the maturity of the User Stories.
What is a User Story?
We define a User Story as “a short description of a small piece of desired
functionality written from the user’s perspective, implemented by Agile Teams as
small, vertical slices that can be completed in a few days or less” [2]. But what does
any of that really mean?
User Stories evolved from Extreme Programming (XP) [8] as a response to

shortcomings in traditional software development methodologies. XP emphasizes
the importance of collaboration between developers and customers with frequent
feedback and an iterative approach to development. XP identified User Stories to
capture customer requirements. The idea was to write brief informal descriptions of
the user’s need, focusing on what the user wanted to achieve rather than how the
software would accomplish it. The User Stories were typically written on index
cards. The practice has evolved and was adopted by other Agile methodologies.
On the front of the index card, we typically see the description written in what we
refer to as User Story format:
Figure 4.2 – Example User Story Card
This format helps us understand who the request came from and what they want to
accomplish. The why or the reason is the most important part of the User Story as it
gives us the context for the request, how they intend to use it, or the expected
benefit.
PRO TIP
Sometimes, you may find it difficult to phrase the story from a user or customer’s perspective. I find it
helpful to think about the human performing the action. For example, if you need to change a
database to capture a requirement to track hours spent doing volunteer work in the time tracking
database, you could write the following story:
As an employee, I want to be able to submit a request for volunteer hours and get it approved by my
Manager quickly so that I get time off to support my charitable foundation.
The conversation is probably the most important part of writing a User Story so that
the team can have a sufficient understanding of the work to be done. The
conversation between the team, the PO, and Stakeholders ensures alignment on
customer needs, definition of scope, and any potential roadblocks or challenges.
On the back of the index card, we capture the Acceptance Criteria. The
confirmation comes from the set of Acceptance Criteria, sometimes referred to as
AC, that need to be met for the User Story to be considered complete and to be
accepted by PO or customer.
When writing Acceptance Criteria, we look for the following elements:

Condition: A specific requirement or condition that must be met
Action: A description of the action that will be taken to test the condition
Expected Result: A description of the expected outcome or result of the action
Here’s an example User Story and Acceptance Criteria:
Figure 4.3 - Example User Story and Acceptance Criteria
In summary, the index card, the conversation, and the Acceptance Criteria (aka
confirmation) are collectively referred to as the 3Cs of User Stories:
the Card
the Conversation
the Confirmation
STORY FROM THE REAL WORLD

I was working with a team that didn’t have “so that” as part of their User Stories. Let’s take a look at
one of their User Stories:
User Story: As an administrator, I want to be able to remove users from the system.
Acceptance Criteria:
When I navigate to the User Management section of the application, I should be able to see a list
of all users.
Each user in the list should include the user’s name, email address, and user role.
When I select a user from the list and click Delete, a confirmation dialog should be displayed.
If I confirm the deletion, the user should be removed from the system, and the user list should be
updated to reflect the change.
If I cancel the deletion, the user should not be removed from the system, and the user list should
remain unchanged.
Based on the information they had, the team completed the User Story by adding a field to the
database indicating that the user access had been removed. The team thought this was an elegant
solution as it would be easy to restore access if needed without restoring the database from backups.
What the team didn’t know is that the user database was getting unwieldy, and this User Story was
intended to provide a way to clean up old records that needed to be purged. The work they did on
this story ended up as waste simply because they didn’t understand the reason for the request.
They skipped two crucial pieces of the User Story; the “so that” and the Conversation.
Now that we understand the construct of a User Story, let’s see what it takes to
write a good User Story.
We can see that to write a good User Story, we need to consider it from multiple
perspectives and it’s important to involve the entire team. We can also INVEST in
our User Stories.
INVEST is an acronym coined by Bill Wake [4] to describe the attributes of a good
story:
I - Independent (among other stories)
N - Negotiable (a flexible statement of intent, not a contract)
V - Valuable (providing a valuable vertical slice to the customer)
E - Estimable (small and negotiable)
S - Small (fits within an iteration)
T - Testable (understood enough to know how to test it)
You will want to spend time with the teams and the POs to work on writing User
Stories. Include it as part of the Team Retrospectives to discuss stories that were
particularly well written compared to those that weren’t and then challenge the team
as an improvement to write better User Stories in the next iteration.
PRO TIP
There are a lot of resources and User Story writing workshops available on the internet. Depending
on the specific needs and challenges your team is experiencing, don’t hesitate to use them to help
your team improve. Mike Cohn (Mountain Goat Software) has a great workshop titled Better User
Stories: https://www.mountaingoatsoftware.com/training/courses/better-user-stories.
Types of Stories
Within the SAFe® Framework, we differentiate types of stories:
User Stories are our primary means of expressing needed functionality
Enablers Stories are stories that capture the architecture and infrastructure needed to implement User
Stories
You may also see additional types of Enabler stories such as the following:
Refactoring Stories capture activity necessary to improve code or a component’s internal structure or
operation without changing its external behavior
Spike Stories capture activities such as exploration, architecture, infrastructure, research, design, and
prototyping with the purpose of gaining the necessary knowledge to reduce risk, better understand a
requirement, or increase the reliability of an estimate
Technical Debt Stories capture the work necessary to maintain and fix code that was developed quickly
that needs to be reoptimized for the long term
The last type of story we will call out is Improvement Stories. These are stories or
items that we want to ensure we work on in our drive for relentless improvement.
Some teams keep these items in their Team and Iteration Backlogs; others create a
separate backlog. Regardless of where you keep the items, make sure you are
tracking them.
PRO TIP
It often doesn’t make sense to write Enabler Stories in User Story format. It can be clearer to specify
just the what and why. For example, if we need to upgrade a piece of software on a server, it can be
simpler and clearer to state “Upgrade xCode from version 1.2 to 1.3 to fix known security loophole”
than “As a server administrator, I want to upgrade xCode from version 1.2 to 1.3 so that hackers can’t
access our database.”
Bottom line: don’t get overly hung up that every story must be written in User Story format,
particularly if the user is another system or the focus of the story is improving underlying technology
rather than adding new functionality or Features for end users.
Why do we have different types of Stories?

We often get asked this question, or “why do I care if it is an Enabler Story, a User
Story, or Technical Debt?” This simple answer is Capacity Allocation. Capacity
Allocation is the allocation of work by the type of work. While we typically begin
to think about Capacity Allocation for the ART Backlog, we want to understand
how it impacts the Team Backlog as well.
By looking at the different types of stories in our Team Backlog (or Iteration
Backlogs), we can ensure that we maintain a balance between delivering customer
value and improving the system architecture.
If we are only focused on new functionality, then we might not be considering the
long-term sustainability of the solution, which can lead to decreased velocity over
time. Whereas if we are focused on delivering infrastructure, our customers may go
elsewhere if they don’t get new Features and functionality.
PRO TIP
As a Coach, when I first launch an ART, I tend to not worry about what types (Enabler vs. User) of
stories the teams are working on as my primary focus is to have them begin to work together as
teams and in the new Agile ways of working with incremental delivery. I will work with Product
Management, the RTE, and System Architect to review the stories and capture the type during the PI.
In the next PI, we work with the POs and Scrum Master/Team Coach to review the stories that we
added a type to and then let them work with their teams to begin to add the types for the stories we
will be planning in the third PI event.
Incrementally introducing this practice allows real examples and a better overall understanding of
why it’s important and creates an additional opportunity to improve story-writing practices.
Estimating User Stories

Estimating stories is an important activity that allows us to forecast the work to be
completed. The goal of estimating User Stories is to understand the complexity and
size of each story while also accounting for the knowledge and uncertainty the
team may have.
It is important to point out that estimation should be done by the team who is doing
the work, not a Manager, an architect, or even an individual as it negates the
benefits of the team having a shared understanding of the work and improved
accuracy of the estimate by inclusion of all perspectives.
There are different techniques and approaches to estimating User Stories. The most
common are as follows:
Story Points: This technique is based on the relative scale of complexity and effort required to complete a
User Story compared to other User Stories. The team assigns a numerical value (e.g., 1, 2, 3, 5, 8, or 13) to
each story based on its complexity, effort, and risk.
T-shirt sizes: This technique uses t-shirt sizes (e.g., XS, S, M, L, XL) to estimate User Stories. The team
assigns a size based on the level of effort and complexity required to complete a story compared to other
stories in the Team Backlog.
Planning Poker: This technique involves a team discussion and consensus-building exercise to estimate
User Stories. Each team member assigns a numerical value to a story based on their individual assessment
of its complexity and effort, and the team discusses and reconciles any differences to arrive at a shared
estimate.
PRO TIP
We use the modified Fibonacci Sequence to assist in estimating the relative sizes of User Stories or
backlog items. The sequence starts with 1 and each subsequent number is the sum of the previous
two. We continue this pattern until 13, and then we use 20, then 40, and then 100. The full sequence
is 1, 2, 3,5, 8, 13, 20, 40, and 100. By utilizing these numbers, Agile Teams can gauge the relative
size or effort required for completion.
Whichever method you use to estimate story size, it’s essential to consider the
Acceptance Criteria, complexity, and dependencies. To improve your estimates, use
relative sizing to compare User Stories to others you have previously estimated and
assign the size based on the perceived level of effort and complexity.
For example, if your team has estimated a User Story as three points, then a similar
story may also be estimated at three points, regardless of whether the absolute effort
involved is the same. Relative sizing is useful for several reasons, including the
following:
It is faster and less prone to errors than trying to estimate absolute values in hours or days
It allows for more accurate estimation when dealing with uncertainty and incomplete information
It encourages team collaboration and discussion during the estimation process, leading to a shared
understanding of the work to be done
Normalized story points are essential in SAFe. They provide a way to estimate
work relative to other tasks and can be used by teams with no experience with Agile
development or without real data on their performance.
By using this method, normalized story points provide a method for getting to an
agreed starting baseline for stories and velocity as follows:
Give every developer-tester on the team eight points for a two-week iteration (one point for each ideal
workday, subtracting two days for general overhead).
Subtract one point for every team member’s vacation day and holiday.
Find a small story that would take about a half-day to code and a half-day to test and validate. Call it a
“one.”
Estimate every other story relative to that “one.”
Example: assuming a six-person team composed of three developers, two testers,

and one PO, with no vacations or holidays, then the estimated initial velocity = 5 ×
8 points = 40 points/iteration. (Note: Adjusting slightly lower may be necessary if
one of the developers and testers is also the Scrum Master/Team Coach.)
Once a team has some real data about its performance, normalized story points
should no longer be used as they become less accurate over time as the items in the
backlog change. At this point, teams need to switch from normalized story points
and start tracking velocity based on completed work items instead.
Relative estimating is comparing two pieces of work and determining how much
more effort one task requires than another. This allows us to quickly determine how
long it will take us to complete our backlogs without measuring each item
individually, which would take too long and not provide accurate results.
PRO TIP
Too often, I see organizations assuming based on this formula that 1 story point is 8 hours of work,
and then teams begin estimating how many hours it will take to develop (10 hours), test (6 hours),
and deploy (2 hours) the story. Total up the number of hours (18 hours), divide by 8, and round up to
calculate the story points (3 points). Do not fall into this trap.
Story Splitting
When defining what a User Story is, we stated that we should be able to deliver it in
a few days. That means that the team should be able to design, build, test, and
deploy to meet the DoD for that User Story. This often means that the teams must
rethink how they have typically received requirements and broken down the work.
This breakdown does not mean that the team will write a story to figure out what
they are going to do, another story to do the work, another story to test the work,
and yet another story to deploy it. If we are doing that, we don’t have a vertical
slice of the work.
A vertical slice is a User Story that cuts through all the layers of a system from the
user interface down to the data layer. A vertical slice is developed and tested from
end to end, providing a working and usable increment of the system.
To create vertical sliced User Stories for our teams that can be completed in a few
days, we will often need to split our Features and even other stories. There are
several techniques as outlined in Agile Software Requirements [4] that we typically
consider when splitting stories, including the following:
Workflow steps: Stories can be split based on the steps involved in a particular workflow, allowing the
team to focus on one step at a time and deliver value incrementally.
Business Rule Variations: Stories can be split based on variations in business rules, allowing the team to
address specific business rules separately and avoid developing a single, complex story.
Major Effort: Stories can be split based on major effort, allowing the team to focus on the most important
and valuable aspects of a story first.
Simple/Complex: Stories can be split based on simplicity or complexity, allowing the team to work on
simpler parts first and then move on to more complex aspects of the story.
Variations in Data: Stories can be split based on variations in data, allowing the team to address specific
data variations separately and avoid developing a single, complex story.
Data Entry Methods: Stories can be split based on different data entry methods, allowing the team to
focus on each method separately and deliver value incrementally.
Deferred System Qualities: Stories can be split based on deferred system qualities, allowing the team to
address those qualities in separate stories later in the development cycle.
Operations: Stories can be split based on operations (Create, Read, Update, Delete (CRUD)), allowing the
team to focus on specific operations separately and deliver value incrementally.
Use Case Scenarios: Stories can be split based on use case scenarios, allowing the team to focus on
specific scenarios separately and deliver value incrementally.
Break-out Spike: A spike is a short, focused investigation to answer a question or resolve a technical
uncertainty. Stories can be split based on breaking out the spikes into separate stories, allowing the team to
address specific technical issues separately and avoid developing a single, complex story.
By splitting stories, we avoid developing big, complex stories that take a long time
to deliver and may not provide much value. By splitting stories, we focus on
delivering small incremental improvements that add up to significant progress over
time.
CAUTION
Avoid the trap when splitting stories that a User Story originally estimated at 8 points, once split, still
needs to equal 8 points. When splitting User Stories, you will need to re-estimate them independently
of each other and relative to the other stories in your backlog. You might be surprised to discover that
your 8-point User Story is now two 3-point stories.
User Story Prioritization

Achieving continuous value flow requires that the highest-value backlog items are
delivered in the shortest sustainable lead time and in the right sequence. The PO
enables this by regularly ordering backlog items according to their cost of delay and
communicating that sequence to the team during Backlog Refinement and Iteration
Planning. So, when we talk about Team Backlog prioritization, because the team
inherits the prioritization from the Features prioritization, we are effectively
sequencing the work, but thereafter we will refer to it as prioritization.
Prioritizing the backlog can be particularly difficult for a PO as they have to

balance all of the following: the needs of the Stakeholders and customers, the
priority of Features versus the Enabler Features, Architectural Runway and
Technical Debt, Milestones and deliverables, and the list could go on.
When we prioritize the Team Backlog, we create focus and alignment and receive
the following benefits:
We ensure we deliver the most valuable items first
We create a roadmap for our team with clear direction on what to work on next
We are able to make better decisions and understand trade-off costs when priorities change, or new
requests come in
We see improved efficiency as we end up eliminating unnecessary work, reducing waste
When prioritizing your backlog, it may be helpful to define your prioritization

criteria. Consider what factors are most important to your team. This may include
Business Value, Feature prioritization, risk mitigation, dependencies, and
sequencing.
MoSCoW is another common technique where you assign the story to one of four
categories:
Must have
Should have
Could have
Won’t have
You could consider using this in conjunction with other techniques such as Story
Mapping.
Regardless of the technique you use, remember that prioritization is an ongoing
process and requires continuous communication and collaboration between the
team and Stakeholders. It’s important to regularly review and adjust your Team
Backlog to ensure that you’re delivering the most valuable work first.
Getting your Team Backlog to Flow

Managing the Team Backlog with hundreds of stories requires a lot of work and
effort. By capturing the Team Backlog in a Kanban system, you can create
alignment and visibility, which makes managing it much simpler. The Team
Backlog Framework article suggests using a similar structure to the Portfolio
Kanban. In Figure 4.4 is another example for your consideration:
Figure 4.4 – Example Team Kanban Board
When designing your Team Backlog Kanban board, it is crucial that you can
quickly and easily identify which items are ready for the team to tackle, prioritize
them effectively, and visually represent the current status of the backlog items. It is
also essential to consider establishing Work-In-Progress (WIP) limits for each state
and developing policies for when an item can be pulled into the next stage. The
team should define and adjust the WIP limits and policies as necessary to ensure
that work flows smoothly through the system and evolves over time to meet their
evolving needs.
Kanban Team Stories

In Kanban, we typically use the term work item rather than story. However, in
SAFe®, we understand that teams should have autonomy, but they are not
autonomous. Therefore, wherever we can simplify the language to a common
taxonomy, it makes it easier to communicate with other teams. To that end, in
SAFe® Kanban, we also use the same story vernacular.
Figure 4.5 – SAFe® Team Kanban method overview (© Scaled Agile, Inc.)
It is much easier to calculate flow metrics when work items are roughly the same
size and we always want to work in small batches. Make sure you have clear
policies for the Definition of Ready (DoR) and the DoD and that you’re always
comparing apples with apples.
Team Backlog preparation for PI Planning

Having a Team Backlog that is ready for PI Planning is important in that it allows
the team to focus on dependencies, ensuring alignment with the Vision,
architecture, and Roadmap. They have the time and space to collaborate with other
teams, create plans with high confidence, and draft PI Objectives at the event.
Each team will be different in the amount of preparation needed for PI Planning.
We have found success when the teams have identified and roughly estimated the
stories for the next PI ahead of PI Planning. These stories (except those that will
likely be worked on in the first iteration) aren’t well refined and wouldn’t meet the
DoR.
You will want to ensure that your teams don’t go into PI Planning with a fully
refined and planned backlog, knowing what stories will go into which iterations and
then spend the event staring at each other. You may even find that they become
overly attached to their plans and resistant to changing them when necessary, based
on feedback from other teams and Stakeholders. It’s important for teams to strike a
balance with the amount of preparation and to be open to feedback and adjustments.
Summary
We discovered that the Team Backlog is a collection of work that the team can
undertake, which includes User Stories and Enablers. The PO is primarily
responsible for it, but any team member can contribute to it. We learned that User
Stories are small pieces of desired functionality that our Agile Teams implement
within a few days. Acceptance Criteria are the conditions the story must meet to be
considered complete.
We also took a look at the importance of estimating User Stories, which is done by
the team, and outlined several techniques for splitting and prioritizing User Stories
with reminders to always factor in relative sizing. Lastly, we took a look at Kanban
Team Backlogs, and how to prepare for PI Planning.
Let’s now take a look in w at the events the teams execute.
Further reading
2. Stories: https://scaledagileframework.com/story/
3. Enablers: https://scaledagileframework.com/enablers/
4. Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and
the Enterprise. Addison-Wesley, 2011.
5. Refactoring: https://scaledagileframework.com/refactoring/
6. Spikes: https://scaledagileframework.com/spikes/
7. Design Thinking: https://scaledagileframework.com/design-thinking/
8. Extreme Programming: https://en.wikipedia.org/wiki/Extreme_programming

5
Team Iteration Events

Regardless of the type of team you have, the events that your team holds on a
regular and synchronized cadence can’t be overlooked. Without these checkpoints,
the teams will struggle to effectively and efficiently deliver and will struggle to
reach high performance.
In this chapter, we will look at each of the team events, including the following:
Iteration Planning
Team Sync
Backlog Refinement
Iteration Reviews
Iteration Retrospectives
This chapter isn’t just for teams executing as a SAFe® Scrum team. We will also
look at SAFe® Kanban Team events:
Planning
Delivery
Team Sync
Retrospectives
We will also take a look at key artifacts that will help ensure team success:
Definition of Done
Definition of Ready
Working Agreements
Let’s jump in and get our teams started with Iteration Planning.
SAFe® Scrum Team Events

Due to the extensive content available from SAFe® regarding Scrum on how to
execute and facilitate the events, in this section, we will share our key takeaways,
experience, and tips, rather than how to execute or facilitate each event.
We encourage and recommend you visit SAFe® Studio (formerly known as the
community pages) and download the following Facilitator Guides from SAFe®
Studio Toolkits:
Facilitator’s Guide to SAFe® – Iteration Planning
Facilitator’s Guide to SAFe® – Team Sync
Facilitator’s Guide to SAFe® – Backlog Refinement
Facilitator’s Guide to SAFe® – Iteration Review
Facilitator’s Guide to SAFe® – Iteration Retrospectives
Iteration Planning
The first event in an iteration is Iteration Planning, which is facilitated by the Scrum
Master/Team Coach (SM/TC). During this event, team members refine stories
already defined in PI Planning to meet the Definition of Ready. The maximum
timebox for this event is typically four hours for a two-week iteration, but it is
rarely needed. There is a law of diminishing returns, and spending more time
beyond a certain point does not increase accuracy. All team members, including the
Product Owner (PO), are present during Iteration Planning.
Backlog preparation
It is important to ensure that the PO attends this event with a well-prepared Team
backlog, which should include any work carrying over from the previous iteration.
The PO has the decision-making power, from a prioritization perspective, to
exclude carry-over work from the next iteration. However, there are tradeoffs that
should be considered, such as the criticality of the work, sequencing, dependencies,
and the cost of task switching.
Capacity
Too often, we see teams spend upward of 30 minutes figuring out their capacity for
the iteration, trying to calculate for an hour here and there or being unsure of their
schedule. This activity should take no longer than 5 minutes. Coach the team that
they are responsible for knowing what their schedules will be for the next two
weeks. You may want to consider not adjusting capacity for anything less than 4
hours as the impact to the Capacity will be negligible.
Story selection, analysis, and estimation

Backlog preparation ensures this activity goes smoothly. Time spent on Backlog
Refinement is regained in Planning. Since we have a prepared Team Backlog,
simply start at the top of the backlog, review the story, get any additional
clarification, verify the points are still accurate and, with the team’s consensus that
they can complete this in the next iteration, move the story into the Iteration
Backlog.
Repeat this process, ensuring you don’t exceed the agreed capacity, and that, as you
approach that capacity, the team agrees they can complete all the work that is
currently in the Iteration Backlog. This also means that all stories will meet the
Definition of Done (DoD).
It is often helpful to have the DoD readily available for the team. If you have a team
room, keep it posted; if it’s virtual, ensure that all team members know where it is
and can access it regularly.
It’s important to call out that the team does not have to plan to capacity. For
example, if the team capacity is 25 points and the team reaches an agreement at 23
points that this is the most work they can commit to, there is no obligation to find a
couple of 1-point stories or a 2-point story from farther down the backlog for the
team to complete.
Additionally, the team could also decide that while their capacity is 25, they want to
attempt to do 26 points this iteration based on the stories they have selected. The
consensus of the team and their commitment and agreement are more important
than meeting or exceeding the estimated capacity.
Tasking
Not all teams create tasks for their stories. However, we find this practice helps
many teams initially as they start to mature. It helps the team to understand the
work required to deliver the story. Encourage the teams to think beyond tasks of
develop, test, and deploy. Tasks don’t have to be overly detailed; they could be
something as simple as “Write API to retrieve XYZ data.” Encourage the teams to
keep the descriptions short.
There is a balance with tasking, with a general rule of thumb being a task should be
able to be completed in 4 hours or less. The balance is that we want to prevent all of
our tasks taking 15 minutes.
Use tasks to identify important steps that we don’t want to miss. Some teams will
create tasks for key items in the DoD.
Ultimately, the value of tasking creates a shared understanding of the work among
the team members as everyone can see what work needs to be done and how it fits
into the overall story. Additionally, tasking may bring to light something that was
overlooked, allowing the team to adjust their Iteration Plans before commitment.
Iteration Goals
Iteration Goals are often overlooked by many teams; however, they play an
important part as this helps to keep the team focused.
PRO TIP
A practice you might consider is that your Iteration Goals are “tweets” with hashtags and social media
lingo. We then use those tweets to communicate to the other teams what is being worked on. Here’s
an example:
Enhance the login process by implementing MFA via text. #Login #MFA #TeamAvengers
You can even create standard hashtags to allow you to quickly search your communication tools
(Slack, Teams, etc.) for them. One organization created hashtags for each of its Features. Be
creative!
Commitment
This is the exit criteria for Iteration Planning. There are numerous ways to get the
commitment, including Fist of Five, verbal agreement, or a simple yes/no vote.
Regardless of how you do it, be sure that everyone participates, and their concerns
are heard.
Team Sync
The Team Sync (formerly the Daily Stand-Up or DSU) is a 15-minute meeting with
a Meet After to resolve or discuss any items. It is important that everyone in the
team participates and that it does not become a status meeting.
The Team Sync is important for the team to stay aligned with the work that is
occurring to deliver the stories they committed to in the iteration.
PRO TIP
As a Scrum Master/Team Coach, you want to make sure everyone gets a chance to speak and
actively participate in the event. A simple technique to pass around a speaking token (e.g., a ball or a
baton); when the token is passed (or thrown) to you, it is your turn to provide an update.
Encourage the team to actively talk to and even move the tasks or stories they have
been working on to the appropriate column on the board during the Sync. Track and
ensure items aren’t stuck in a state for too long (more than a day). Some teams even
discuss when they expect to have a particular item done and capture that in the tool
as well.
The Meet After is a timebox that allows for the team to further discuss any issues or
topics that came up during the Team Sync. Ensure that Meet After items are
captured and visible so team members can quickly determine whether they need to
participate.
Backlog Refinement
Backlog Refinement is the opportunity for the team to identify and address
potential obstacles and dependencies, estimate the stories, and provide input into
the sequence and importance of the stories.
PRO TIP
The biggest mistake I see teams make is not dedicating enough time to Backlog Refinement. Too
often, the first practice I put into place with teams (and ARTs) is mandatory Backlog Refinement of 2
hours per week. I recognize that may seem a bit extreme; however, what teams quickly discover is
the time spent on refinement leads to reduced time spent on planning, improved predictability, and
overall improvement in morale.
We encourage a rolling-wave approach to Backlog Refinement, where we track

stories that have already been refined and do a quick check for any adjustments to
those stories before working down the Team Backlog to stories that need additional
information and conversations.
Be sure to capture relevant information from the conversations during Backlog

Refinement with the stories, including any drawings, diagrams, and so on.
With the rolling-wave approach, teams should eventually be able to get their
backlogs to have a PI plus 1 Iteration worth of work at decreasing levels of
readiness. Here is an example you may want to consider, noting there are no hard
guidelines and that it will take the teams some time (usually at least a PI) to get
anywhere near these recommendations:
Next Iteration 95%+ Stories meet Definition of Ready
2 Iterations 85% of Stories meet Definition of Ready

out

out

out
5 Iterations Stories have descriptions and most Acceptance Criteria are

out defined
6 Iterations Stories identified, some description, and Acceptance Criteria

out
Iteration Review
The Iteration Review, sometimes called the Iteration Demo, is important for the
team to be able to present their work to key Stakeholders, and also to assess their
progress toward their PI Objectives. Too often, that assessment by the team is
missed or skipped.
We have experienced numerous Iteration Reviews, both good and bad. We

recommend one of two patterns when looking at all the stories the team completed.
Either review each story on a story-by-story basis in backlog order or, if there is a
natural sequence to show the stories, you could follow that model. A pattern we
recommend staying away from is person-by-person. This is a common format when
we have individuals rather than the team working on a story.
Remember that the Iteration Review is the opportunity to review ALL the stories
the team worked on, not just those that are finished. Ensure that the team takes the
opportunity to discuss and show the work that was completed on stories that aren’t
done as well. Outlining what work remains helps the team continuously improve
and can serve as input into the Iteration Retrospective.
Lastly, this event is also an opportunity to discuss the Team Backlog and adjust
based on feedback from the Stakeholders and the team. Ensure that the Product
Owner and team capture any adjustments for inputs into Iteration Planning or
Backlog Refinement.
Iteration Retrospective
The Iteration Retrospective is the capstone to the iteration. It reinforces the SAFe®
Core Value of Relentless Improvement.
Ensure that the team understands the importance of the retrospective and that it
doesn’t become stale. Change up the retrospectives the teams participate in. The
book Agile Retrospectives: Making Good Teams Great [9] is a great resource for
ensuring effective retrospectives.
Ensure that the improvement items the team identifies are captured; many teams or
ARTs will use an Improvement Backlog or capture it as an Improvement Story.
At the beginning of each retrospective, review the improvement items from the last
retrospective to determine their efficacy and if the team wants to continue or stop
them.

We cover the Iteration System Demos in detail in Part 2; however, we wanted to
call out that the teams attend and may participate in them. Ensure that the teams
have this event on their calendars and attend. It’s a key event for measuring
progress and maintaining alignment across the ART.
SAFe® Kanban Team Events

Kanban, a concept that originated in Japan, has become a widely used production
planning framework across industries worldwide. In the early 1940s, Toyota, a
Japanese automotive company, introduced Kanban as a means of improving
inventory management, reducing waste, and optimizing workflow. The word
“Kanban” translates to “visual signal” or “card,” referring to the visual cues used to
manage production and inventory. Its principles involve creating a balance between
supply and demand, reducing overproduction, and Continuous Improvement. Since
its inception, Kanban has evolved beyond its original usage in manufacturing
sectors and has been adapted to various fields, including software development,
healthcare, and education. Its simplicity and effectiveness have made it an essential
tool for many organizations seeking to streamline their work processes.
SAFe® is a flow-based system, and we use Kanban extensively across all levels to
visualize our work. In Figure 5.1 is an example Kanban Board for a team. On the
far left, we have the funnel where we capture all our ideas. Each column reflects the
steps that we go through to finish an item in our backlog.
Above each column are numbers representing the Work-In-Progress (WIP) Limits.
As the name suggests, this creates a pull-based system by restricting the items in
each column. In doing so, we are encouraged to stop starting and start finishing.
In Figure 5.1, we can see that Integration and testing has a WIP Limit of 6, and
there are 6 stories already in that column. Enforcing a WIP Limit means that we are
unable to move a story from Building until we’ve created room for it. Without a
WIP Limit, our developer would probably just pull another story and increase the
amount of unfinished work in the system, which we see as operational debt.
However, in this case, we would encourage developers to help out with the
Integration and testing, thereby moving stories closer to completion.
Figure 5.1 – An example team Kanban system (© Scaled Agile Inc.)
PRO TIP
For the most part, Figure 5.1 will be a good starting point. However, you will need to customize the
board to reflect the steps in your processes. When I implement Kanban in some organizations, I find
that leaders, or sometimes PMOs, have mandated that everyone use the same states on their boards
to make reporting easier.
You will need to think about how to integrate with the Features on the ART Kanban, but make sure
that it represents the work in a way that is meaningful to the team.
Planning
Planning for SAFe® Kanban Teams differs slightly from SAFe® Scrum Teams as
they focus on continuous flow. Often, Kanban Teams use this approach because
they struggle to plan two weeks in advance. To this end, Kanban Teams often meet
once a week or as needed to plan for the week ahead and address dependencies and
bottlenecks.
Although we want teams to have autonomy, they are not entirely autonomous.
Therefore, it is essential that Kanban Teams share their planned work visibly. They
usually display their work on a Kanban board, either physically or digitally.
As part of the ART, they also share their progress toward their PI Objectives by
publishing their Iteration Goals and progress on dependencies so that they are
aligned with the rest of the ART.
Team Sync
Like most Agile Teams, Kanban Teams get together regularly to ensure their work
is on track. Teams often meet daily like a Scrum Team, although the Team Sync for
a Kanban team is more akin to an Iteration Review. There is always a trade-off
between encouraging collaboration and disrupting time in the zone.
Teams usually synchronize their syncs with the rest of the Train. It is common to
start and end Iterations mid-week. Post-pandemic, people are in the office more
from Tuesday to Thursday and are more productive when face-to-face.
The Team Sync covers a lot of the same topics we would typically talk about during
a Sprint Review:
1. Flow Metrics and Blockers
2. Review and Accept Stories
3. Upcoming Dependencies
4. Progress toward Iteration Goals and PI Objectives
PRO TIP
I often see Team Syncs going on for far too long. I once Coached a team that struggled to keep their
syncs below an hour! Make sure you keep your updates to the point and focus on what the other
team members need to know. Come prepared and let people go as soon as possible.
Retrospective
Kanban Teams also prioritize retrospectives to ensure Continuous Improvement
over time. During these retrospectives, team members reflect on their recent work
and identify ways to improve their processes, collaboration, and outcomes.
Here are some key elements that contribute to a good retrospective (note these
apply to Scrum Teams as well):
Psychological Safety: The retrospective should foster an environment where team members feel safe to
express their opinions, share their experiences, and raise concerns without fear of judgment or reprisal.
This encourages open and honest communication.
Focus on Learning: A good retrospective emphasizes learning from past experiences. It encourages the
team to analyze both successes and failures, identifying what worked well and what could have been done
better. The focus should be on Continuous Improvement rather than blaming individuals.
Clear Objectives: Define clear goals and objectives for the retrospective. It could be to identify areas of
improvement, celebrate successes, address specific challenges, or enhance team dynamics. Having a clear
purpose keeps the discussion focused and ensures meaningful outcomes.
Structured Format: Utilize a structured format or technique to guide the retrospective. There are various
frameworks available, such as the Start, Stop, Continue method, the Mad, Sad, Glad technique, or the 5
Whys approach. A structured format provides a framework for discussion and helps prevent the
conversation from becoming unfocused.
Inclusive Participation: Ensure that all team members actively participate and have a chance to
contribute. Encourage even the quieter or more introverted individuals to share their thoughts and ideas.
This inclusivity promotes a sense of ownership and collaboration within the team.
Actionable Insights: The retrospective should result in actionable insights and concrete steps for
improvement. Encourage the team to generate practical ideas and create a plan of action to implement
changes. Assign responsibilities and set deadlines for follow-up actions.
Follow-Up and Accountability: Ensure that the actions identified in the retrospective are tracked and
followed up on. Hold team members accountable for their commitments and provide support or resources
as needed. Regularly revisit the retrospective outcomes to assess progress and make further adjustments.
Continuous Improvement: A good retrospective is not a one-time event but part of an ongoing process.
Encourage the team to reflect regularly, ideally after every significant Project or iteration. Emphasize the
importance of Continuous Improvement and foster a culture of learning and adaptation within the team.
PRO TIP
One of the best retrospectives I ever participated in was with a small team working on a top-secret
Project in an innovation lab. We were under tremendous pressure from senior leaders to prove the
value of a proposition, so time was of the essence.
During the retrospective, we brainstormed ways to improve the team. When we got to one of the
SMEs, he said, “Guys, this Project is making me ill. I haven’t slept in weeks, and I don’t think I can do
it anymore.”
What happened next was a great example of how a team can work together. Not only did we
acknowledge that it wasn’t okay for him to feel that way but we immediately came up with tangible
solutions for improving team dynamics. We didn’t like that we had reached that point, but we
celebrated that our SME had the psychological safety to be honest about how he was feeling.
That turned out to be one of the best teams I’ve worked with, not only because of the genuine
relationships we formed but also because we went on to develop a product that generated millions in
revenue.
Focus on people, and the rest will take care of itself. It is essential to have tangible improvements
from a retrospective; otherwise, people will start to see them as a waste of time. Remember that
every team is unique, and what works for one may not work for another. Adapt the retrospective
process to suit the team’s preferences and needs and be open to experimenting with different
techniques or approaches to find what works best.
Team artifacts
There are several key artifacts that we wanted to make sure we didn’t overlook. You
may have others that you regularly incorporate into your teams as well; just keep in
mind the Agile Manifesto Value in that we find Working Systems to be more
important than Comprehensive Documentation.
Definition of Done
The Definition of Done (DoD) is the team’s checklist to ensure that the work can be
considered complete. Team DoDs evolve over the life of the team and often with
the maturity of the Continuous Delivery Pipeline.
We encourage the team to regularly review the DoD (the Retrospective is a prime
opportunity) and ensure that the DoD is accessible, visible, and used by the team
for the stories they complete.
PRO TIP
Too often I see new teams have a DoD that includes something to the effect that the story is
deployed to production. This leads to teams ignoring the DoD and subsequently, we see quality
issues creep into the system. Leverage the Scalable Definition of Done to help teams, ARTs, and
Leadership understand what should and shouldn’t be included at the different levels or stages.
Definition of Ready
The Definition of Ready (DoR) helps the team mature its backlog. This checklist
should be short and outline the criteria a story must meet before it can be pulled
into the iteration for a Scrum Team or worked on by a Kanban Team.
Some items teams typically include are as follows:

The Story has clear Acceptance Criteria
Story dependencies have been identified
The Story has been estimated
The Story has been reviewed with the team and pending questions have been answered
You may often find that if a team is struggling to deliver all the stories they commit
to in an iteration, spending some time creating a DoR or refreshing the DoR, which
can drive improvement.
Working Agreements
Working Agreements, sometimes called team norms or charters, establish a shared
understanding of expectations for team members on how they will work together.
This artifact can help the team get to the high-performing stage quickly.
The Working Agreements help reduce inefficiency by clarifying how the team
should communicate, collaborate, make decisions, and resolve issues. Working
Agreements promote transparency, respect, trust, and accountability within the
team.
Ensure that you regularly review the team Working Agreements and add new items
to the Team’s Working Agreement and remove items that are no longer necessary.
Summary
We learned about the importance of regular and synchronized events within a team,
regardless of type. These events serve as checkpoints for the team’s progress and
are crucial for effective and efficient delivery, as well as achieving high
performance. We have explored various team events, such as Iteration Planning,
Team Syncs, Backlog Refinement, Iteration Reviews, Iteration Retrospectives, and
Iteration System Demos. We have also looked at key artifacts that contribute to a
team’s success, including the DoD, DoR, and Working Agreements.
Further reading
1. SAFe® Studio https://community.scaledagile.com
2. SAFe® Scrum https://scaledagileframework.com/safe-scrum/
3. SAFe® Team Kanban https://scaledagileframework.com/safe-team-kanban/
4. Iteration Planning https://scaledagileframework.com/iteration-planning/
5. Iteration Review https://scaledagileframework.com/iteration-review/
6. Iteration Retrospective https://scaledagileframework.com/iteration-retrospective/
7. System Demo https://scaledagileframework.com/system-demo/
8. Iteration Goals https://scaledagileframework.com/iteration-goals/
9. Derby, E. & Larsen, D. (2006). Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf.
11. Scalable Definition of Done: https://scaledagileframework.com/built-in-quality/

Part 2: Agile Release Trains
Agile Release Trains, or ARTs as they are often referred to, are simply a collection
of teams or a team of teams working together to deliver a solution. This
understanding is critical as you begin to organize your Agile Teams.
In this part, we will cover the following:

Chapter 6, Agile Release Trains
Chapter 7, Release Trains Day to Day
Chapter 8, ART Backlog Management
Chapter 9, Iteration Events for the Train
Chapter 10, PI Events

6
Building the Agile Release Train

Launching an Agile Release Train (ART) can be a daunting task. There are
numerous things to consider when building your ART, including the following:
Its structure and composition
Why it’s important to align your ARTs to Value Streams
Key roles in the ART
What a Troika is, who is on the Troika, why the Troika is important, and the influence needed for success
What a System Team is
We will take a look at each of these areas and help you understand some key
considerations, regardless of whether you are launching your first ART, recovering
an ART, or maturing an ART.
Why your Train isn’t your department

One of the first mistakes many organizations make when standing up an ART is
they align it with their existing organizational structure. After all, our organizations
have evolved into a system that works. We have an organizational structure that we
continually refine (reorganize) to make sure we are optimally aligned. However,
have you stopped to consider the reason we seem to be in a constant state of re-org?
How should we build our ART?

Let’s start by defining what an ART is. An ART is a virtual organization of 5 to 12
long-lived Agile Teams that consist of 50 to 125 people working to deliver a
common solution on cadence. Successful ARTs are aligned with a shared mission or
vision.
Now that we know what an ART is, we need to determine whether we need one.
A common mistake that many organizations make is assuming that they “need” an
ART, and they stand one up for every Project they undertake. The organization
identifies the Project and then finds the “resources” to work on that Project.
With SAFe®, we take a different approach and create our teams and ARTs for our
Development Value Streams; see Chapter 12 for additional information. This
naturally allows us to align the ART so that it works with a specific domain and
take work to the ART rather than standing up and tearing down ARTs as Projects
start and stop.
Cross-functional
When creating our ART, the intent is that our ART can support itself. This means
we want our ART to be organizationally cross-functional. We will need people from
all parts of the organization, including Business, Engineering, Testing, Operations,
Security, Compliance, and so on. We often encounter situations where these parts of
the organization typically don’t work together daily and have their own hierarchy
and even culture.
As we launch our ART, we likely won’t have the ART composition correct on our
first attempt and that is OK – it will evolve. The intent is to minimize hand-offs and
subsequent delays. Our non-siloed cross-functional teams will drive this in
conjunction with a strong Continuous Integration/Continuous Delivery (CI/CD)
pipeline with DevOps support. Chapter 7 has additional information on CI/CD and
the Continuous Delivery Pipeline (CDP).
Note that even cross-functional ARTs will still need to interface with the rest of the
organization and will need a System Team and will likely have dependencies on
Shared Services Teams.
Dedicated and long-standing

Our ART should have dedicated team members. This means that the individual is
allocated to the ART and their team 100%. We want to minimize task switching and
keep teams together for as long as is reasonably possible.
PRO TIP
If I had to pick one battle to win when setting up an ART, it would be having dedicated team
members. Too many times I see organizations allocate a person 25% to the ART. 25% of the time,
they attend the ceremonies and are left with an hour or two of actual time to work on stories. How
much of a story can you realistically get done in 1 or 2 hours?
Communicative
Our ART needs to be able to communicate freely and effectively across
organizational boundaries. People from Business need to be able to regularly talk
with people from IT and subsequently people in Operations and people in
Marketing and throughout the organization. This communication must flow
organically without you having to work up and down the organization chart.
CONWAY’S LAW
Conway’s Law [1] states that an organization’s output is directly related to how it communicates
internally. What we have discovered is that these communication hierarchies are often significant
barriers to flow. Organizations with successful ARTs have figured out the nature of a Dual Operating
System and understand that our ARTs should be built around our social structures (how we talk and
chat and work with each other informally) as opposed to our organizational hierarchies.
Maturity
ARTs mature and evolve. ARTs, like teams, follow Tuckman’s model of Forming,
Storming, Norming, and Performing, as explained for teams in Chapter 2. As a
Coach and/or Release Train Engineer (RTE), you want your ART to become high
performing. One thing to keep in mind is that the ART will mature more slowly
than a team will due to its size.
PRO TIP
I liken the maturity of an ART to that of a child; each PI is like a year of child development. When that
ART is in its first PI, I liken it to a newborn baby. It needs constant care, feeding, and changing.
The second PI is like a 1-year-old; maybe a little less care, but it still needs to be fed. It’s maybe just
starting to crawl.
The third PI is like having a 2-year-old with constant “Why” questions.
By the time we get to the fifth PI, the ART is like a kindergartener. It can get dressed on its own, but
its clothes are likely mismatched and its shoes are on the wrong feet.
It’s about 2 years in, around PI 9 or 10, that the ART can largely take care of the daily activities with
help and support for the big items.
It takes time for ARTs to grow and mature. The longer you keep the ART stable, the better it will
execute and deliver.
When our ARTs aren’t communicative, cross-functional, dedicated, long-standing,

and mature, they are inefficient. The ART will be plagued by corporate politics, it
will grow and shrink with each budget cycle, and the churn and overhead of
standing up and down ARTs in the same fashion as Projects are just wasteful.
How identifying the Correct Value Stream

impacts the ART
Pause for a moment and ask yourself, what is the product or the solution that my
company delivers? Now, consider for a moment, are the teams and ARTs that
you’re working with directly supporting that product? Is everybody aligned to
ensuring that the product is successfully delivered every day? Oftentimes, you will
find that a company’s core competence is X, which isn’t necessarily what the teams
and trains are attempting to build.
Let’s consider an Airline company. Its product is flying passengers from Point A to
Point B. It also has a mobile app and a website that lets users book tickets, change
reservations, check in, and so on. Like most companies, it is hierarchically
organized to support flying passengers. However, when it embraced the concept of
the Dual Operating System and socially aligned its ARTs with the products it was
creating, such as a mobile app versus a plane maintenance scheduling application,
they were inherently aligned with their Value Streams.
PRO TIP
As a Coach, I recommend leveraging the SAFe® Value Stream Identification Workshop to identify
your Value Streams and ARTS. This is an invaluable resource available to SPCs in good standing.
How should we identify our Value Streams

and what happens if we don’t?
Simply put, we should align our ARTS with the products or solutions that we are
attempting to deliver, which, in turn, typically align with our Development Value
Streams.
SAFe® recommends we start by identifying our Operational Value Stream and then
determine which systems support it. Next, we identify the Development Value
Streams that support those systems and subsequently identify the ART(s) for them:
Figure 6.1 – Example Value Streams and ARTs identified in the Value Stream Identification
Workshop (© Scaled Agile, Inc.)
When we don’t align closely with our Development Value Streams, then our ability
to deliver work continuously and on cadence is severely hampered. The teams will
often be hampered by dependencies and/or will duplicate architectural efforts and
have limited learning.
The smaller the organization, the less this will impact you as your scale is smaller.
If I only have one ART or even two ARTs, then the impact of misalignment is
significantly smaller than if there were 15 ARTs.
PRO TIP
If you can’t re-align your ARTs, strive to reduce and minimize the delays in your system. Leverage
Value Stream Mapping to identify your biggest bottlenecks and start there.
Our primary intention is to effectively flow work through our system. It’s like water
flowing through a pipe. If we have a straight, clear pipe with the proper angle,
water flows easily. Every bend, change in elevation, or even build-up slows down
the flow. We want to work to eliminate the blockages, bends, and improper
elevation.
Ultimately, we won’t get the benefits of Agile that we are looking for without
proper alignment. If we don’t align our ARTs with the Development Value Streams,
we will continually be challenged with dependencies, lack of overall alignment,
duplication of effort, and significant challenges in the portfolio area, particularly
when it comes to prioritizing the Portfolio Backlog and portfolio funding and
budgeting (see Chapter 13).
PRO TIP
Value Stream Identification and Value Stream Mapping are two separate activities. Value Stream
Identification is used to identify what your Value Streams are and then identify what teams and ARTs
are necessary to support the identified Development Value Streams. See the Value Stream
Identification Workshop available in the SAFe® toolkits.
Value Stream Mapping involves looking at the steps in your Development Value Stream. SAFe®
covers this activity in the DevOps class and has a Value Stream Mapping Workshop Toolkit that is
available.
Release Train Engineers, Product

Management, and the System Architect –
Senior Leaders
An empowered high-functioning team consisting of your Release Train Engineer
(RTE), Product Management, and System Architect is critical to the success of the
Agile Release Train. We often refer to this group as the Troika; our group of three
responsible for the success of the ART.
The Troika
What is a troika (/’troik’/)?
“A group of three people working together, especially in an administrative or
managerial capacity”
– Oxford Dictionary
Our Troika comprises the Release Train Engineer, Product Management, and
System Architect who collectively lead and guide the ART. Together, this group
ensures the success of the ART by making sure the teams are developing the right
things, at the right time, at the right level of quality, and with the right alignment.
In a successful ART, the influence of the Troika is critical. Collectively, they

influence the entire organization.
We look to Product Management to influence the following:

Leaders to undertake an Epic
Teams to deliver the product
Product Owners to execute the vision
Architecture to push technology forward
We look to the System Architect to influence these aspects:

Alignment across ARTs and the potential organization
Collaborate with Release Management
Participate in System Demos explaining the value of Enablers and Non-Functional Requirements (NFRs)
Participate/lead an Architecture Sync
Drive the System Team and ART teams in creating an Architectural Runway
Alignment with the Enterprise Architectural Vision
We look to the RTE to influence the following:

Alignment across the teams and organization
Participation of leaders in key events
Continuous collaboration, growth, and maturity of the teams
Ensuring the teams and ART have what they need to be successful
Removing blockers and impediments
If the Troika members lack sufficient influence and even authority, you will quickly
find that the progress of the ART will grind to a halt.
The decisions that this group makes likely have long-term impacts on the
organization. They need to be involved not only in the day-to-day work of the
teams but be part of the decisions that are being made strategically about the
business in general.
PRO TIP
Avoid the mistake that many organizations make in assuming that these roles are staff-level roles.
Successful organizations recognize their value and often, these roles are filled by Director-level roles
and above.
A defined and sufficiently powerful Troika is critical to an ART’s ability to deliver
high-quality, committed value. Each member of the Troika has an important role in
ensuring the success of the ART and it takes work and effort from all three roles for
success.
PRO TIP
As a Coach it is important that you ensure the success of the individuals in these key roles. You may
want to help identify and recommend individuals for each role.
Let’s take a deeper dive into each of the roles on the Troika, starting with the RTE.
The Release Train Engineer (RTE)

The RTE is like the quarterback of your football team. He or she is calling the
plays, getting the players aligned, and making sure that the ART is scoring goals by
delivering value.
There is a perception that the RTE is just the Scrum Master/Team Coach for the
ART. While this is technically true, the RTE role goes beyond the expectations of a
typical Scrum Master/Team Coach. The RTE is the ultimate Servant Leader. A
successful RTE often has prior management experience and domain knowledge.
When identifying an RTE, look for someone who can do/has the following:
Create an environment of respect and mutual influence
Understand and empathize with others
Strong listening skills
Excels in problem identification and decision-making
Coaches and leads
Appreciates others and leverages support
Is very organized and diligent with follow-up
Thrives in challenging situations and with constant change
Has the ability to communicate at all organizational levels and audience as appropriate
Can anticipate what is coming down the tracks
The RTE often interfaces not only with the ART but also with Stakeholders,
customers, and the executive leadership in the organization. The demeanor, level-
headedness, and eloquence of the RTE are critical.
There are many different career paths successful RTEs follow, but most individuals
come with backgrounds in management and were former Program or Project
Managers, Scrum Masters/Team Coaches, or Lean-Agile Coaches.
The RTE needs to be able to command a room and not be intimidated by large
groups of people. The RTE needs to be witty and entertaining and the life of the
party, particularly for PI Planning.

I once worked with an RTE who was new to the role. She was an amazing Scrum Master and when
the opportunity arose for her to become an RTE, she was the natural selection. She was knocking it
out of the park when it came to handling the day-to-day aspects of the ART, but when the first PI
event occurred, where she was in front of 150 people and leading the show, she froze. She looked
down at her feet and notes, barely made eye contact with the audience, and spoke in an extremely
monotone voice. One of her fellow Scrum Masters took pity and helped facilitate the remainder of the
PI event.
I began working with her shortly thereafter and we discussed her fears and challenges with being in
front of a large group of people. We worked on this over the next several months and one of the
activities we tried was reading children’s books out loud with lots of voice inflection.
We practiced reading to pets, nieces and nephews, co-workers’ children, and even an assembly at a
school. By the time we got to the next PI event, the RTE had discovered that if she could read a book
to a group of children, she would be able to lead the next PI event – and she did so with flying colors.
While this approach may seem a little unorthodox, we did what worked for her. I have since used this
approach with others, Product Owners in particular, who are presenting often at System Demos and
lack voice inflection and therefore lose their audience and often insight and feedback from their
customers.
By practicing reading story books with character voices, they start to naturally begin to add more
inflection in their voice as they tell the story of what work the team delivered and the functionality of
the system.
Try it out yourself – you may find it helps you as well!
On occasion, a former Program or Project Manager can make an excellent RTE;

however, a shift in mindset away from command and control and strict schedule
adherence must occur. We need to reinforce that RTEs need to fundamentally shift
their behaviors and work patterns when coming from those types of roles.
SAFe® outlines the RTE needs to move away FROM and TO the following
behaviors:
From coordinating team activities and contributions to Coaching the teams to collaborate
From deadlines to objectives
From driving toward specific outcomes to being invested in the ART’s overall performance
From knowing the answer to asking the teams for the answer
From directing to letting the teams self-organize and hit their stride
From fixing problems to helping others fix them
Responsibilities of a Release Train Engineer

The responsibilities of the RTE can’t be underrated. Ensuring that everything and
everyone is aligned and on track is a full-time job. It’s a version of extreme cat
herding.
The RTE needs to be able to also understand and navigate through various
Coaching stances to determine when to engage versus when to let teams and
individuals struggle a bit to achieve learning.
There are five primary activities that the RTE is focused on:
Figure 6.2 – The RTE’s primary responsibilities (© Scaled Agile, Inc.)
The RTE also needs to ensure they don’t get bogged down by practices. Ensuring a
solid understanding of the principles and staying in alignment is key. Overly rigid
practices and not having an awareness of when and how much to flex known
successful practices are key for an RTE.
There is a common misperception about RTEs that they are responsible for the
release of the system/solution being developed. While the RTE has a hand in the
release, there is no expectation they manage and coordinate it or that they are the
single accountable person that ties up all the loose ends. They rely heavily on the
System Team, Product Management, the System Architect, and the teams to release
systems. The RTE will help coordinate the activities and ensure that impediments
and blockers are removed or escalated appropriately, but the RTE should not be the
person figuratively pushing the button to release.
Product Management
Product Management is a person or group of people responsible for knowing what
needs to be built and ensuring that the ART can deliver the solution in incremental
units of value. Product Management owns the product vision, and to do that
effectively, it needs regular customer exposure to support it.
In many ARTs, Product Management is a single person. However, in highly

complex and/or distributed environments, it takes several individuals, often with
specialized knowledge, to define the product. In this scenario, we recommend that
one person has the overall final decision and lead responsibility.
In this chapter, we will assume that Product Management is a single individual as

this is most common, and we will refer to them as the Product Management.
Product Management needs to be quite personable and easy to work with. When
identifying Product Management, look for someone who has the following
qualities:
Has good market and domain knowledge
Is trusted by peers and colleagues
Has experience with messaging complex information
Understands how to position the solution within the market
Has proven success in working toward consensus
Is forward thinking and curious about customer needs
Balances competing priorities
Is able to admit when a solution doesn’t meet the hypothesis and pivot appropriately
The demeanor, level-headedness, and eloquence of Product Management are critical

as they interface and collaborate across the organization and with customers and
clients.
Product Management must collaborate with many roles. They have lots of
conversations with all levels of the organization and frequently meet with
customers and get insight and feedback on the products they are developing:
Figure 6.3 – Product Management key collaborations (© Scaled Agile, Inc.)
There are many different career paths successful Product Managers follow, but most
individuals come with backgrounds in management and product development.
Some were Product Managers, Domain Experts, Marketing Analysts, Subject
Matter Experts, or Product Owners.
Due to these frequent interactions, Product Management often become

overwhelmed by the responsibilities of the day-to-day working of the ART. This is
where the Product Owners and Product Management relationship is important.
The responsibilities of Product Management

SAFe® outlines five main responsibilities for Product Management:
Figure 6.4 – Product Management responsibility areas (© Scaled Agile, Inc.)
The Product Management role is particularly challenging and finding the right
person or people is often one of the biggest challenges. Product Management needs
to be able to balance the long-term vision of the product with the short-term ART
deliverables. The right person will possess the necessary soft skills, product
knowledge, and leadership qualities to drive the product forward and deliver value
to the customers and the organization.

I worked with a particular client and re-launched an ART. The ART was about 2 weeks from their third
PI Planning. The Product Manager, while an expert in his field, had not sufficiently prepared a
backlog and was struggling to help the Product Owners identify the work for the next PI. The Product
Manager knew what he wanted for the final product but struggled to break it into pieces that the
teams could consume and deliver incrementally.
I met with the Product Manager and quickly learned that he was attempting to define and build the
product step by step. For example, if we were building Amazon’s website, we would completely build
the home page, then all the individual product pages, the user profile, subscription services, and
music, all before building the cart to check out.
We worked quickly with the Product Owners to identify some critical spike areas for the teams in the
next PI. We were able to look at the system as a whole and identified smaller parts from each
functional area that would allow us to see work flow through the entire system.
During the PI, the Product Manager and I worked diligently with the Product Owners and System
Architects to develop a path through the system that would cover all the key components. We called
this our through-line; however, some folks might consider this the happy path. The Product Manager
was then able to add different pieces of functionality and complexity iteration after iteration until the
system was good enough for release.
The Product Manager shared that by breaking the work down and identifying the simplest path first,
as opposed to building out everything completely step by step through the process, he was able to
better manage expectations from Stakeholders and customers. He admitted that he didn’t think the
product would have ever been finished if he had stayed on his original course, and years of work and
millions of dollars would have been wasted.
As a Coach, it’s important to make sure that the ART is delivering incremental value. While the
Product Manager is responsible for identifying it, many are new to the role and are trying desperately
to understand how to work in this type of environment without big upfront and often sequential
design. Any help you can provide in helping them see a simple path through the system will be
appreciated.
System Architect
The System Architect is the technical authority for the ART. The System Architect
is responsible for not only the overall Architecture but also for ensuring that
consistent engineering practices are followed.
The System Architect’s background and knowledge will vary widely, depending on
the solution being built. For example, if we are building a software solution, we
would likely want a System Architect that has been a Software Engineer. However,
if we are building a submarine, we would likely want a System Architect with a
background in Aeronautic Engineering.
The System Architect needs to be able to effectively communicate and work well
with others. The following diagram shows some of the key collaborations the
System Architect engages in:
Figure 6.5 – System Architect responsibility areas (© Scaled Agile, Inc.)
Finding and identifying a System Architect can be significantly challenging, given

the breadth and scope that is expected to be known. Typically, the individual has
significant industry experience, is organized and thoughtful, personable, and
approachable, and understands the importance of teamwork and collaboration.
The System Architect drives the how for the entire system, whereas Product
Management articulates what needs to be built. The System Architect needs to
ensure that the underlying architecture and infrastructure simplify and accelerate
building and delivering Features with Built-In Quality.
The five areas of responsibility for the System Architect are outlined in Figure 6.6:
Figure 6.6 – System Architect areas of responsibility (© Scaled Agile, Inc.)
The System Architect has a significant role in the ART and isn’t alone in its
execution. The System Architect relies heavily on the System Team to deliver the
tools necessary for the ART to deliver successfully. They also rely on the teams to
ensure they are following Built-In Quality practices, minimizing technical debt, and
balancing the delivery of Enablers and Features.
PRO TIP
I have come across several clients who have attempted to map their job titles and roles together,
particularly when it comes to architecture. I strongly encourage avoiding this practice and leveraging
the dual operating model. I encourage you to ensure that your organization understands that the
System Architect role, in particular, is greater than what an Architect is expected to execute.
Now that we understand the roles and responsibilities of the Troika, let’s take a look
at the System Team and the role it plays on the ART.
Do we need a System Team?

Simple answer – yes, even though you will hear or read about, and maybe even
experience, a successful ART without one. In these instances, there is likely a
System Team, but it isn’t formally defined, it isn’t aligned with the ART, the
infrastructure has already been built, or even there may be an entire ART dedicated
to building and maintaining the infrastructure your ART uses.
What is a System Team?
A System Team is simply a group of individuals that works to support teams in
delivering their systems. The larger the system that’s being supported, the greater
the need for the System Team. They create and manage the infrastructure and
environments that support continuous integration, automated builds, and automated
testing: the DevOps pipeline.
Figure 6.7 highlights five primary areas of responsibility for the System Team:
Figure 6.7 – System Team responsibility areas (© Scaled Agile, Inc.)
Based on these responsibilities, we can see how critical the System Team is in
helping the ART continuously deliver value.
While an ART can theoretically function without a System Team, there is a good
chance that someone or multiple individuals on the ART are executing the role.
Many ARTs believe that the infrastructure already in place will be sufficient to
support the ART and do not invest in a System Team. Alternatively, there is a
perception that the team members on the teams have the skills and abilities to build
the pipeline and ensure its security and stability.
Establishing an official System Team shows dedication to and support for the ART
and its ability to deliver. Keep in mind that it is not the System Team’s
responsibility to be fully responsible for solution integration. It’s a partnership with
the teams.
The System Team allows an ART to mature and to share knowledge across the
teams and other ARTs. As the infrastructure is built, the System Team ensures that
knowledge is shared, and it becomes the established way of working.
PRO TIP
In the SAFe® ART Readiness Workbook, one of the items is “Has the System Team been identified
and formed?” In the first ART I launched, I was unable to answer that question with a yes. Now, I
won’t launch an ART without one.
As you can see, the System Team brings a lot of benefits to the ART. They have key
responsibilities that are often lost in the day-to-day work and execution of the teams
and ART. Do you have to have a System Team? No. However, the ability of the
ART to deliver will be impacted, the maturity of the ART will slow, and the
visibility of the work to effectively and efficiently keep the Train running down the
tracks will be hidden and will eventually cause the ART to crash.
PRO TIP
As a Coach, I initially didn’t think the System Team was that important when launching an ART,
however after launching a few ARTs that struggled until we formalized this team, it is now one of the
first teams I identify.
I encourage you to ensure you know who is doing this work even if you don’t have a formal team
identified.
Summary
In this chapter, we looked at the structure and key attributes to consider when
standing up an ART. We learned why it’s important to align your ARTs with your
Value Streams and some challenges you may encounter if you don’t. We discussed
the critical roles in the ART, including the RTE, Product Management, and System
Architect, and that these three roles collectively comprise the Troika. We learned
why the Troika is important and its impact on the ART. Lastly, we learned how
critical a System Team is to our ART and why we shouldn’t overlook this team.
Further reading
To learn more about the topics that were covered in this chapter, take a look at the
following resources:
1. Conway’s Law: https://en.wikipedia.org/wiki/Conway%27s_law
2. The Agile Release Train: https://www.scaledagileframework.com/agile-release-train/
3. Release Train Engineer: https://www.scaledagileframework.com/release-train-engineer/
4. Product Management: https://www.scaledagileframework.com/product-management/
5. System Architect: https://www.scaledagileframework.com/system-architect/

6. System Team: https://www.scaledagileframework.com/system-team/
7. Operational Value Streams: https://www.scaledagileframework.com/operational-value-streams/
8. Development Value Streams: https://www.scaledagileframework.com/development-value-streams/

7
Release Trains Day-to-Day

You have an ART; now what? This is where the fun begins. There are so many
things that happen every day in an ART that it is easy to quickly get overwhelmed.
How to keep everything aligned and who is responsible for managing the everyday
workings of the ART can be a challenge. The Troika, which we discussed in the
previous chapter, plays an important part. In this chapter, we will look at the day-to-
day activities that occur in the ART, as well as activities and actions for key ART
roles, including RTE, Product Management, and the System Architect.
In this chapter, we’ll cover the following topics:

The Continuous Delivery Pipeline (CDP)
Tooling
Day-to-day – Product Management
Day-to-day – System Architect
Day-to-day – the Release Train Engineer
The Innovation and Planning (IP) Iteration

One of the keys to ART success is synchronization and cadence. If you have ever
taken a SAFe® class, you will have heard these two items discussed many times.
These two aspects play a pivotal role in aligning teams and facilitating
communication, contributing significantly to the overall success of the ART.
As a Coach, one crucial responsibility is to assist the RTE in ensuring that all teams
within the ART schedule their events appropriately. By coordinating events, teams
can effectively resolve dependencies and promote cross-team collaboration.
There are several benefits we receive from synchronization and cadence:

Improved communication: Synchronization and cadence enable teams to work together more effectively
by establishing a consistent rhythm for planning, development, and delivery. This promotes better
communication and fosters cross-team collaboration, leading to a more cohesive working environment.
Predictability and visibility: Maintaining a regular cadence helps teams establish a predictable pattern of
delivery, making it easier to plan and manage expectations. This predictability enhances visibility across
the organization, allowing Stakeholders to anticipate outcomes and make more informed decisions.
Faster feedback and learning: Synchronization ensures that all teams within an ART are working in
unison, allowing them to share knowledge, learn from each other, and adapt more rapidly. This process
accelerates feedback loops and promotes Continuous Improvement, resulting in better overall
performance.
Efficient dependency management: By aligning teams within an ART, synchronization helps manage
dependencies more effectively. This alignment enables teams to identify, communicate, and resolve
dependencies promptly, reducing the risk of delays and ensuring smoother delivery.
Higher quality: When teams follow a consistent cadence, they can better plan their work and allocate
resources, leading to higher-quality deliverables. Synchronization also allows teams to identify and
address issues sooner, resulting in improved product quality.
Greater adaptability: A regular cadence allows organizations to respond to changing market conditions
or customer needs more effectively. By maintaining synchronization across the ART, teams can quickly
adapt to new requirements, prioritize work, and ensure that they are delivering the most valuable Features.
This flexibility is crucial for organizations to stay competitive and responsive in a dynamic business
landscape.
As organizations reach the stage where scaling is necessary, implementing

additional patterns becomes crucial to preserve the connection between teams. To
promote and sustain synchronization and cadence, we expand team events to
encompass ART events.
We will delve into each ART-level event in depth, but an important point to
remember is that ART events resemble team events, but on a larger scale. The
following diagram illustrates the correlation between team events (inner loop) and
ART events (outer loop). For instance, we can observe that PI Planning serves as
the scaled ART event equivalent to team Iteration Planning. Similarly, Coach, PO,
and ART Sync correspond to the Team Sync:
Figure 7.1 – ART event correlation to team events (© Scaled Agile, Inc.)
Over the next several chapters, we will review each of the ART events that are
typically facilitated by the RTE and the outcomes we seek to achieve that help us to
maintain synchronization and cadence. However, there are several other aspects of
the ART we need to stay focused on that are not directly related to the ART events,
such as the Continuous Delivery Pipeline.
PRO TIP
As a Coach you will want to ensure that the teams on your ARTs are executing the appropriate team
events and that the ART is executing the correlating ART events.
While SAFe® itself is a framework and thus isn’t prescriptive, by ensuring these events happen
regularly and with the intended outcomes you will find greater success.
The Continuous Delivery Pipeline

The Continuous Delivery Pipeline (CDP) (sometimes referred to as the Continuous
Integration/Continuous Deployment (CI/CD) pipeline) is an integral component of
an ART:
Figure 7.2 – The Continuous Delivery Pipeline (© Scaled Agile, Inc.)
What is the CDP?

The CDP drives ARTs to follow principles over practices, particularly the following
ones:
Principle 4: Build incrementally with fast, integrated learning cycles
Principle 5: Base milestones on an objective evaluation of working systems
Principle 6: Make value flow without interruption
HISTORICAL TIP
SAFe® principle #6 was updated with SAFe® 6.0 to make value flow without interruption. Previously,
it was to visualize and limit the WIP, reduce batch sizes, and manage queue lengths. These three
items, when executed collectively, will allow for an increased flow of value that directly correlates to
lean thinking principle #3.
The CDP is a four-part system representing the workflows, activities, and

automation necessary for an idea to become a release of value. These four parts are
as follows:
1. Continuous exploration (CE): This aspect of the CDP is focused on what needs to be built. Product
Management and the System Architect spend time together in this area defining what needs to be
delivered. We leverage Minimum Viable Products (MVPs) and/or Minimum Marketable Features (MMFs)
to explore and then persevere in development or pivot based on the exploration. The items created
comprise the ART backlog.
2. Continuous Integration (CI): CI is a software development practice that involves automatically building,
testing, and integrating code changes into a shared repository on a regular basis. The goal of CI is to catch
errors and issues as early as possible in the development process, so they can be addressed quickly and
efficiently.
With CI, developers frequently integrate their code changes into a shared repository,
triggering automated builds and tests. This ensures that code changes are
compatible with the rest of the solution and that any issues are detected and
resolved quickly.
3. Continuous Deployment (CD): CD is a software development practice that involves automatically
deploying code changes to production environments once they have been tested and approved. In a mature
CD, code changes are often automatically deployed to production as soon as they pass automated testing
and other quality checks, without requiring any manual intervention.
4. Release on Demand (RoD): The Business chooses when to make the solution, or parts of the solution,
available to customers. This can occur in many ways, including all at once or in a staggered fashion. By
allowing the Business to choose when to release, they can ensure appropriate market timing and the ART
can continue to work on its normal cadence.
The CDP is not a linear process; information flows between all four parts of the
CDP continuously.
Who is responsible for the CDP?

The simple answer is everyone. Depending on the aspect of the CDP, various roles
and teams have larger roles in supporting the CDP.
Product Management and the System Architect play a key role in defining what
should be built during Continuous Exploration. Subsequently, in CI, they ensure
that what they wanted to be built is being built.
The System Team is often responsible for maintaining and maturing the DevOps
pipeline, which enables Agile Teams to continuously integrate and deploy their
solutions while following the architecture and engineering practices outlined by the
System Architect.
The Agile Teams build their solutions while leveraging DevOps practices that allow
the Business to choose when to release. In software development, a common
practice is to use Feature toggles.
PRO TIP
A Feature toggle, also known as a Feature switch or Feature flag, is a software development
technique allowing certain Features and functionalities to be turned on and off without deploying new
code.
Feature toggles are often used to enable the gradual rollout of new Features, to test new Features in
production with a small subset of users, or to temporarily disable a Feature that is causing issues or
errors.
Feature toggles work by wrapping sections of code with conditional statements that check whether a
particular Feature should be enabled or disabled. When a Feature is disabled, the code associated
with that Feature is not executed, and the application behaves as if the Feature doesn’t exist. When a
Feature is enabled, the code associated with that Feature is executed, and the Feature becomes
available to users.
Feature toggles are an important tool for creating more flexible and resilient software, allowing
developers to control the rollout of new Features and respond quickly to issues or errors. However,
they can also introduce complexity into the code base and require careful management to avoid
creating technical debt.
Why do we need a CDP?

We have had the fortunate, or maybe unfortunate, experience in our careers of
helping many different organizations with ART recovery. They have Agile Teams,
they have ARTs, and they are executing but aren’t getting the results that they want.
Most of the time, this is due to a poor CDP.
As a Coach, you will likely encounter organizations that want to “be Agile.” They
will Train people in Agile practices, put them on Agile Teams, start writing User
Stories, implement an Agile tool (such as Jira) to track the work, create ARTs, hold
PI Planning Events, and fail to invest in the technology and development skills
needed to deliver the solutions any differently than they have been.
For car enthusiasts, you could say we have done the bodywork to make the car look
like a Maserati but didn’t upgrade any of the mechanical parts, including the
engine, which is from an old Pinto. It’s like putting lipstick on a pig.
Integrate Often and Early

Integrating work from multiple teams (or even individuals) is one of the hardest
things for most organizations to do. How many times have we heard, “It works on
my machine?” Cadence, the CDP, and DevOps reinforce the importance of frequent
integration:
“Nothing in the world is worth having or worth doing unless it means effort,
pain, difficulty…”
- Theodore Roosevelt
Establishing patterns of frequent integrations, frequent deployments, and release on

demand fundamentally change the culture of the organization. “We have always
done it this way” is a hard habit to break.
Developers will need to learn new ways of working, including, but not limited to,
Test-Driven Development (TDD), ensuring low coupling and high cohesion. They
will need to leverage modularization and test doubles. The environments and tools
will likely need to be improved and upgraded to support these new ways of
working.
PRO TIP
The Iteration System Demos create a forcing function for teams to integrate on a regular cadence.
Because it is “hard,” this is an event that many ARTs try and skip or perform irregularly or only at the
end of the PI.
Note: We have titled the System Demo that occurs during each iteration the Iteration System Demo
to avoid confusion with the PI System Demo, which occurs at the end of the PI.
As a Coach, you will have to challenge the status quo and push the organization to
invest both in technology and people development.
PRO TIP
Ensure that the Iteration System Demos aren’t skipped and work with Product Management to show
a seamless demo between teams, not just each team demoing what they completed in the last
iteration.
The CDP is a crucial element for driving ARTs to prioritize principles over
practices. It is a four-part system consisting of CE, CI, CD, and RoD. This non-
linear process enables the constant flow of information between the four parts.
While everyone has a role in the CDP, certain roles and teams have larger
responsibilities over specific aspects. A well-executed CDP can lead to better
results for organizations, while a poorly implemented one can hinder progress. To
ensure the CDP’s success, it is essential to invest in technology and development
skills and maintain a culture of frequent integration, deployment, and release on
demand. Coaches must challenge the status quo and push organizations to make the
necessary investments in both technology and people development.
Tooling
We aren’t about to tell you what tools are best, what tools we prefer, or even give
you an exhaustive list of tools; we already listed some common industry tools to
help with context and alignment. What you need to know is that everyone hates
their tools and yet they are necessary and even more so in the distributed working
environments in the post-Covid-19 era.
When you are considering your tooling suite to support the CDP, there are a few
key items you will want to ensure your tools assist with:
Workload management
Automated testing
Built-in-Quality
Deployment automation
Metrics
Workload Management
Workload management tools are essential in keeping the teams and ARTs aligned.
Common workload management tools include Jira, Rally, Target Process, and
VersionOne.
Automated Testing
Tools that support automated testing will vary widely, depending on the languages
you are developing in. Selenium and Watir are two common software suites. There
are also multiple levels at which you will need to leverage test automation,
including unit tests, integration tests, and functional UI tests.
Built-in-Quality
Tools in this area intend to help developers improve the code that has been written.
We often focus on code coverage for testing, but there are additional tools that will
look for duplication of code and ensure proper documentation and formatting. A
common code quality tool is SonarQube.
Deployment Automation
One of the most common tools for deployment automation is Jenkins. Deployment
automation is key in allowing teams to move code quickly and easily from
environment to environment and ensure that the proper automated tests are
executed. By automating deployments, we minimize the risk of human error, likely
decrease the amount of documentation, and reduce the time it takes, freeing up
developers to do development.
Metrics
When people think of metrics in Agile, there tends to be a focus on team velocity
and burndowns. See Chapter 15 for more information on metrics. However, many
other metrics need to be considered. The tools in your CDP will have their own sets
of metrics, including (but not limited to) the following:
Code coverage: This metric quantifies the percentage of code that is covered by automated tests,
indicating the extent to which the code base is tested and its overall quality.
Deployment metrics: These measure the efficiency and effectiveness of the deployment process,
including deployment frequency, deployment time, and deployment success rate.
Test execution metrics: These metrics track the performance of the testing process, such as the number of
tests executed, test pass rate, and test failure rate.
Process time: This measures the time it takes for a task or process to be completed, helping to identify
bottlenecks and inefficiencies in the workflow.
Lead time: This metric captures the time elapsed from the initial request to the delivery of a completed
Feature or product, providing insight into the overall responsiveness of the development process.
Delay time: This metric calculates the amount of time for which a task or process is waiting in a queue
before it is executed, helping to identify areas where work has been stalled or resources are being
underutilized.
Percent complete and accurate: This metric assesses the accuracy and completeness of work items,
indicating the quality of the deliverables and the need for rework or additional effort.
System up/down times: These metrics track the availability and reliability of systems, highlighting
potential issues with infrastructure, application stability, or other factors impacting system performance.
Utilization rates: These metrics measure the percentage of available resources (such as team members or
equipment) that are actively engaged in work, providing insights into resource allocation and efficiency.
When using metrics, it is essential to avoid focusing too heavily on a single metric.
Instead, apply SAFe® Principle #1: Take an economic view, considering a balanced
set of metrics to understand the overall performance and make informed decisions.
PRO TIP
As a Coach you will want to ensure that the tools selected by the organization will gather the metrics
needed to mature the ART.
You will want to work with the teams to guide and influence what is being tracked and how frequently.
It’s important to watch out for metrics abuse, where metrics are misused or misinterpreted, leading to
negative consequences and teams being punished.
Lastly, setting up tools isn’t a once and done activity, you will want to ensure that the tool suite is
continuously reviewed, refined, and updated to stay current with industry practices.
So now that we understand the importance of the CDP, let’s shift gears and look at
the people driving ART success and their day-to-day responsibilities and activities.
Day-to-Day – Product Management

While Product Management often spends a lot of their time looking forward and
planning and coordinating work for future Planning Intervals (PIs), they still have
responsibilities in the current PI.
ART Events and Product Management

Product Management is involved in many of the ART events that occur on a regular
cadence.
Product Management and PI Planning

Product Management sets the vision and prioritizes the Features of the ART.
Product Management will need to be available to answer questions that may arise.
They participate in Management Review and Problem Solving and contribute to the
Business Value assigned to team objectives and are consulted on plan acceptance by
the Business Owners.
Product Management and the ART Sync

At the ART Sync, Product Management is an active participant and helps address
and remove any problems and discusses opportunities with the teams.
Product Management and the PO Sync

While the PO Sync may be facilitated by either the RTE or Product Management,
we have found that the event tends to be more effective when Product Management
owns and facilitates it. This event ensures that the Product Owners and Product
Management are aligned on the work being developed, as well as what is coming
up in the next iteration.
Product Management and the Iteration System

Demos
The Iteration System Demo (not the PI System Demo in I&A) is a key opportunity
for Product Management to receive feedback on the current solution. Successful
Iteration System Demos are facilitated by Product Management, who can tell the
story of what is being delivered by the teams. It highlights and shows the
integration of all the work that all the teams have delivered.
Product Management and Inspect & Adapt (I&A)

Product Management is a key player and often leads the PI System Demo portion of
I&A. It is important for Product Management to actively participate in the
Quantitative and Qualitative Measurement and Retrospective and Problem-Solving
workshops. Product Management needs to ensure plans for improvement items are
incorporated into the next PI.
PRO TIP
Plan and dry run the PI System Demo. While we don’t encourage dry running every demo, especially
team iteration demos, the PI System Demo warrants a little extra attention as it is often the only time
when some key Stakeholders attend.
Product Management and ART Backlog

Refinement
Product Management needs to continually refine the ART Backlog in the same
fashion that a Product Owner refines the Team Backlog.
PRO TIP
Encourage Product Management to set aside dedicated time each week to work on the backlog.
Most Product Managers need at least 3 to 4 dedicated hours per week to stay ahead of the ART.
Part of refinement includes working with the Product Owners to help decompose
the Features and Enablers into stories for the teams with appropriate Acceptance
Criteria.
Product Management and Preparing for PI

Planning
Product Management needs to ensure that they have the appropriate presentations
ready for the PI Planning Event. This involves setting and refreshing the product
vision, ensuring that Features and Enablers are ready and prioritized for PI
Planning, and working with Product Owners to ensure Features are broken down
into stories and refined with the teams.
PRO TIP
As a Coach, you will want to ensure that Product Management is engaged with the ART and involved
in the day-to-day work that is being delivered. Too often we encounter Product Management that
doesn’t dedicate the time and effort necessary and we see those ARTs struggle.
Ongoing Activities for Product Management

In addition to attending the ART events, Product Management has five key areas of
responsibility they should be continuously working on:
Figure 7.3 – Product Management responsibilities (© Scaled Agile, Inc.)
As a Coach, you will want to support Product Management as they navigate all the
various areas and aspects of the role. Product Management gets pulled in numerous
directions and often, it is a challenge for them to find enough time to manage and
prioritize the ART Backlog – particularly when new to the role.
PRO TIP
I encourage Product Management to make a habit of explicitly blocking time on their calendars to
work on the backlog, conduct market research, meet the customer, and update roadmaps. This helps
ensure that key activities aren’t skipped due to the tyranny of the urgent activities.
Day-to-Day – System Architect

Similar to Product Management, the System Architect is also looking ahead as well
as keeping abreast of the current execution of the ART.
ART Events and the System Architect

Let’s look at some of the ART events the System Architect attends or facilitates.
The System Architect and PI Planning

The System Architect has a key role in the PI Planning Event – that is, preparing
and sharing the architecture vision briefing. The System Architect is a key
individual at Management Review and Problem Solving and influences the
Business Owner in estimating Business Value and plan acceptance.
The System Architect and ART Sync

At the ART Sync, the System Architect is an active participant and helps address
and remove any impediments and discusses opportunities with Feature and Enabler
development. It’s also a good opportunity to review quality metrics.
PRO TIP
While SAFe® doesn’t identify a Technical Sync, I have found that, in the same fashion, there is a
Coach Sync (formerly the Scrum of Scrums) and a PO Sync, and that teams often have a technical
leader, often in an unofficial capacity. I have had success in formalizing that role and establishing a
Technical Sync that the System Architect leads, just as the RTE or Product Management would lead
the Coach Sync or PO Sync, respectively.
This creates a similar and scalable context for sharing information regarding technical challenges in
the teams, architectural design patterns, infrastructure discussions, and so on. The System Architect
has a daunting role in keeping abreast of constantly changing technology, security threats,
compliance needs, and performance demands.
If your ART decides to hold a Technical Sync, make sure you invite the RTE.
The System Architect and Iteration System Demos

At the Iteration System Demos, the System Architect can see the collective progress
as they likely aren’t able to attend every team’s itineration demo. The System
Architect will often use this opportunity to ask questions of the teams regarding
technical practices and progress on Enablers.
The System Architect and Inspect & Adapt (I&A)

The System Architect actively participates in the PI System Demo and will often
compliment Product Management and share some of the technical underpinnings of
the system that have been developed. It is important for the System Architect to
actively participate in the quantitative and qualitative measurement and
retrospective and problem-solving workshops.
PRO TIP
As a Coach, it is important to ensure that the System Architect is engaged daily with the ART. This
includes actively attending and participating in the ART events.
In my experience, System Architects tend to be a bit introverted and likely don’t understand the full
expectations of the role and will benefit from some extra knee-to-knee guidance and Coaching.
Ongoing Activities for the System Architect

In addition to supporting the ART in the various events, the System Architect has
five key areas of responsibility:
Figure 7.4 – System Architect responsibilities (© Scaled Agile, Inc.)
The System Architect stays very busy and is constantly working with the teams and
organization to deliver quality solutions.
While being embedded in to aligning architecture with business priorities and

fostering Built-in Quality and attending to NFRs, the System Architect needs to
continually refine the ART Backlog in conjunction with Product Management.
They may need to work closely with the Product Owners to decompose both
business and Enabler Features into consumable stories for the teams.
PRO TIP
As a Coach, encourage the System Architect to set aside dedicated time each week to work on the
backlog. Most System Architects need at least 3 to 4 dedicated hours per iteration to stay ahead of
the ART. Often, the System Architect and Product Management will set aside time together every
iteration to work on the backlog together in addition to independent work.
Day-to-Day – the Release Train Engineer

For a Release Train Engineer (RTE), no two days are ever the same. Attempting to
lay out what an RTE should do each day would be come out of date the minute it
was written. In this section, you will discover some typical activities that an RTE
undertakes regularly. Bear in mind that depending on the ART and organizational
maturity, these may vary widely.
Keeping the Train (ART) on the Tracks
There are many idioms that folks use to describe an RTE’s job, including “keeping
the Train on the tracks,” “keeping the plates spinning,” “herding cats,” and
“keeping balls in the air.” I’ve even heard the RTE called the “ART mom.”
However, you want to describe it or whatever you want to call it, the RTE’s job is
indispensable in ensuring success.
Much of what the RTE does is ensure that coordination and conversations are
happening. They are working with Product Management and the System Architect
to look ahead, as well as make sure that the teams are executing their day-to-day
work.
The RTE removes the impediments that are escalated to keep the teams delivering
value. The RTE is a Coach and helps ensure the teams continue to grow and mature
and become high-performing teams.
Whatever comes up that the ART needs help, support, or guidance with is what the
RTE does.
Facilitating the Events

The RTE is responsible for facilitating the ART-level events throughout the
iteration. These events serve as the checkpoints to help the RTE make sure the ART
is staying on track. Depending on the needs of the ART, holding all three sync
events (ART Sync, Coach Sync, and PO Sync) might not be necessary.
The RTE and the ART Sync

Conducting the ART Sync is more an art form than a rigid, prescriptive process.
During the ART Sync, the RTE plays a crucial role in guiding the conversation and
ensuring that the event remains productive and focused.
In an ART Sync, the RTE utilizes the ART Planning Board from PI Planning to
track and assess progress toward the agreed-upon commitments and dependency
deliverables. This helps maintain a clear view of the current state and identifies any
significant deviations from the plans.
This event also serves as an opportunity to review and address risks identified
during PI Planning, as well as to discuss any new risks that may have emerged. By
fostering an open and collaborative environment, the ART Sync encourages sharing
insights and problem-solving strategies that can help mitigate these risks and
maintain momentum.
Additionally, the ART Sync is a platform for discussing and resolving impediments
that individual teams have been unable to overcome on their own. By bringing
together the collective knowledge and experience of the ART, this event enables
participants to devise creative solutions to challenges and remove any roadblocks
that may be hindering progress.
The ART Sync is a dynamic and essential event that allows the RTE to facilitate
effective communication, ensure alignment, and promote problem-solving across
the teams in the ART. By mastering the art of conducting the ART Sync, the
organization can maintain a well-coordinated and high-performing ART, ultimately
delivering value to customers in a timely and efficient manner.
The RTE and the PO Sync

The PO Sync is a crucial event that enables Product Management and Product
Owners to maintain alignment and foster collaboration with their teams. This event,
facilitated by either the RTE or Product Management, creates the opportunity to
discuss progress, address challenges, and ensure that the teams’ goals and
objectives are aligned with the overall vision.
During the PO Sync, Product Owners come together to share updates on their
respective team’s work, review dependencies between teams, and identify any
potential risks or obstacles that need to be addressed. This event also provides an
opportunity to discuss priorities, align backlog items, and coordinate any necessary
adjustments to the overall plan. The exchange of information and insights during
the PO Sync helps create a shared understanding of the status and direction,
promoting a sense of unity and coherence across the ART.
The RTE and the Coach Sync

The Coach Sync, previously known as the Scrum of Scrums, serves as a vital forum
for Scrum Masters/Team Coaches and other select members and Subject Matter
Experts (SMEs) to discuss and collaborate on the challenges they face at the team
level. In addition, it provides an opportunity to share successes and best practices
that have positively impacted their teams. This event plays a crucial role in
fostering Continuous Improvement and knowledge sharing across the ART.
The Coach Sync is an excellent platform for the RTE to offer guidance, support,
and Coaching to the Scrum Masters/Team Coaches. By actively participating in
these discussions, the RTE gains valuable insights into the day-to-day operations of
the teams, allowing them to better understand their needs and challenges.
During the Coach Sync, participants can share their experiences, discuss common
issues, and brainstorm solutions, which can be applied across the entire ART. This
collaborative environment encourages learning from each other’s successes and
mistakes, leading to more effective problem-solving and the implementation of
improved practices.
Furthermore, the Coach Sync can help identify patterns and trends in team
challenges, enabling the RTE to address systemic issues that may be affecting
multiple teams. This proactive approach to identifying and resolving problems
ensures that the ART operates efficiently and effectively, ultimately delivering
value to customers.
The Coach Sync is a crucial event that promotes communication, collaboration, and
learning among Scrum Masters/Team Coaches within the ART. By actively
participating in these events, the RTE can provide valuable Coaching, identify
trends and patterns, and gain a deeper understanding of the day-to-day challenges
faced by the teams, ultimately contributing to the overall success of the ART.
PRO TIP
Not all ARTs will need all three syncs: ART Sync, PO Sync, and Coach Sync. I have found that it
often helps newer ARTS to have all three events as people learn how and what to communicate with
each other in an Agile fashion.
The RTE and the Troika Sync

You won’t find this event in SAFe®, but we have found it to be a key event for the
ART leadership to come together and have honest conversations about the state of
the ART in delivering its commitments. We recommend holding this sync (typically
30 minutes) at least once per iteration. One format that works well is to time box
the event into three 10-minute conversations with each Troika member (RTE,
Product Management, and System Architect) leading the section with their pertinent
agenda topics and discussions.
PRO TIP
I have worked with ARTs that find this to be such a critical event that the RTE, System Architect, and
Product Management treat it like a Daily Stand-up and hold it every day to ensure alignment.
The RTE and the Technical Sync

If your System Architect holds a Technical Sync, the RTE should be an active
participant and listen to the technical challenges the ART may be having, as well as
items that need to be included in the backlog for future PIs.
The RTE and the Iteration System Demos

The RTE’s role at the Iteration System Demo will vary from ART to ART,
depending on the maturity and the strength of Product Management. At the very
least, the RTE will ensure the demo is scheduled with appropriate attendees and
will update the agenda based on feedback from Product Management.
General Responsibilities of the RTE

The five primary areas of an RTE’s responsibility are outlined in the following
diagram. We called out a few key facilitation areas previously that aren’t explicitly
listed here that are especially important as an ART is launched:
Figure 7.5 – RTE responsibility areas (© Scaled Agile, Inc.)
PRO TIP
As a Coach, ensuring the ART is successfully launched and executed is of the utmost priority. First
impressions are critical, especially for PI Planning. Ensure that adequate preparation has gone into
the first PI Planning and that it continuously improves.
As a Coach, you may find yourself spending a lot of time helping the RTE get the
ART going and keeping it on track. The RTE has a big job, and tooling and
preparation are critical elements and areas.
The RTE and Agile Tools

The RTE should be regularly (daily) reviewing the ART metrics in the Agile tools
and helping the Scrum Masters/Team Coaches as necessary to keep the tools up to
date. If leaders aren’t comfortable with the Agile tools, the RTE may become the
go-to source for information on the current “status” of the ART and its progress.
The RTE and preparing for PI Planning and

I&A
The RTE has a big job in preparing for I&A and PI Planning every 10 to 12 weeks.
A good RTE starts preparing for PI Planning as soon as the last one ends. While we
will take a deeper look at what goes into PI Planning and I&A in subsequent
chapters, we don’t want to overlook the amount of work and effort that occurs
during the PI that the RTE does in preparation for these events.
In Appendix A, we have provided a spreadsheet where we have decomposed the

large deliverables that feed into PI Planning and I&A into smaller activities, as well
as provided a suggested timeline of when the various activities should be delivered.
Get Help!
One important thing the RTE must do is ensure they don’t try and do all the
planning, coordination, and execution of the events by themselves. Too often, we
see the RTE trying to do it all. The RTE should leverage Product Management and
the System Architect for help, as well as the Scrum Masters/Team Coaches and
Agile Coaches.
Calendars! Calendars! Calendars!

One of the most tedious activities that an RTE undertakes is working with calendars
and schedules. Many factors come into play. Let’s look at some of the key
calendars/schedules that an RTE is responsible for.
PI Calendar
The RTE is responsible for setting the PI calendar. They will need to coordinate
with the organization to potentially align with other ARTs or ensure that PI events
are off cadence from regular market rhythms.
The RTE should maintain a rolling PI calendar and, depending on the length of each
PI, may need to make adjustments (usually by lengthening a PI) to avoid major
holidays. Typically, we suggest setting the PI calendar to span at least a year,
accommodating four to five PIs on average.
PRO TIP
Pre-Covid-19, many RTEs found themselves needing a PI calendar that was 1.5 to 2 years out. This
allowed them to find and schedule event spaces that could accommodate the entire ART for PI
Planning. While Covid-19 has forced virtual PI Planning, consider that calendars may need to be
extended as organizations are again returning to in-person PI Planning, even if the teams are remote.
Event Schedule
The RTE sets up and schedules the ART events. As ARTs launch, it can be difficult
to find time to schedule these events; we’ve found it best to set them on a cadence
and work the fallout. Often, the conflicts are meetings that already have a similar
function. It will take work and effort to establish the new alignments.
The events the RTE needs to ensure are scheduled are as follows:
PI Planning: Note that there may be multiple invites for this event; see Pro tip.
ART Sync
PO Sync: Encourage Product Management to schedule this event.
Coach Sync
I&A: Note that this event may also have multiple invites; see Pro tip.
Troika Sync
Technical Sync: If holding this event, encourage the System Architect to schedule this event.
PRO TIP
Sending out multiple invites for PI Planning and I&A can help ensure attendance at appropriate times
for key Stakeholders. Often, an executive can’t attend the full 2 days of PI Planning. Consider
sending out invites for the specific timeboxes that would be critical for an executive to attend in
addition to the full invite, such as the business context and vision sections, plan readouts, and
management reviews.
Similarly for I&A, you may want a wider audience for the PI System Demo and then a Quantitative
and Qualitative Measurement and Problem-Solving Workshop invite for ART members.
As a Coach you will want to work closely with the RTE and Scrum Masters/Team
Coaches to set up and align all of the calendars, schedules, and events. This is
especially critical for the ART launches.
PRO TIP
I have had success in declaring meeting bankruptcy. To do this, meet with the Scrum Masters/Team
Coaches and review and identify all the meetings that everyone in their teams participates in,
including the PO. Any meeting that doesn’t correlate to an event must be negotiated to be attended
moving forward. We effectively set a budget for meetings and are judicious in watching our meeting
spend.
Team Calendars/Schedules
While the RTE isn’t directly responsible for scheduling and facilitating the team
events, the RTE (as a Coach) must ensure the team events are happening with the
appropriate outcomes.

I was invited to help recover a failing ART that was already three quarters behind in delivery and
forecasted that it would take at least four additional quarters to complete the work. If you are thinking
that this is a very waterfall mindset already, you are correct. I could probably write an entire book on
this ART and organization, but that is for another day.
For this ART, one area I looked at was their basic practices, including team events. I quickly
discovered that the teams weren’t executing the basic events we would expect, and the ones they
were holding didn’t meet the intent.
Most of the teams held 30 minutes of Iteration Planning, had no scheduled backlog refinement
sessions, Team Syncs were over 1 hour long, iteration reviews had been skipped completely, and
they had irregular retrospectives without actions.
The ART did have an Iteration System Demo; however, it was executed as a combined Iteration
demo for the teams, with each showing work they had completed independently of one another.
The RTE was wearing multiple hats and didn’t have enough insight into the happenings of the teams
on a day-to-day basis. Adding insult to injury, a couple of Scrum Masters/Team Coaches were new to
their roles; they didn’t have formal training and supported multiple teams.
While I Coach teams to leverage principles over practices, this was a clear instance where the
fundamentals were missing, and we re-instated standard ART and Scrum events and the ART quickly
became more predictable and started delivering incrementally.
The lack of event execution is why the RTE needs to have a pulse on what is going on in each team
and why the RTE needs to be aware of each of the team’s events and, in the ART Coach role, ensure
they are being executed effectively.
Now that we understand what day-to-day activities Product Management, the

System Architect, and RTE are responsible for during the PI, let’s take a look at the
last iteration of the PI.
The Innovation and Planning Iteration

The Innovation and Planning (IP) Iteration occurs at the end of each Planning
Interval (PI) and serves multiple purposes. The IP Iteration provides dedicated time
for several different activities teams and individuals may undertake, depending on
their needs and maturity:
Innovation: Innovation gives the team time and space to research new technologies, try out new ideas, and
create a thinking space to drive better solutions in the future. Teams often do this via hack-a-thon,
leveraging design thinking, finding solutions to technical issues, and so on.
Continuing education: Teams should try and learn new technologies or enhance and build existing skills.
They can attend training classes and generally work to expand their T-shaped skills.
Team/ART building: Improve collaboration between the teams with team-building exercises.
Alternatively, they can work collectively to update and refine the various Definitions of Ready, Definitions
of Done, and Working Agreements.
Buffer to meet PI Objectives: Finish Features and refactor and/or fine-tune work that was delivered
during the last PI. This may also include some whittling down of technical debt.
Mature DevOps and CI/CD pipelines: This is an opportune time for upgrades to occur, including
infrastructure, system, tooling, patching, and more.
Measure and grow: Complete Measure and Grow Assessments and compare them with previous PIs.
Common assessments include the Team and Technical Agility assessment and Agile Product Delivery
assessment.
PI Planning preparation: Teams meet and often draft initial User Stories, ensure Features are refined, and
help create and set up the planning space.
Two key events occur during the IP Iteration that time needs to be set aside for:
Inspect and Adapt: Typically, one day of the iteration is set aside for the Inspect and Adapt workshop.
PI Planning: PI Planning typically takes 2 full days in the IP Iteration. If remote sessions, distributed
teams, or travel are involved, additional time may need to be allotted.
PRO TIP
A hack-a-thon is an event, usually lasting anywhere from a few hours to a few days, in which a large
group of people, often with diverse backgrounds and skill sets, come together to collaboratively work
on software or hardware Projects. The goal of a hack-a-thon is typically to create a functional
prototype, solution, or proof of concept for a specific problem or challenge, often within a limited time
frame.
IP Iteration Schedule
Most ARTs align on a Wednesday through Tuesday iteration schedule. This
schedule avoids many major holidays, and most team members are in the office on
Tuesday, Wednesday, and Thursday for key events. Let’s look at some example
event schedules.
Table 7.1 is an example IP Iteration schedule for in-person PI Planning. Monday

and Friday can be used for travel if necessary:
Table 7.1 – Example in-person IP Iteration schedule

Table 7.2 is an example IP Iteration when planning remotely. The same number of
hours are used but are spread across multiple days to minimize “Zoom fatigue.”
This schedule can also be used with distributed teams with limited overlap of
working hours:
Table 7.2 – Example remote IP Iteration schedule
Measure and Grow Assessments

Measure and Grow is a critical and often overlooked tool for the teams and ARTs to
use to reflect on where they came from, as well as to identify areas for Continuous
Improvement. We aren’t going to deep dive into the benefits, learnings, and
opportunities that arise from using measure and grow assessments here, but we do
need to touch on their value.
We encourage you to use the IP Iteration as a regular cadence for doing assessments
with your teams. Then, you can incorporate the results into the Quantitative and
Qualitative Measurement section of I&A or use them as potential inputs for the
Problem-Solving Workshop.
We don’t recommend executing all the assessments with the teams every PI. We
recommend selecting one or two at the most and executing them as a guided and
facilitated conversation to ensure that the statements are understood and
conversation is encouraged.
Consider using the Team and Technical Agility (TTA) self-assessment each PI and
then pick one of the others on a rotating basis, potentially to get feedback on areas
the ART might be struggling with where you want some additional insight from the
ART or an area that was particularly low or high in the Business Agility
assessment.
The Measure and Grow Core Competency Assessments align with the SAFe® Core
Competencies and have questions that align with each of their dimensions. The
SAFe® Core competencies and assessments are as follows:
PRO TIP
As a Coach, we often have to justify the expense/overhead that Coaching incurs. Leveraging
Measure and Grow can help with this justification. You can show the impact Coaching is having on
the ART in terms of the stability and growth of the metrics.
Responsibilities in the IP Iteration

It is incumbent on all ART members to ensure a successful IP Iteration.
RTE IP Iteration Responsibilities

During the IP Iteration, most RTEs barely have time to breathe. They are ensuring
that everything is ready for I&A and PI Planning. It’s coordinated chaos to get all of
the pieces in place.
Product Management IP Iteration Responsibilities

Product Management needs to ensure that the Product Owners are working with
their teams to wrap up any last-minute items, preparing for the PI System Demo,
and ensuring their briefings are ready for the PI event. Product Management may
want to lead a hack-a-thon activity.
System Architect IP Iteration Responsibilities

In addition to preparing for the PI event briefing, the System Architect plays a
crucial role in collaborating with teams to ensure a thorough understanding of the
Enabler’s work for the upcoming PI. This involves working closely with the System
Team to coordinate their efforts and provide guidance on the work they are
executing. The System Architect also contributes to the successful closeout of the
PI by addressing any outstanding issues and ensuring that all necessary work has
been completed.
Another valuable opportunity for the System Architect is to team up with Product
Owners in organizing and leading a hack-a-thon. A hack-a-thon is a focused event
where cross-functional teams come together to work on specific problems or
challenges, often involving innovation, problem-solving, or process improvement.
By partnering with Product Owners, the System Architect can help identify areas
where a hack-a-thon may be beneficial, align the objectives of the event with the
overall vision of the product, and ensure that the outcomes of the hack-a-thon
contribute to the success of the ART.
During a hack-a-thon, the System Architect and Product Owners can facilitate
collaboration, offer guidance, and provide technical expertise to participating teams.
This collaborative environment allows for the rapid development of creative
solutions, the exploration of new ideas, and the fostering of team engagement and
morale. Additionally, hack-a-thons can serve as a valuable learning experience for
both the System Architect and Product Owners as they gain insights into team
dynamics, individual skills, and potential areas for improvement.
Scrum Masters/Team Coaches

The Scrum Masters/Team Coaches help with PI Planning preparation and ensure
the teams are ready for all the events. One item that’s often overlooked is
calculating the capacity for each iteration for the next PI; make sure not to skip this.
The Scrum Masters/Team Coaches will often lead the measure and grow
assessments for their teams. They will prepare their team spaces for planning and
ensure that the plans are captured in the Agile tool after the event. The Scrum
Masters/Team Coaches may also need to facilitate the additional activities that
occur during the IP Iteration, such as a hack-a-thon, training, or team-building
activities.
Product Owners
Product Owners need to ensure that the team is ready for PI Planning. There is
often a lot of last-minute refinement that occurs, as well as ensuring that all work
from the PI is closed out. The Product Owners will also work closely with Product
Management to ensure successful briefings and will often help the Scrum
Masters/Team Coaches in prepping the team spaces and facilitating events.
Team members
The team members are fully engaged with all the wrap-up work, new skill
development, preparation, and execution of the events. As a Coach, encourage the
team members to help identify the work that they want to execute in the IP
Iteration.
We don’t need an IP Iteration

As a Coach, one of the challenges you will likely face with every single ART you
work with is regarding the IP Iteration. This challenge often stems from a
misunderstanding of what occurs during the IP Iteration.
During PI Planning, we ask teams to not plan any stories or work in that iteration.
As a result, people often mistakenly assume that the teams are not working. After
all, we measure the teams by stories completed, right?
You will likely need to justify and push to keep the IP Iteration holistic. Often,
Coaches will talk about using it to reduce technical debt, avoid burnout, and
increase predictability. While these are noble efforts, and people agree that they are
important, they typically don’t carry enough weight to quell the sentiment.
We recommend working with the Troika to identify specific activities that the teams
will be doing during the IP Iteration and have them scheduled out in advance of PI
Planning and then included in the PI plans as stories. This changes the visual of
looking at an empty iteration on the team boards. It shows that the teams are still
engaged and “doing work.” One other consideration would be to not have a board
for the IP Iteration at all.
ACTION
As a Coach, it’s critical to execute a successful IP Iteration. Work diligently with your organization to
ensure this critical event occurs.
Summary
The day-to-day activities of the ART focus on keeping alignment and
synchronization. The CDP allows the ART to deliver value and can be a significant
impediment if it isn’t continuously matured. The tools that drive the CDP and the
ART are important in helping keep track of where the ART is in its journey. In this
chapter, we looked at the activities and expectations for Product Management, the
System Architect, and the RTE during the PI as this group is largely responsible for
ART success. We also covered the IP Iteration and now understand what occurs,
why it’s important, and the responsibilities of everyone in the ART during the
iteration.
Further reading
1. Continuous Delivery Pipeline: https://www.scaledagileframework.com/continuous-delivery-pipeline/
2. Innovation and Planning Iteration: https://www.scaledagileframework.com/innovation-and-planning-

iteration/
3. Measure and Grow: https://www.scaledagileframework.com/measure-and-grow/
4. Product Management: https://www.scaledagileframework.com/product-management/
5. System Architect: https://www.scaledagileframework.com/system-architect/
6. Release Train Engineer: https://www.scaledagileframework.com/release-train-engineer/
7. The Phoenix Project, by Gene Kim
8. DevOps Handbook, by Gene Kim
9. Agile Testing, by Lisa Crispin and Janet Gregory
10. Measure What Matters, by John Doerr

8
ART Backlog Management

The ART Backlog (formerly the Program Backlog) is the holding area for
upcoming Features and Enablers for the ART. Product Management is responsible
for managing and maintaining this backlog.
Ensuring that the ART Backlog is well-refined and maintained is a foundational

component of a successful ART. In this chapter, we are going to look at what the
ART Backlog is and how it differs from other backlogs. We will dive into Features
and Enablers, ensure our backlog is ready for PI Planning, and delve into WSJF.
In this chapter, we will cover the following topics:

The ART Backlog
The ART Backlog

The ART Backlog is a Kanban system that manages the work of the ART. Product
Management is responsible for its management and maintenance. The ART
Backlog contains bot Features and Enablers.
The ART Backlog differs from the Team Backlog in that the items span across the
entire ART and are worked on during the Planning Interval (PI). Alternatively,
compared to the Portfolio Backlog, the ART Backlog is more granular. The
Portfolio Backlog often contains work for several Development Value Streams and
spans multiple PIs.
While Product Management has the primary responsibility of managing the ART
Backlog, key contributors and collaborators include the System Architect, Business
Owners, and Product Owners.
The work in the ART Backlog should come from the Portfolio Epics and Portfolio
Enablers. It is split into Features and Enablers that the ART will be able to deliver
in a PI or less:
Figure 8.1 – Example flow from Portfolio Backlog to ART Backlog (© Scaled Agile, Inc.)
If you’re implementing Essential SAFe®, there is no intentional need for the work
to come from the Portfolio Backlog. Remember to only scale to the Portfolio,
Solution, and Full configurations when necessary.
Ensuring that the ART Backlog is well maintained is one of the most critical items
for the ART. Without a well-defined and refined backlog, the ART will struggle to
deliver value and determine what they should be working on.
The ART Backlog is typically represented via a Kanban Board. In Figure 8.2 we
have an example of how the Features flow through the system, including the usage
of WIP limits and some example policies.
Figure 8.2 - Example ART Backlog in Kanban (© Scaled Agile, Inc.)
Product Management is responsible for ensuring the backlog is continuously

prioritized and updated and shepherds the Features through the process in the same
fashion as an Epic Owner at the portfolio level.
The ART Backlog is a critical tool for the ART. It visualizes the work that is in
progress, as well as what is coming down the pipeline. We can see the different
types of work (Features versus Enablers) and ensure that we have an appropriate
Capacity Allocation to keep our ART running full steam ahead.

As per SAFe®, “A Feature represents solution functionality that delivers Business
Value, fulfills a stakeholder need, and is sized to be delivered by an Agile Release
Train within a PI.” (© Scaled Agile, Inc.)
Great! Now, what does that mean to me in the real world? How do I deliver one?
If we asked you to identify Features on a car, you would likely list things such as
anti-lock brakes, power windows and locks, remote start, leather seats, and so on.
Features don’t have to be hard to define, yet we see many ARTs struggle to define
them. When you approach your system, think about what the key aspects are; that
becomes your starting point for your Features.
When identifying and writing your Features, make sure you include a Benefit
Hypothesis Statement. Simply capture what you expect to gain or accomplish by
delivering the Feature.
Lastly, don’t forget to capture the Acceptance Criteria. These are the key items
necessary to consider the Feature “done.”
PRO TIP
Features don’t need to be written in user-story voice. Use a short phrase or name to capture the
essence of the Feature and then keep the Benefit Hypothesis short and sweet.
Example Feature: Adaptive cruise control
Example Benefit Hypothesis: Cruise control that automatically adjusts speed to the vehicle ahead
of it
Let’s take a look at a specific type of Feature: Enablers.
Enablers
An Enabler is simply a type of Feature that supports NFRs or extends the
Architectural Runway.
We often differentiate between a Feature and an Enabler to help with prioritization

and sequencing or to help ensure we have a balanced Capacity Allocation.
Enablers, like Features, are captured and prioritized in the ART Backlog. They have
a short title, Benefit Hypothesis, and Acceptance Criteria.
SAFe® identifies four different types of Enablers:

Exploration: Research and support for future development or customer needs
Architectural: Work to build the Architectural Runway
Infrastructure: Work to create or optimize environments
Compliance: Work to support specific compliance activities
PRO TIP
When you are first starting, don’t get caught splitting hairs on whether an item is a Feature, an
Enabler, or the type of Enabler. At the end of the day, it’s all work that needs to be done. As you
mature, the Capacity Allocation will likely become more important, and you will get a better sense of
whether it’s an Enabler or a Feature. Worry about it then.
Capacity Allocation
Many people confuse Capacity Allocation and Capacity. Capacity Allocation is the
percentage of the different types of Features and Enablers that are planned.
In the following example, we can see the percentage of new Features versus
Enablers versus Technical Debt and maintenance work on the system. You will
need to determine the Capacity Allocation for your ART and know that it will
change over time:
Figure 8.3 – Capacity Allocation (© Scaled Agile, Inc.)
Understanding your Capacity Allocation is important to help ensure that the ART is
providing a balanced solution. We need to ensure that we have enough
Architectural Runway items balanced with the new Features that are being
requested. If we skew one way or the other, we run the risk of building
infrastructure that isn’t needed or requires additional development when we start
using it, or we don’t have the infrastructure in place to support the new Features and
ultimately can’t deliver them.
Now that we know what Features and Enablers are and why we need to balance
them, let’s look at why sizing them is so important.
Feature Sizing
We know that a Feature should “fit” into a PI, but how exactly do we accomplish
this? Feature sizing is a bit of an art (not an Agile Release Train) and a bit of a
science. We want the Feature to be of value to the customer, but it also can’t be so
big that it takes us a long time to deliver it.
The challenge that Product Management is up against is the same challenge that
Goldilocks had with the three bears: finding the Feature that is “just right.” When
we first launch an ART, the Features tend to be “too big.” We lack the knowledge
and experience to know how much work the ART can deliver in a PI.
We often see this play out in the first stage of PI Planning. Product Management
presents the top 10 Features, and at the end of Day 1, we realize that we will be
lucky to complete 1 (or at best, 2) of the Features. To avoid this in the future, ARTs
will often overcorrect, and we will see Features that are “too small.” Now, almost
every Feature can be delivered in a single iteration.
It can take upwards of a year after the ART is launched before we start to normalize
and get Features that are “just right.” The question becomes, how do we get
Features that are “just right” earlier in the process? There’s no magic bullet, but
here are strategies to adopt early with your ART:
Get feedback: This seems like it should be simple and that it would be a normal part of the process, but
often, Product Management works in a bubble with only the Product Owners and doesn’t ask the teams
that will be doing the work to share how long it will take to deliver it. The estimate doesn’t need to be
precise, and an understanding needs to be established that this isn’t a commitment but an estimate.
Keep batch sizes small: Suggest that Product Management creates a couple of Features to start, maybe
two or three, and then gets feedback. Are the Features too big, too small, or just right? Maybe the Features
have too much detail or not enough. In the same way that we look for the teams to get continuous feedback
on the work they are delivering, Product Management and Product Owners should get feedback on the
work they are delivering in the form of Features and stories.
Definition of Done: Ensure that the Definition of Done (DoD) aligns with and supports the current
environmental setup. We have encountered DoDs stating the work needed to be in production for the
Feature to be considered “done.” The organization had constraints and bottlenecks in the process and the
fastest timeline from development to production was eight weeks (almost an entire PI). We adjusted the
DoD from production to pre-production and then worked with the System Team on streamlining the move
to production over time.
What about Points?

We typically don’t assign points to Features or estimate them from a points
perspective. When we size Features, we are looking to ensure that they are
deliverable in a PI. We want to leverage the concept of relative sizing to help with
estimation.
PRO TIP
When we relatively size Features, we often start with a Feature that took us three to four iterations to
complete and call that a medium. We then take a new Feature and decide whether this new Feature
is bigger, smaller, or the same size as our first Feature.
Some ARTs add up the number of story points once the Feature is completed and
establish ranges for Features, similar to Epics, to help with forecasting. For
example, a small Feature is 50 to 150 points, while a medium Feature is between
150 and 300. We could then potentially look at the average velocity of the ART and
the Features in the backlog and roughly estimate when a Feature could potentially
be delivered. We strongly encourage you to use this practice with extreme caution
as it can lead to perceived commitments.
PRO TIP
When working with teams and ARTs, I typically encourage T-shirt sizing the Features as small,
medium, and large. I look for a small Feature to be delivered in about 2–3 iterations, a medium
Feature typically is 3–4 iterations, and if we have a large Feature, we work to split it into smaller
Features.
Now, let’s take a look at some options for splitting and combining Features.
Feature splitting and combining

In our experience, most of the time, we see Features that are “too big” based on the
feedback from the teams. We will want and need to split our Features into smaller,
more manageable work to keep our batch sizes small. There are many different
ways and methodologies to split work. SAFe® has 10 ways [6]. Ultimately,
whatever practices you follow for splitting stories, you can scale those to Features.
Here are some ways you can split stories that apply to Features:
Workflow steps
Business rule variations
Major effort
Simple/complex
Variations in data
Data entry methods
Deferred system qualities
Operations (for example, Create, Read, Update, Delete (CRUD))
Use case scenarios
Break-out spike
One watchpoint when splitting Features (or stories) is that we want to try and keep
each Feature as independent as possible from another Feature to enable early value
delivery.
If you find that your Features are generally “too small,” it’s important to work with
the teams to identify natural combinations using the same concepts you used to split
a story, only in reverse. Combine Features that were originally split by operations
into one or maybe two Features.
CAUTION – BUT JIRA DOESN’T HAVE FEATURES!

Many of your organizations use Jira as your agile tool, as it is one of the most popular tools on the
market. At the time of writing, Jira currently doesn’t have “Features” in the sense that SAFe® has
defined them. There are numerous workarounds and add-ons available to leverage Features in Jira.
However, my advice is Keep It Super Simple (KISS). Simply use Jira Epics as Features and ensure
that the organization understands. A Rosetta Stone of sorts in that, in our organization, a Jira Epic is
equivalent to a SAFe® Feature.
Now that we know what Features are and why they are important, let’s take a look
at some ways we can prioritize them.
Weighted Shortest Job First (WSJF) is a common prioritization technique for
Features in the ART Backlog. Our backlogs often have many Features, and it can be
difficult to know which to prioritize first.
Why WSJF?
Principles of Product Development Flow, by Reinertsen, [9] described a model
where we want to minimize the amount of money lost by delaying a job. We refer
to this as the cost of delay. Our organizations strive to get the most value in the
shortest amount of time, and by using WSJF, we can empirically determine which
jobs provide the most value in the shortest amount of time.
So, why WSJF? We want to identify the Features that will give us the most value in
the least amount of time. Let’s look at how to do this.
Applying WSJF
WSJF can seem pretty complicated with the numbers and values, and math! Let’s
simplify this. We need four things when we look at WSJF:
1. User Business Value: How important is this to our business or customer?
2. Time criticality: Are there key dates we need for the Feature?
3. Risk Reduction and/or Opportunity Enablement (RROE): What risk are we avoiding, or what
opportunity are we creating?
4. Job size: How big or how long will it take to complete the work?
With these four pieces of information and some math, we can get the WSJF score
and start working on the highest-valued items.
User Business Value, time criticality, and RROE are summed to determine the Cost
of Delay (CoD).
The formula for WSFJ is simply the cost of delay divided by job size:
PRO TIP
We use Job Size as a proxy for the duration; however, we still may need to refactor this as it’s not
always a good proxy.
This seems simple, and it is when you have a few more tricks up your sleeve:
Use a spreadsheet (or similar tool) to capture the values
Use a modified Fibonacci for the values of 1 to 20
Every column must contain a 1
Use relative estimation in determining the values
One at a time, estimate the CoD components (user Business Value, time criticality, and RROE) and then
the job size for all Features
Let’s go through an example step by step. We are getting ready to sell our house.
We have three things that we want to get done before we sell our house. We will
consider each of these a Feature:
Landscape the front yard.
Fix a leaky faucet.
Paint the bedroom.
Here’s an example table:
Feature User Business Time RROE CoD Job WSJF

Value Criticality Size
Landscaping + + = / =
Fix Faucet + + = / =
Paint + + = / =
Bedroom
Step 1
First, we will look at the User Business Value column and determine which
Feature has the least value to us. It is important to note that when working through
this with your organization, you will want to agree on what each of the columns
means to your organization.
In our scenario, we think that fixing the leaky faucet would provide the least
amount of value when selling the home, so we will give it a 1. We think that
landscaping will give us the most value as first impressions and curb appeal are
important when selling a house:

Landscaping 13 +
Fix Faucet 1+
Paint 5+
Bedroom
Step 2
We will now look at Time Criticality. Our realtor (US)/estate agent (UK) wants to
take pictures of the house for the listing, so both painting the bedroom and the
landscaping are urgent priorities. Fixing the leaky faucet is our least time-critical
item:

Landscaping 13 + 8+
Fix Faucet 1+ 1+
Paint 5+ 8+
Bedroom
Step 3
Our third step is looking at the RROE. We think painting the bedroom is our 1
because buyers might still choose to repaint, so we have limited OE, and there isn’t
any risk reduction we could identify. We think that the landscaping and curb appeal
will create some opportunity, but there isn’t any risk we are reducing. The leaky
faucet won’t pass an inspection, and there is a possibility that the leak could get
worse and flood the house, so we scored that higher:

Landscaping 13 + 8+ 3=
Fix Faucet 1+ 1+ 8=
Paint 5+ 8+ 1=
Bedroom
Step 4
We now total the User Business Value, Time Criticality, and RROE into the CoD
column and estimate the Job Size. We think that fixing the leaky faucet will take
the least amount of time, so we have given it a 1. Landscaping is significantly more
work, and we thought that painting was somewhere in the middle:

Landscaping 13 + 8+ 3= 24 / 8=
Fix Faucet 1+ 1+ 8= 10 / 1=
Paint 5+ 8+ 1= 10 / 3=
Bedroom
Step 5
Divide the COD by the Job Size and review the results:

Landscaping 13 + 8+ 3= 24 / 8= 3
Fix Faucet 1+ 1+ 8= 10 / 1= 10
Paint 5+ 8+ 1= 14 / 3= 4.6
Bedroom
Our results indicate that we should complete the work in this order:
1. Fix the leaky faucet.
2. Paint the bedroom.
3. Landscape the front yard.
The secret to winning a WSJF is job size. We want to do the smallest jobs first. Our
results would have looked different if we split landscaping into several smaller jobs,
such as mowing the lawn, putting down mulch, and sweeping off the porch. While
the smallest jobs win, don’t fall into the trap of making Features too small. The
overhead of managing and maintaining so many Features outweighs the benefits.
What if we disagree with WSJF?

On occasion, there will be fundamental disagreement with the results, and
organizations will determine that there isn’t any value in WSJF. When this occurs,
it’s important to dig a bit deeper and understand the root cause of the disagreement.
You will often find that the organization hasn’t broken down large initiatives into
smaller deliverables to enable faster feedback.
WSJF is one way to prioritize the work and works well when there are many factors
to consider – if you don’t need to do it, don’t. Often, Product Management has a
good sense of priority and can simply order the work based on experience and
feedback.
WSJF is one of many prioritization techniques you can use to prioritize the backlog.
Leveraging the ART Kanban board with WIP limits is also a natural prioritization
method and helps keep backlogs manageable. Whichever method you choose,
having a prioritized backlog is critical as you head into PI Planning.

As we discussed in Chapter 7, Release Trains Day-to-Day, the ART executes on a
closed loop and, at scale, executes similar ceremonies to the team. In the following
diagram, we can see that backlog refinement at the team level correlates to our need
to prepare the ART Backlog for PI Planning:
Figure 8.4 – Backlog refinement and preparation for PI Planning correlation (© Scaled Agile, Inc.)
One key reminder is that preparing for PI Planning is a continuous process and that
ensuring the ART Backlog is ready is a key activity. As a Coach, you may need to
encourage the RTE to work closely with Product Management to ensure they have
worked with the Product Owners and teams to socialize and refine the backlog
before the PI Planning Event. We don’t want to surprise the teams with new
Features during PI Planning.
As PI Planning approaches, the ART Backlog should be built out with fully refined
Features; many of the stories should also be identified and partially refined. Without
this preparation, new ARTs, in particular, will struggle to complete all of the
necessary work in the two-day PI Planning Event. As your ARTs mature and the
work becomes more familiar to the teams, the amount of pre-PI Planning
preparation of the stories may decrease over time.
As we look at the ART Backlog and prepare for PI Planning, the top Features that
Product Management shares should be the same prioritized Features that are ready
in the ART Backlog.
PI Planning is critical to the ART’s success. We want to ensure the ART has
prioritized, sized, and clearly defined work as they go into the PI Planning Event.
Summary
The ART Backlog is critical for the ART and shouldn’t be overlooked. By
leveraging the ART Backlog, Kanban can visualize the progress of the Features,
ultimately driving success for the ART. We also want to understand the Capacity
Allocation of our ART Backlog and prioritize the work to deliver the weighted
shortest jobs first, ultimately delivering value quickly through appropriately sized
Features.
Further reading
1. ART Backlogs: https://www.scaledagileframework.com/ART-and-solution-train-backlogs/.
2. Features: https://www.scaledagileframework.com/Features-and-capabilities/.
3. Enablers: https://www.scaledagileframework.com/enablers/.
4. WSJF: https://www.scaledagileframework.com/wsjf/.
5. Planning interval: https://www.scaledagileframework.com/planning-interval/.
6. Splitting stories: https://scaledagileframework.com/story/.
7. Right-sizing your Features: https://scaledagileframework.com/right-sizing-Features-for-safe-program-

increments/.
8. Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and
the Enterprise. Addison-Wesley, 2011.
9. Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product
Development. Celeritas Publishing, 2009.
9
Events for the Train

The ART executes events in the same fashion the Agile team does, only at scale.
ART events are slightly different from team events. Let’s look at the various
activities and events that occur in each iteration and throughout the PI for an ART,
including all the syncs, the ART Board, and the Iteration System Demo.
In this chapter, we’ll look at the following topics:

The syncs
The syncs
The equivalent of a Team Sync for the ART is the ART Sync. Depending on the
ART, it may take various formats. The outcome is always alignment, impediment
removal/escalation, and risk management.
SAFe® outlines three different sync events for the ART:

The Coach Sync
The Product Owner (PO) Sync
The ART Sync
We will provide two additional syncs your ART may want to consider:
A Technical Sync
A Troika Sync
Coach Sync
The Coach Sync is a cadence-based event for the Release Train Engineer (RTE),
Scrum Masters/Team Coaches, and selected Agile Team members or SMEs to align
and continuously work to improve ART and team performance.
The RTE typically facilitates this event. All the Scrum Masters/Team Coaches
should be present. Since this is the scaled version of the Team Sync, you will often
find the event executed in a round-robin format and that the Scrum Masters/Team
Coaches and RTE will answer these (or similar) questions:
What has your team last accomplished since we last met?
What will your team be working on until we meet again?

Are there any impediments in your team’s way?
Will your team be putting anything in another team’s way?
PRO TIP
My favorite question, and one that I sometimes incorporate into the Team Daily Standup, is “Will you
be putting anything in someone else’s way?” Often, we are so worried about getting our work done
that we don’t think about its impact on anyone else. This question can help teams to understand that
they are part of the bigger picture and the impact of the work they are doing.
I don’t typically recommend introducing this question to new teams for their Team Syncs. I do,
however, like to ask this question during the Coach Sync to help the Scrum Masters/Team Coaches
begin to think about the impact they have and to ensure they are thinking about what information they
need to provide to other teams.
In addition to discussing the work that the teams are doing, consider spending some
time to share successes and failures in the growth and maturity of the team and as a
Scrum Master/Team Coach.
The event is typically 30 to 60 minutes in length, depending on any post-meeting

items, other syncs that occur, and the needs of the ART. A successful pattern is to
hold this event once per week, which is twice per iteration; however, it can be more
frequent if needed.
The RTE is responsible for communicating any major blockers or impediments to

the appropriate Stakeholders after the meeting and resolving them, and the Scrum
Master/Team Coach is responsible for communicating information to the teams.
We achieve alignment by ensuring that we are all working toward the goals of the
ART. We improve the ART and team performance by sharing learning and
experiences from working with the teams and the interpersonal dynamics within
them.
PO Sync
The PO Sync is similar to the Coach Sync. It’s a cadence-based event for the
Product Owners (POs) and Product Management to maintain alignment and to drive
the value being delivered by the ART forward.
The RTE or Product Management may facilitate this meeting; however, ARTs are
more successful when the PO Sync is owned and facilitated by Product
Management. All the POs should be present. There is no prescriptive format for this
meeting, and like the Coach Sync, you may find success with a round-robin format
with the following questions:
What Features has the team completed since we last met?
What Features does the team expect to complete before we meet again?
Is the team on track to deliver the Features as planned during PI Planning?

Are there any impediments in the team’s way?
Ultimately, we are trying to determine how the teams are doing in their progress to
meet the PI Objectives and commitments. In addition to discussing the work the
teams are executing, this is a prime opportunity for the Product Team (Product
Management and POs) to do the following:
Discuss and make any adjustments to Features
Acknowledge any market rhythm adjustments
Work on ART Backlog refinement in preparation for the next PI
Share additional customer feedback
Clarify and refine the Acceptance Criteria for upcoming stories
This event is typically 30 to 60 minutes in length, depending on the other syncs that
are occurring and the needs and maturity of the ART and Product Teams.
PRO TIP
It is often a challenge for Product Management to ensure ART Backlog refinement occurs regularly.
Consider scheduling the PO Sync every week for 1 hour for Product Managers and POs to work
together in refinement.
You may want to consider inviting the System Architect to these sessions for feedback and input into
the ART backlog.
ART Sync
The ART Sync may be used in lieu of the Coach Sync and the PO Sync, depending
on the needs and maturity of the ART. The ART Sync is a combined Coach Sync
and PO Sync. The System Architect also attends this event, in addition to Product
Management, the POs, and Scrum Masters/Team Coaches. This cadence-based
event is used to ensure the ART is staying on track.
The RTE typically facilitates this event; the PO and Scrum Master/Team Coach
pairs will provide updates on the progress of their teams by answering variants of
the following questions:
What progress has your team made since we last met?
What progress do you expect your team to make before we next meet?
Will your team be putting anything in another team’s way?
Depending on your ART and what ART iteration events you use, you may want to
clarify the questions to ask specifically about PI Objectives or Features.
As with the PO Sync and the Coach Sync, we are ultimately trying to determine
whether the ART is on track to deliver its commitments. This event is a great
opportunity to look at the ART Board as well as to review the risks identified
during PI Planning.
PRO TIP
Pull up the ART Board and review the Team and ART PI Objectives and risks at the ART Sync.
Typically, this event is 30-60 minutes long, depending on post-meeting discussions.

If you are only holding the ART Sync, we recommend holding this event weekly;
however, if combined with a PO Sync and Coach Sync, once per iteration is usually
sufficient for ongoing alignment, depending on the maturity and needs of your
ART.
PRO TIP
The one aspect to note in an ART Sync that varies from the PO Sync and Coach Sync is that the
timebox typically doesn’t allow for continuous learning and improvement. In the Coach Sync, we try to
spend some time growing the teams. In the PO Sync, we are afforded the opportunity to prioritize and
refine the ART backlog. The ART Sync, due to the number of attendees, typically lacks that
opportunity, with general announcements taking precedence.
Figure 9.1 shows how the ART, PO, and Coach Syncs complement one another:
Figure 9.1 – ART, Coach, and PO Syncs (© Scaled Agile, Inc.)
The Technical Sync

The Technical Sync isn’t outlined by SAFe®; however, it can be a very valuable
addition to help keep the ART aligned. The Technical Sync is like the Coach Sync
or PO Sync, but builds alignment from an architecture, engineering, and
development perspective.
The RTE or the System Architect may facilitate this meeting; however, ARTs are
more successful when the Technical Sync is owned and facilitated by the System
Architect. The attendees can be a bit tricky to identify as SAFe® doesn’t specify a
technical lead role in the teams. However, what we typically find within most teams
is a senior technical person that often helps guide and informally leads the team’s
development. This is the recommended attendee from each team. If there isn’t a
lead on the team, you can also rotate the attendees and, eventually, you will find
that someone will self-identify as a regular attendee.
At the Technical Sync, the attendees can answer variations of the following
questions:
How is your team progressing with delivering its commitments?
Will your teams be putting anything in another team’s way?
During the Technical Sync, the outcome is to learn about challenges and gain
alignment within the technical domain of the solution we are building. Many
developers are introverts by nature and being at this event among their peers is an
opportunity to raise what may seem to be insignificant issues in the grand scheme
of things, but that can have a significant impact over time.
At this event, we often learn about challenges with the following:

Development and testing environments
The DevOps pipeline
Test automation issues
Deployment constraints
Delays in the system

I once worked with an ART, and it was during one of the Technical Syncs that the developers
mentioned that it was taking a long time for the builds to complete. The others agreed, but it was
considered normal.
Fortunately, the System Architect was astute and asked a few follow-up questions:
How long is a long time?
Is this happening for every build?
How frequently, on average, would you say you do a build?

It turned out that every build was taking between 5 and 7 minutes to complete and the average
developer would run a build 3 times an hour. This meant that approximately one-third of every hour
was lost. That’s significantly wasteful overhead. It was also noted that the developers would like to
build more frequently but often avoided it due to how long it would take.
They began investigating why the builds were taking so long, were able to make some adjustments
within the environments, and were able to reduce the build time to under 30 seconds. This allowed
the developers to build more frequently, and it ultimately improved the velocity of the teams.
The Technical Sync is typically 30-60 minutes in length. Allow the team to
determine the frequency of this event; we recommend at least once per iteration.
PRO TIP
For new ARTs, I recommend holding all syncs: the PO Sync, Coach Sync, and Technical Sync. I find
that this helps communication and helps with role alignment. Eventually, you can reduce or adjust the
events as the teams and the ART mature by leveraging the ART Sync.
The Troika Sync

The Troika Sync is also not outlined by SAFe®. This is simply a regular
synchronization point and discussion to ensure alignment between the RTE, Product
Management, and System Architect. It’s an opportunity to compare notes on what
they are hearing in their respective areas and to ensure alignment on messaging.
The agenda for this meeting typically revolves around the current challenges of the
ART and a look ahead toward the next PI.
The RTE usually facilitates and schedules this sync, and it typically runs for
between 30 and 60 minutes. This should occur as frequently as is needed, even
daily. Many issues will come up that need to be addressed, and having a regular
daily touchpoint to resolve issues and address challenges will help the overall
health of the ART and establish regular communication channels.
Release Management Sync

SAFe® mentions that a Release Management Sync may be necessary to coordinate
upcoming releases, communicate about the releases, and ensure governance
requirements are met. How this meeting is structured, its frequency, participants,
and so on will be unique to each ART depending on what is being built. Use the
System Team to drive this sync.
Scheduling the syncs

The RTE typically schedules the syncs. Product Management and the System
Architect usually own and facilitate the PO and Technical Syncs respectively;
however, coordinating the schedule of the activities is important.
Here is an example schedule for your consideration. Adjust it to fit your ART
needs:
Wednesday Thursday Friday Monday Tuesday
Week Iteration PO Sync Troika ART Troika Sync

1 Planning Sync Sync
Coach Sync
Technical
Sync
Week PO Sync Troika ART Troika Iteration Review

2 Sync Sync Sync
Coach Sync Iteration
Technical Retrospectives
Sync
Table 9.1 – Example sync schedule
In the schedule, you will notice that the PO Sync, Coach Sync, and Technical Sync
are all held on the same day. You may even want to consider holding them at the
same time.
We recommend placing the ART Syncs mid-way and toward the end of the
iteration. This allows the teams a few days to dive into the work and then provides a
checkpoint toward the end of the iteration to address any areas where work may not
get completed and whether the team needs to pull in additional work to be
completed in the iteration.
PRO TIP
There is no “correct” way to structure and schedule your ART’s various sync meetings. It’s more of an
art than a science, no pun intended. Every ART has unique needs and challenges. That’s why
SAFe® isn’t a textbook, but a framework. What works best for one ART might not work for another,
even in the same company.
As a Coach, be sure to be flexible; however, also ensure that your ART is delivering the outcomes for
success by ensuring the syncs are happening and that you are getting the necessary alignment and
maturity from them.
Bonus sync recommendations

Now that we understand the key syncs for an ART, let’s take a look at a few more
items that we want to ensure are covered in the syncs.
Do we need all these syncs?
The simple answer is no, you don’t need all these syncs. However, each of these
syncs does serve a purpose and helps with communication and the alignment of the
ART. Use the syncs that your ART needs. You may also find that these meetings are
occurring anyway, and these syncs become a way to formalize, operationalize, or
even eliminate the extra meetings.
PI Objectives
Remember our goal is to deliver our PI Objectives; ensure that doesn’t get lost in
the sync meetings and that there are regular discussions on progress toward meeting
the objectives.
Impediment escalation
One watchpoint is that people will wait until a sync to escalate impediments.
Having numerous syncs can help to prevent that from occurring. Our goal is for
impediments to be resolved or raised as quickly as possible. As a Coach, you can
help ensure that immediate impediment escalation and removal are occurring.
Not a status meeting

One key watchpoint is that these sync meetings don’t become status meetings. If
you find that is happening, consider holding a retrospective and reviewing the
intended outcome of the event with the group.
Iteration goals
One item you might want to introduce during syncs early in the iteration is sharing
the iteration goals that the team creates. Sharing them can help build alignment and
provide a simple way for the teams to know what each other is focused on.
Taking it back to the teams

You will want to remind the sync attendees of their responsibility to take
information from the syncs back to the teams. This is often overlooked, and
information only flows up and doesn’t always make it back down. The syncs are an
intersection, with information needing to flow in multiple directions.

The ART Board is unique to SAFe®. It has been said that if you aren’t doing PI
Planning, of which a key output is the ART Board, then you aren’t doing SAFe®.
NOTE
Prior to SAFe® 6.0, the ART Board was known as the Program Board.
What is the ART Board?
The ART Board is an outcome of PI Planning and is key to the planning process.
The ART Board is a representation of the work the teams are completing and when
they expect to complete it.
The importance of the ART Board can’t be understated. As a Coach, making sure
the ART leverages the ART Board to its fullest potential can be one of the hardest
things to accomplish. Ensuring that the ART Board is created with the necessary
level of detail during the PI event and that the ART actually uses it during and after
the PI event takes some effort.
Most folks think of the ART Board as only the ART Board with the rows for the
teams, the sticky notes, and the string; however, if you think of all the information
gathered and collected for the ART, there are several key components:
The ART Planning Board
The ROAM Board
Integrated ART PI Objectives

The ART Planning Board captures the Features, dependencies, milestones, and
support needed from others who are not in the ART.
The ART Planning Board is a grid with a column for each iteration in the PI and a
column for the next PI. There is a row for milestones, a row for each team, and
some extra rows for out-of-ART support. These may include UX support, additional
architecture work, callouts to a Shared Services Team, and so on.
On the ART Planning Board, the teams will add sticky notes for each Feature,
typically blue, to the iteration in which the team plans to complete the Feature.
Red sticky notes capture dependencies between the teams and should ultimately
align with the delivery of a Feature. Red string is attached to the dependency, and
sticky notes show the critical path.
Orange sticky notes are typically used to denote milestones or significant events
that affect the ART.
PRO TIP
Keep the sticky note colors on the ART Planning Board consistent for each PI. We have mentioned
the typical colors that SAFe® recommends here. Over time, you might discover that you are running
low on one color and have an excess of another. You could choose to invert the colors; just make
sure that everyone on the ART is aware and has updated legends so when folks read the boards,
they know what they are looking at.
If you are creating a physical board, 1-inch blue painter’s tape works well for
creating the rows and columns. You can print out and tape up the team names and
iterations with dates to label the rows and columns.
Here, you will find an example of an ART Planning Board with dependencies,
Features, and milestones.
Figure 9.2 – Example ART Planning Board
ART Planning Board tools

There are many different tools available for your ART Planning Board. If you are in
person, sticky notes and painter’s tape will work on almost any wall. You might
want to consider getting vinyl or laminated boards (and team boards) printed so that
you can reuse them for every PI and potentially transport them from your PI event
space back to the office.
In the virtual world, there are various tools that support the ART Planning Board,
including PIPlanning.io, Agile Hive, Mural, Miro, and even Excel.
We encourage you to check out what’s available and works within your budget to
provide the best experience and integrations for your ART.
The ROAM Board

The ROAM Board, sometimes called the Risk Board, captures the risks that may
affect the ART. ROAM stands for Resolved, Owned, Accepted, and Mitigated.
These are the states assigned to the various risks identified during the PI event:
Resolved: The Resolved state captures risks that were identified during the PI event that have been solved
during the PI event and are no longer risks.
Owned: The Owned state captures risks that an individual has taken ownership of to ensure the risk gets
resolved or mitigated.
Accepted: The Accepted state captures risks that, if they occur, the ART will address at that point in time.
These are risks that cannot be resolved in advance.
Mitigated: Risks in the Mitigated state are ones that are targeted by plans to reduce their impact. A
recommended practice is to identify who or what team will mitigate the risk and ensure that it is part of
their plans.
PRO TIP
Consider getting the teams to write the risks as “if X, then Y.” This format helps understand the
impact of the risk being articulated.
For example, if Team Aviators don’t have the widget from Team Blue Falcons by Iteration 2, then
Team Aviators won’t deliver the component by the end of Iteration 4.

I have rarely found risks that have been added to the Accepted state materialize. However, I was at a
PI Planning session in February 2020, and one team raised a risk that the scheduled parts may not
arrive timely due to the news regarding shipments from China.
As we all know now, less than a month later, the world pretty much came to a standstill with Covid-19
and that risk (plus a few more) had to be addressed at that time.
There is occasional confusion between Mitigated and Owned, particularly when

identifying who is executing the mitigation plan. Keep in mind that Owned risks
still need additional work to identify the plan, whereas Mitigated risks already have
a plan assigned to them; the plan just needs to be executed.
The Integrated ART PI Objectives

The Integrated ART PI Objectives are typically created after the PI event by the
RTE, Product Management, and the System Architect and are a combination of the
objectives created by the teams. We recommend capturing them and adding them to
the area where your ART Board is stored. We will be able to leverage them during
the iterations.
PRO TIP
Many ARTs don’t take the time after the event to create their integrated ART PI Objectives and, all
too often, the ART loses a bit of focus, especially toward the end of the PI. Make sure you take the
time to create the objectives.
Consider creating the overarching PI Objectives prior to the PI event. Share them as part of the
Product Vision. Then, as the teams create their PI Objectives, they can even share how their
objectives compare to the overall objectives for the PI, thus improving alignment.
Using the ART Board during the Iterations

We recommend leveraging the ART Board throughout the PI. The teams have
worked diligently during PI Planning to identify dependencies, plan Features, and
identify risks. Too often, we see the PI work fall by the wayside once the iterations
start. This feels like a waste and not an embodiment of the Lean-Agile principles
we want our ARTs to have. When we leverage the ART Board during the PI, we
reduce risk, as the teams have already identified and planned for many potential
complications.
Recreating the ART Board in your ART’s space
Prior to Covid-19, we typically held PI Planning Events in person and would have a
wall for the ART Board. We would take copious amounts of pictures and recreate
the physical board in our ART’s space after the PI event. If you are fortunate
enough to have face-to-face PI Planning Events and are regularly working together
in the office, our recommendation is that you recreate the ART Board in your space
if it is separate from where you hold PI Planning.
If you are virtual, as many organizations now are, we strongly encourage you to
invest in tools that support remote PI Planning, including the creation of an ART
Board.
Having an ART Board that team members can look at and view regularly helps
maintain alignment and allows teams to have conversations when items change or
shift or can even just remind them of what they committed to during PI Planning.
Using it at the Sync Events

By reviewing the board at the various syncs, we can realign with the common
objective we are driving toward. Depending on the sync, you may want to use the
board in various ways and review different aspects of it from different perspectives:
ART Sync: Review the dependencies to ensure they are on track for resolution and don’t become blockers.
Review risks to ensure they are being mitigated appropriately.
PO Sync: Review Feature delivery plans and have discussions regarding any changes to the plans.
Coach Sync: Review the dependencies to ensure they are being resolved and capture any additional risks
or dependencies that have arisen during the PI.
Technical Sync: Review the progress toward delivery and identify any technical challenges that could
impede delivery.
As a Coach, you will want to work closely with the teams to help them use the ART
Board during their team meetings as well. Consider reviewing it as part of Backlog
Refinement and Iteration Planning.

The Iteration System Demo is held once per iteration for the entire ART. The
intention is to provide an integrated view of all the work that all the teams have
completed. Integration of work is one of the hardest things that teams do, and the
Iteration System Demo is a forcing function for the integration of the systems and
to give Stakeholders an objective measure of progress during the PI. Without the
Iteration System Demo, we are unable to determine the actual progress being made
to meet the PI Objectives and lose a critical feedback loop to keep the ART on track
or to make any adjustments.
How to execute an Iteration System Demo
The Iteration System Demo should be executed after the end of every iteration and
show the Features developed during the last iteration.
It is typically scheduled by the RTE and facilitated by Product Management with

help from wider teams.
There is some planning and preparation that is required for the Iteration System
Demo. You will need to balance the preparation efforts and, if the preparation for
the demo is costly, there are likely areas within the ART for improvement.
Attendees typically include the System Team, Business Owners, the System
Architect, ART team members, and Stakeholders.
There is typically a set agenda and a fixed timebox, usually 1 hour. The agenda
often includes the following:
Reviewing the PI Objectives
Describing the Feature prior to demonstrating it
Demonstrating the Feature with an end-to-end scenario
Reviewing and identifying any current risks or impediments
A question-and-answer session
A closing-out summary with feedback and the action items captured
When holding the Iteration System Demo, you will want to demo from an
environment as close to production as possible; typically, this is a staging
environment.
Considerations for the Iteration System Demo

Consideration #1
Some systems, particularly those in manufacturing environments, may be too
expensive to demo every two weeks. In this instance, you will want to work closely
to determine what can be demoed and leverage the use of test doubles, models, and
mock-ups.
Consideration #2
The cost of skipping the Iteration System Demo is extremely expensive. When we
don’t integrate and use the Iteration System Demo as a forcing function, we are
unable to truly see the progress of the working system, which creates a false sense
of accomplishment. Late integration is one of the biggest challenges and costs
which leads to significant rework. Remove the cost by insisting on regular Iteration
System Demos.
It is also important to ensure that the Iteration System Demo is integrated and we
can see value flow through the system, not just teams independently highlighting
the work they have completed. We strongly urge you to avoid these anti-patterns.
Consideration #3
Use the Iteration System Demo as a way to continuously improve the Continuous
Delivery Pipeline (CDP).
As former developers, we can assure you that if we have to do something more than
once, we’re going to try and find a way to automate it and avoid having to manually
complete steps if possible. The Iteration System Demo being executed as close to
production as possible helps build out that automation and ultimately helps us to
build in quality, as it will drive the use of test automation as well.
Summary
In this chapter, we learned about the various syncs we need to use to keep the ARTs
aligned and why these syncs are important. We have even looked at a couple of
extra syncs, including a Technical and Troika Sync. We learned how to
continuously leverage the ART Board and why it’s important to not skip the
Iteration System Demos due to their value.
There is a lot of continued alignment and execution that occurs during the iterations
in the PI. Don’t fall into the trap of letting the teams operate independently during
the PI. Use the Syncs, ART Board, and Iteration System Demos to retain alignment
and keep the ART on the right track. In the next chapter, we’ll look into the PI
event.
Further reading
1. Planning Interval: https://www.scaledagileframework.com/planning-interval/
2. PI Planning: https://www.scaledagileframework.com/pi-planning/
3. System Demo: https://www.scaledagileframework.com/system-demo/

10
PI Events
There are several key events that happen as part of the PI boundaries and that only
occur once in a PI. PI Planning is the kick-off in the same way that Iteration
Planning starts the iteration. The Inspect and Adapt (I&A) Event closes out the PI
in the same way that the Iteration Review and Retrospective close out the iteration.
We will cover the following topics in the chapter:

PI Planning
The execution of PI Planning
The I&A event
PI Planning
The PI Planning Event is one of the most important events for any organization
executing SAFe®. It’s often said that if you aren’t doing PI Planning, you aren’t
doing SAFe®. PI Planning is like Iteration Planning for the ART. It’s often referred
to as the heartbeat and is pivotal in keeping the Train on the tracks and delivering
the right work.
There is a lot of work and effort that goes into the execution of successful PI
Planning. As a Coach, you will want to ensure that the Release Train Engineer
(RTE) is preparing throughout the PI for the next PI Planning Event.
Traditionally, PI Planning was a face-to-face event that occurred every 8-12 weeks,
with 10 being typical. However, since Covid-19, it may no longer be practical or
feasible to hold planning face-to-face. When possible, we still encourage face-to-
face planning, as it promotes team building and collaboration.
If face-to-face planning is not an option, ensure you have invested in technology

that will support virtual, remote, or distributed PI Planning. This includes video
conference equipment, shared workspaces, virtual boards, break-out spaces,
applications designed to support PI Planning that can be integrated with Agile
planning tools, and so on.

I was working with an organization and when we learned that Covid-19 was going to force remote
planning for the remainder of 2020 and into 2021, the organization was reluctant to invest in more
tools. There was an impression that a virtual whiteboard and MS Teams were sufficient. As a Coach,
I could see that the teams weren’t planning as effectively as they had been when we were face-to-
face. The organization was hesitant to invest in more tools to support an event that occurred a couple
of times a year.
We calculated the cost of a single face-to-face PI Planning Event compared to the cost of the tools
being requested. The difference was significant and we determined that after two PI Planning Events,
the cost of the tools would be offset. A new Covid-19 variant was identified and we were not going to
be able to return as quickly as we had anticipated to face-to-face PI Planning. We made the decision
to invest in better tools and started to see more effective planning and improved delivery.
We also discovered that PI Planning remotely, even with improved tools, took longer and the
conversations that would naturally occur during lunches and breaks didn’t occur. This led to some
missed dependencies, and we discovered we needed to be even more intentional in finding ways for
those types of conversations to occur. We established “fireside chats” during PI Planning and had 1
member from each team go into a specific room; these small groups were able to share what was
going on in their team rooms and some of the work they were planning, and were able to get to know
individuals from other teams a little better. The team members loved it and took part in these same
sessions several times throughout the PI Planning Event.
The RTE and PI Planning

Many people would say that PI Planning is what being an RTE is all about and that
successful PI Planning is the measurement of a good RTE. While there is more to
being an RTE than executing successful PI Planning Events, it is a critical part of
the role.
The RTE sets the tone of PI Planning. The RTE should have lots of enthusiasm and
excitement, as that gets absorbed by others in the room. How prepared the space is
(whether virtual or physical) will also impact the success of the event. The attitude
and demeanor of the RTE also set the tone. If the RTE is overly stressed or doesn’t
handle the inevitable curveball well, then the ART tends to behave the same. To this
end, as a Coach, supporting the RTE through this event is critical.
Preparing for PI Planning

RTEs should begin to prepare for the next PI Planning Event shortly after the
previous event ends, early in the PI. In Appendix A, you will find an expanded
checklist of items, as well as suggested dates for PI Planning activities. This list is
based on the ART Readiness Workbook in the SAFe® PI Planning Toolkit and is
available to RTE and SPCs in good standing.
You can’t underestimate the amount of planning that is necessary or the time and
effort it takes to get organized. One thing to keep in mind is that the RTE shouldn’t
try and do it all themselves. Leveraging support from the Scrum Masters/Team
Coaches, Product Owners, Product Management, and System Architect will help
make the event successful.
The RTE is like the ringmaster in a circus, coordinating all the parts and
announcing the various activities, but ultimately relying on the other performers for
their individual pieces.
Preparing attendees
You will want to ensure that all PI Planning attendees understand the expectations
prior to the PI Planning Event. Make sure that all members of the Agile Teams have
completed SAFe® for Teams. Hold an overview of PI Planning for any
Stakeholders that haven’t attended a SAFe® class or past PI Planning Events.
Consider spending some additional time with the Business Owners discussing PI
Objectives and how to assign Business Value. Lastly, make sure that Product
Management and the System Architect have agreed on Capacity Allocations for
Features compared to Enablers and technical debt.
PRO TIP
Leverage the PI Planning Overview for Stakeholders slides from the SAFe® PI Planning toolkit.
The day before PI Planning

Depending on whether you are holding a virtual or in-person PI Planning Event,
you will want to ensure your environment and space are prepared at least the day
before. If it will be virtual, you can work on this during the weeks leading up to the
event.
For in-person events, typically, the day before or right after the I&A workshop, the
room needs to be set up and configured for the event. This includes building the
ART Planning Board, Risk Board, and the team areas and boards. You want to
ensure that when the teams arrive for the first day of PI Planning, they are able to
jump directly into a successful event and not spend time creating their work
environment.
With virtual events, you will need to ensure that your tools are configured with the
appropriate boards. All ART members have links to the locations of the boards,
virtual rooms, tools, and logins. Consider holding a session prior to the event to
familiarize ART attendees with the tools and breakout spaces.
The preparation for PI Planning can’t be undervalued. Ensure you put in the time
and effort to have a successful event. While each event is unique, you will quickly
learn that you can leverage what’s learned from one event in the next one.
Executing PI Planning
The PI Planning Event is typically 2 days long. Depending on whether you are in
person or remote or have distributed teams across multiple time zones, you may
want to span the event across a greater number of days for shorter durations each
day.
Figure 10.1 depicts the standard PI Planning Event schedule. We will walk through
each activity in detail.
Figure 10.1 – PI Planning Schedule (© Scaled Agile, Inc.)
There are several PI Planning schedule variations in Appendix B.
When preparing for PI Planning, be sure to use the SAFe® PI Planning Toolkit. It is
a rich resource that can help ensure a successful PI Planning Event. The SAFe® PI
Planning Toolkit is only available to SPCs and RTEs in good standing.
Let’s take a deeper dive into the various parts of the event.
Day 1 kick-off
Day 1 starts out with breakfast! One of the most important items at a face-to-face PI
Planning Event is food. If remote, consider putting together a box and sending it to
each attendee with various goodies, including coffee, tea, snacks, and candy or
sweets. Once the ART has gathered, the RTE will kick off the event with the
Welcome segment of the presentations.
Presentations
We start with the Business Context, followed by the Product/Solution Vision, then
the Architectural Vision and Development Practices, and lastly, the Planning
Context. We have a 4-hour time slot for these presentations.
PRO TIP
This part of the PI Planning Event can feel a lot like a bunch of talking heads. Toward the end of the 4
hours, everything may begin to sound like Charlie Brown’s teacher. Wah-wah, wah-wah-wah. To
avoid this, make sure to plan short breaks (especially if remote) and work with the presenters to
ensure that they avoid reading slides. Encourage and even push the ART to ask clarifying questions
(even if you have to plant a few questions to get things going).
Welcome
When you look at the typical PI Planning Event schedule, the Welcome is often
overlooked and combined with the Business Context. As the master of ceremonies,
the RTE should open the event, spend a few minutes welcoming folks, talk through
the high-level schedule to set expectations, and consider introducing key ART
members.
The PI Planning Event Template from the PI Planning Execution Toolkit has a
handful of slides to help set the context for the event, including why we are here,
the agenda, working agreements, and some initial guidance.
If in person, consider identifying each table by its team so that the room is aware of
where everyone is located.
The Welcome should last 15 minutes or less. At the end of the Welcome, the RTE
can introduce (with excitement) the executive, who will present the Business
Context.
The Business Context

The Business Context sets the tone of the PI Planning Event. We want executive
leadership to share the state of the business and its upcoming objectives. There isn’t
a prescribed format; it depends on the executive who is presenting and the needs of
the ART.
When working with the executive on how to prepare, ensure that key portfolio
priorities are communicated, as well as how the solution that the ART is developing
fits into the portfolio and organizational strategy.
Sometimes, a SWOT analysis is used to help convey where the solution fits in the
big picture. Ensure that the WHY is communicated, which is important for the ART
to deliver.
You may need to Coach the executive on how to be personable and approachable in
their presentation. An overall understanding of what the ART is delivering is key.
An hour is allotted to the conversation that the executive holds with the ART, which
should include a Q&A.
Identifying the executive

Depending on your organization, it may not be clear which executive can
effectively lead the Business Context conversation. It would be highly beneficial for
the President or CEO to spend an hour with the ART and set the context; however,
this may not be feasible. Identify an executive who is the most senior person
available, has direct knowledge of the work the ART is executing, is powerful
enough to make decisions, is respected within the organization, and can potentially
spend additional time at the PI Planning Event and attend future System Demos
(ideally the Iteration System Demos, but especially the PI System Demo).
PRO TIP
Depending on your organization, you may have the opportunity to have several executives attend
and set context and/or rotate executives depending on the solution being developed.

I had an occasion where the night before PI Planning, the senior person delivering the Business
Context phoned me to say that he couldn’t attend the PI Planning Event because of a major company
merger. At that stage, my only option was to get one of the other Business Owners to present his
slides on his behalf, which is never ideal. Because this wasn’t the only time this happened, going
forward, I now always get the person delivering the Business Context to create a video recording. Not
only does it give me a backup if the person can’t attend but it also means that I am never chasing the
Business Context at the 11th hour!
By the end of the Business Context discussion, ART members should understand
how their work directly impacts the business and why the work they are doing is
important.
Product/Solution Vision
“If you don’t know where you are going, any road will get you there.”
– Lewis Carroll
The purpose of the Product Vision (and Solution if you are part of a Solution Train)
is to lay out the plans for the ART’s PI. We dedicate 1.5 hours to this conversation,
which can seem long and overwhelming if not well thought-out and prepared.
Product Management is responsible for this part of the PI Planning Event

presentations. Product Management should be prepared to share the vision and the
Features that the teams will work on during the PI.
The Vision
You should plan to work with Product Management to define or refine the vision
prior to each PI Planning Event. Ensure that the vision communicates strategic
intent, is inspiring, and is both aspirational and achievable. Consider leveraging a
postcard from the future or a draft press release to help create the vision.
Figure 10.2 – Sample postcard from the future
Roadmap
Once we have articulated the vision, we recommend reviewing the Roadmap. We
should be able to see a direct correlation between the vision and the Features on the
Roadmap. The Roadmap is a useful tool showing not only where we are going but
also where we have been. Since PI Planning occurs during an IP Iteration, we
recommend showing what was completed in the last PI, as well as looking ahead at
the current PI and the next few PIs.
Table 10.1 – Example PI Roadmap
PRO TIP
Product Management may have several different Roadmaps that they use depending on context. I
recommend at least three Roadmaps:
A 3-5 year high-level portfolio Epic Roadmap
A 1-2 year high-level ART Epic/Feature Roadmap
A PI Feature Roadmap showing past, current, and next PI Features
Discussing Roadmaps is an opportunity for Product Management to congratulate

the ART on its progress thus far and celebrate what the ART has delivered and
accomplished. Also, as the ART matures, this can be a good opportunity to spend
10-15 minutes reflecting on the state of the ART one year prior.
Feature Review
After reviewing the Roadmaps, Product Management can delve into the Features
that they would like the ART to deliver in the PI. Remind Product Management and
the ART that this is a prioritized list and the teams may not be able to accomplish
everything. The prioritized list of Features is the input for PI Planning, not the
output.
NOTE
The teams should already be familiar with the Features being presented. PI Planning is not the time
to introduce new Features to teams. Leverage the ART Kanban to mature the Features for
consumption during PI Planning.
The Features presented should also include Enabler Features, and if there are
milestones that certain Features need to achieve, that should be called out here too;
make sure the milestones are captured on the ART Planning Board.
Product Management may want to involve the System Architect to present and
answer questions about any Enablers. Product Owners can get involved in
presenting and discussing some of the Features.
SAFe® materials typically refer to presenting the top 10 Features. This doesn’t
mean that you must have exactly 10 Features for each PI. However, it is a good
rough rule of thumb. If you find that your ART has significantly more or less than
10 Features in each PI, you likely need to spend some time maturing and sizing
your Features.
PRO TIP
There isn’t an exact science to the right number of Features for an ART, but the size of the ART can
be a factor. If you have 5 teams, then maybe 10 Features might be okay (2 Features per team), but if
you have 12 teams, then 10 Features don’t add up to one Feature per team.
Plus, a Feature (such as a story) needs to be small enough to fit inside a PI. So, I recommend that a
Feature takes 1-2 iterations to deliver, with 3 iterations as the upper boundary. Lastly, we need to
have enough Features not to starve the teams in the PI.
When creating slides for the Feature Review, consider creating a slide showing the
prioritized Features and then a slide for each Feature with the following details:
The Feature Title/Description
The Feature ID (the unique identifier assigned by an Agile tool)
The Benefit Hypothesis Statement
Acceptance Criteria
ART members should ask questions for clarification as needed on the Features and
vision. By the end of the Product Vision section of the PI Planning Event, ART
members should be aligned with the vision and understand the Features that need to
be developed and their levels of priority.
Architectural Vision and Development Practices

We often see this presentation as the most overlooked and the least prepared
briefing. However, it is one of the most critical ones. You are likely familiar with
the phrase “You can’t scale crappy code.” The same holds true with Architectural
Vision and Development Practices. As a Coach, ensure you are working with the
System Architect to help prepare.
The PI Planning schedule sets aside 1 hour for this conversation. From a logistics
perspective, taking a short break before this section is recommended so that folks
can return with better focus.
Depending on the solution your ART is building, this briefing will vary greatly
depending on your context (e.g., hardware versus software). Consider the various
roles that may need to share information in this section:
The System Architect usually presents the architecture, the Enablers, and common frameworks and models
UX leads will provide guidance on the UX
Development management or members of the system team will provide updates on tooling, environments,
the DevOps pipeline, or engineering practices
Enabler Features
This is an opportunity (if it has not already been taken during the Product Briefing)
to discuss in further depth the Enabler Features for the ART for the PI. We
recommend creating a slide for each Enabler Feature, including the information just
referenced. Also, include links to where teams can learn more or find additional
information, such as on models, NFRs, and so on.
Models
“A picture is worth a thousand words”
– Unknown
One often overlooked key component is architectural models and diagrams. While
it isn’t always necessary to go through the models during the briefing, ensuring that
teams know where the models are, how they can leverage them, who updates them,
and the different models that exist will secure alignment.
When reviewing the architecture, a System Architect uses models like Product
Management uses Roadmaps. Scenario models can help to show how information
flows through various systems. Architectural models can show how all the systems
interact with each other. Encourage the teams to reference and update the models
throughout the PI.
PRO TIP
Encourage Product Management and the System Architect to create scenario models for each
Feature to show who and what systems interact with each other as work flows through the system.
Development Practices
The discussion around development practices will be drastically different if the
ART is building hardware compared to an ART delivering software. Development
practices for a hardware ART may include safety discussions, how to best leverage
Model-Based System Engineering (MBSE), the use of 3D-printed doubles, and so
on. For a software-centric ART, this might include updates to versions of various
components, information about the build process and DevOps pipeline, discussions
about the environments, or other various engineering practices.
PRO TIP
MBSE is a systems engineering approach that focuses on developing and using models to support
the system requirements, design, analysis, verification, and validation throughout the life cycle of a
system. MBSE uses formal and graphical models to describe the system’s structure, behavior,
functions, and requirements.
MBSE replaces traditional document-based systems engineering with a more modern approach that
leverages computer-based modeling tools to create and manage system models. This allows for a
more agile and iterative development process, which enables engineers to quickly analyze and
validate system behavior, identify and resolve issues early in the development cycle, and make
informed decisions based on system models.
MBSE is widely used in industries such as the aerospace, automotive, defense, and healthcare
sectors, where complex systems require rigorous design and analysis processes. MBSE has been
shown to improve system quality, reduce development time and cost, and improve communication
and collaboration among team members.
This is a good time for the UX team to present information regarding the
experience we expect of the users and to share wireframes or information from UX
studies and updates to the existing systems. By the end of the Architectural Vision
and Development Practices section, the ART members should understand any
changes to their environments that may impact development. They should
understand the priority of working on Enablers and ensure that UX guidance is
incorporated into their stories.
PRO TIP
One last area I like to include in the Architectural Briefing is testing. This conversation should include
information about test data management, test doubles, testing infrastructure, automated test
coverage, and so on.
Planning Context
Now that the teams understand the impact of their work on the business, what the
vision and highest priority Features are, how the Features will be enabled, and the
architectural and engineering concerns that need to be addressed, we finally get to
talk to the teams about how to actually plan the work that has been articulated.
PRO TIP
If you look at the standard SAFe® PI Planning schedule, it reads Planning Context and Lunch. I have
found that having lunch first and then providing instructions and guidance allows teams to discuss
and digest everything they have learned. The conversations focus on the work to be done, not how to
do the work, and it helps to designate this lunch slot so that teams don’t start the team breakouts
early. Remember, food and breaks are important.
The Planning Context discussion typically takes between 30 and 45 mins depending
on the maturity of the ART and the consistency of location, tools, and practices
from PI Planning Event to PI Planning Event. It is typically presented by the RTE;
however, this is often an opportunity to provide growth opportunities to others on
the ART.
The process
When discussing the Planning Context, it’s important to share how the vision,
Features, and Enablers are transformed into the outputs of PI plans, objectives, and
the ART Board. The important takeaway is to draw a connection between what the
teams learned this morning and what they will deliver at the end of the event.
Reinforce why we are doing PI Planning.
PI Objectives
One of the biggest hurdles for many ARTs is PI Objectives. The RTE will want to
spend some time discussing the PI Objectives and can use slides from the PI
Planning Toolkit to help teams understand the expectations.
Remind teams that they should write Specific, Measurable, Achievable, Realistic,
and Time-bound (SMART) Team PI Objectives.
PRO TIP
Consider holding a PI Objective Writing workshop prior to the PI Planning Event to help the teams
learn how to write effective PI Objectives.
Lastly, remind the teams that Uncommitted PI Objectives are not a stretch or extra
work they will get done if they have time. Uncommitted PI Objectives are planned
work for which the team sees risks, a significant amount of uncertainty, or
significant dependencies and the team lacks confidence in their ability to deliver the
objective.
Watch that teams don’t have too many Uncommitted PI Objectives and don’t be
afraid to dig in and understand where and why the team feels they can’t commit;
then, work to help the team make any adjustments to the plan to improve
confidence.
As a note, we aren’t saying you shouldn’t have Uncommitted PI Objectives. We are

saying to have Uncommitted PI Objectives within reason. We use PI Objectives to
determine the ART’s predictability; a predictable ART meets between 80% and
100% of its PI Objectives. If your ART is consistently very near or above 100%,
push the teams to determine the real reason for Uncommitted PI Objectives and
challenge them to make them committed PI Objectives. You may also need to work
with the Business Owners to help them understand their responsibilities in
assigning Business Value.
PI Objectives are a measure of work completed. When Business Owners review the
PI Objectives at the end of PI, they are asking whether you completed all the work,
in the required timeframe, at the agreed level of quality.
However, when assigning Business Value at PI Planning, the Business Owner uses
a scale of 1 (lowest) to 10 (highest) and will typically assign the highest values to
the customer-facing objectives. However, they should also seek the advice of
technical experts, including the System Architect, who know that architecture and
other concerns will increase the team’s velocity in producing future Business Value.
PRO TIP
Consider having the team define the risks around the Uncommitted PI Objectives. This can help
identify whether the team has Uncommitted PI Objectives due to overplanning and creates an
opportunity to ensure that the team receives the necessary assistance to eliminate risk and possibly
commit.
PI Objective tips and tricks

Many teams and ARTs struggle with PI Objectives. Here are some tips and tricks to
help your ART. You will have to continually work with the ART to improve PI
Objectives; it doesn’t happen naturally.
To ease teams into PI Objectives, consider leveraging the concept of Iteration

Headlines or Intentions and evolve from there. An Iteration Headline or Intention is
a quick statement that articulates the key work the team is planning to deliver in the
iteration; for example, “Extra, Extra, the Shark Team is building the shopping cart
in Iteration 3,” or “the Pelicans intend to deliver credit card processing in Iteration
4.”

I was working with an ART that had a number of interns working with the teams. We shared the
example of headlines starting with the phrase “Extra, Extra, read all about it!” One of the interns
asked me later what that meant. She had no context for newspaper extras. We subsequently
changed the example and determined that we wanted the teams to create a “tweet” instead: “Sharks
will reduce the wait time for the queries by 25% #WaitTime #Reduction.”
As a Coach, ensure the team doesn’t write too many PI Objectives. The general
guidance for teams could be recommending the number of iterations plus one. So, if
you have five iterations in your PI, then recommend between four and six PI
Objectives for each team.
When we write PI Objectives, we often see them relate directly to the Features or
Enablers in the ART Backlog. Other times, they are an aggregation of a set of
Features, relating to milestones such as a trade show.
PRO TIP
Make sure to avoid your teams writing PI Objectives that only correlate directly to the Features. Too
often, I have seen team PI Objectives that look like this:
1. We will deliver Feature X in iteration 2.
2. We will deliver Feature Y in iteration 4.
Be sure to try and avoid this anti-pattern.
Consider leveraging one of the following formats:

To improve end users’ efficiency in ________ (things they already do), we will ________
To reduce or eliminate security risks, we will ________
To improve ________, we will ________
Assigning Business Value

Assigning Business Value is very tricky for many Business Owners. There are some
items that they should consider when assigning the value to avoid only associating
it with the bottom-line return on investment:
Regulatory value – Legal or infrastructural value that could result in fines, loss, or damage to the brand if
not achieved
Commercial value – A product or service that maintains or brings in new revenue

Market value – Functionality that differentiates the solution to stay competitive
Efficiency value – Functionality that improves the pipeline or reduces operating costs, including technical
debt
Future value – Functionality to support future needs including Enablers, proof of concepts, and spikes
As a Coach, you will want to work closely with the Business Owners prior to the PI
Planning Event to help them understand how to assign Business Value and what
they should be looking for.
PRO TIP
PI Objectives help the team understand the priority of the work they are completing from the point of
view of the Business.
Too frequently, I see teams that have 4 or 5 objectives with a Business Value of 10 and other teams
with most of their objectives sitting at 6 or 7. This can largely demoralize the team whose work is
viewed as less important.
One success pattern to leverage is to allow a single Business Value to be assigned to a PI Objective
for each team. For example, each team would have one 10, one 7, one 3, and so on. This helps the
team understand the priorities and Business Owners more evenly distribute value across teams.
Planning Context - Continued

We now want to make sure that the teams understand the layout of the room or
virtual space and their work areas. Each team should have a board that is clearly
labeled for each iteration, including dates, which includes spaces for capacity and
load. Each team should have a board for PI Objectives and a board for Team Risks.
Figure 10.3 – Example Team Iteration Board
Explicitly call out and ensure there is a board for the IP Iteration and it is clearly
marked to indicate work should not be planned in the Iteration.
PRO TIP
Capture the Capacity on sticky notes so it can be easily changed as plans change.
PRO TIP
We have added at the bottom of the Iteration Board example in Figure 10.3 an area to record
planned leave during the Iteration. Add the individuals’ names and the dates they will be absent. This
provides clarity when we review the Capacity.
PRO TIP
We have added an area called Iteration Headline to the bottom of the board. This helps other teams
understand dependencies and what is planned to be delivered in each Iteration. Ideally, all teams will
be able to review the stories and work on all the other teams’ boards; however, this is rarely the case.
The headline/tweet is a quick way during the Plan Readouts to share what is happening each
Iteration. It can subsequently be input for the Iteration Goals.
A legend in the team space is also helpful so that teams are consistently using the
same color sticky notes for each type of work – for example, Stories are green,
Enablers are yellow, Spikes are orange, Risks are red, Features are blue, and so on.
This provides the ability to quickly look at the space and ensure that we have a
good Capacity Allocation or that we don’t see all the Spike stories at the end of the
PI.
PRO TIP
You can change the sticky note colors from PI Planning Event to PI Planning Event if needed. When
purchasing sticky notes, often, multiple colors are bundled together. Inevitably, you will use more
Story sticky notes than Enabler or Spike sticky notes in a single PI Planning Event. You can rotate
the colors at the next PI Planning Event so long as all the teams are consistent, and you explicitly
clarify the colors.
Share and provide the Team Deliverables – Detail slide from the SAFe® PI
Planning Toolkit to the teams. Ensure that teams know how to track dependencies,
risks, and reserve capacity for unplanned activities such as maintenance and
production support. Clearly set expectations for the IP Iteration. Remind teams that
the PI Objectives should be drafted by the end of the first team breakout and will be
assigned their Business Value during the second team breakout session. Lastly,
ensure ART PI Risks are captured on the ROAM Board.

Now that you have drawn attention to the location of the ROAM Board, you can
naturally shift focus to the ART Planning Board. Ensure that Agile Teams and
Scrum Masters/Team Coaches understand the information that should be captured
on the ART Planning Board. Remind the teams that red string is a good thing. We
want to make sure we capture the dependencies, which will highlight bottlenecks so
that we can address or resolve them, thus enabling the ART to be able to meet its
commitments.
The ART Planning Board is a large grid that is customized for each ART and each
PI. The vertical columns identify the teams, each iteration, and a column for beyond
the PI. The rows capture milestones and include a row for each team and a row for
any additional teams/ARTs that this ART or its teams depend on.
Figure 10.4 – Example ART Planning Board
Ensure that you call out the various aspects of the ART Planning Board. You will
want to call out any known milestones (again). Highlight the order of the team
rows. Remind the teams to use blue (or another color you have determined) sticky
notes to capture when the Feature will be completed. Use red string and sticky notes
for the dependencies.
PRO TIP
Strategically place the teams on the ART Planning Board to minimize the length of the red string
between teams. For example, if you have two teams that typically have a lot of dependencies
between them, you might consider placing them near each other.
If you have any specific formats for how teams should capture dependencies, now
is a great time to address those practices. Some common items to consider are:
What the dependency is
Who needs what information, code, and so on
Who is responsible for providing it
When it is needed by
Remind the teams that they need to both agree to and accept the dependency when
it is placed on the board. Team members should meet with each other to discuss and
get agreement regarding the dependencies.
Take the opportunity to remind the Scrum Masters/Team Coaches that it is their
responsibility to ensure the ART Planning Board is continually updated throughout
the entire PI Planning Event, not just at the end of the second team breakout;
however, they do not necessarily have to be the person to do so.
PRO TIP
When identifying dependencies, I have found success in ensuring that the story numbers for both
teams are captured on the sticky notes on the ART Planning Board for the work being completed by
each team. I also have teams add dots to the sticky notes on their respective Team Boards with the
story number from the other team – yellow dots for the teams that need information from another
team and blue dots for the teams providing the information.
We are then able to cross-reference the Team Boards with the ART Planning Board. It also helps to
ensure that the teams discuss the dependencies with each other and don’t overlook key
dependencies in the frenzy of the PI Planning Event.
Before wrapping up the layout of the room and boards, consider calling out the
following:
Retrospective Boards
Kudos Boards
Team table locations
Establishing a Parking Lot/Help Needed board
Where to find Business Owners
Planning Procedures
We are now ready to move on to the steps we need the teams to complete for the
planning itself. Consider leveraging the slides from the SAFe® PI Planning Toolkit
and customize them to your environment and situation. We recommend including
the Planning Procedures slide (or a variation of it) as a handout for the teams. This
will help them stay on track. You will want to walk through the steps at a high level
and make sure to not read the entire slide.
The key items the teams need to execute are as follows:

Estimating Capacity for all Iterations: Leverage the planned leave area we recommended on the team
boards when estimating the capacity. Use historical data whenever possible. The formula for calculating
story points should only be used for teams that don’t have historical velocity.
Make sure to capture any holidays that are occurring in each iteration: You may want to create a
handout of observed holidays, especially if you have teams that aren’t geographically co-located. Don’t
forget to include regional and religious holidays.
Reviewing ART Backlog Items: The teams should already be familiar with the Features and Enablers by
this point; however, it’s possible that additional questions have arisen that need clarification.
Identifying Team Backlog Items: The team should identify the stories and estimate each. There are
multiple schools of thought on whether teams should come to PI Planning with their stories created and
estimated. Do what is best for your ART, its maturity, and its familiarity with the work.
PRO TIP
For stories identified during PI Planning, break traditional planning poker guidance, and use majority
wins, playing only one round. If someone is overly passionate about the estimate, they will typically
speak up and the team can then decide whether they agree with that person’s perspective.
Remember that in PI Planning, we are looking to understand what we can and can’t deliver and then
make a trade-off as needed. Don’t let teams go down a rabbit hole on every story or argue points
indefinitely.
Identify any hard delivery or commitment dates: Ensure that the team is aware of the milestones and
any dates or lead times that may be needed to meet certain deliveries. Consider adding these to both the
ART Planning Board and the Team Boards.
Identify, discuss, and address interdependencies continuously: This is the most important aspect of PI
Planning. Ensure you remind the teams again about your practices for capturing dependencies.
Load stories into the iterations: Teams will add sticky notes to each Iteration Board, completing the
highest priority Feature first and then the next until capacity is reached. Consider guiding teams to split
any story that is eight or more points.
State, negotiate, and gain agreement on PI Objectives: The PI Objectives should be captured on each
team’s board. You may want to consider having the teams write the first draft on large sticky notes to allow
them to be refined before finalizing them on Day 2.
Identify impediments and risks: The team should capture both Team and ART PI Risks. You may want
to consider providing guidance on how the risks should be written.
Prepare to present the plan: The team should identify who will be responsible for presenting the plan
readouts. Often, this is the Product Owner or Scrum Master/Team Coach; however, any team member can
present it.
(Bonus) Iteration Headlines: If you decide to leverage the Iteration Headlines, make sure those are also
created to be shared during the Plan Readouts.

I have Coached numerous ARTs and have yet to see an ART that could take a Feature and
completely decompose, estimate, and plan it during the PI Planning Event. I strongly encourage
communicating the Features to the teams and breaking them down prior to PI Planning.
This does not mean that all the stories are fully refined with full Acceptance Criteria and would meet
the Definition of Ready, just that there is enough information that the team understands what the
story is and can give it a quick estimate.
I would expect that the stories in the first two iterations would be more refined than those in iterations
3 and 4.
You will want to watch that the teams aren’t coming into PI Planning with everything planned and
spend their time just putting the stories on sticky notes and attaching them to the wall. If this is
occurring, teams are overplanning and subsequently losing the value of PI Planning, so
conversations will need to occur about the work being done.
The challenge is to find the right balance between not identifying any of the stories and having all the
stories ready.
Planning Acceptance Criteria

As we near the end of the Planning Context section, we want to ensure that
everyone understands the Acceptance Criteria for completing PI Planning. There
are three key criteria:
All iterations are planned and plans are accepted
PI Objectives have been created and Business Value assigned
ART PI Risks have been captured
You may want to consider some additional Acceptance Criteria to provide

additional clarity to the teams, including the following:
The Load should be less than the Capacity for each Iteration
Dependencies have been captured and agreed to
The ART Planning Board reflects team plans
Before dismissing the teams to their breakout rooms, take the opportunity to answer
any final questions from the participants. Then, with excitement and enthusiasm,
send the teams to the breakout rooms.
This concludes the Planning Context and the Day 1 presentation part of PI
Planning.
Team breakouts
There are two different team breakout sessions that occur during PI Planning, one
occurring each day. The Day 1 breakout is 3 hours long. During this time, the teams
develop their plans, resolve dependencies, identify risks, write PI Objectives, and
prepare their draft plans.
There is a lot of discussion and decision-making that happens during those 3 hours.
The teams should be fully engaged.
During the breakouts, the RTE, Product Management, the System Architect, and
Business Owners should circulate among the teams, answering questions and
providing clarification as needed. You will want to watch that someone doesn’t get
“stuck” with a team and inadvertently de-rail the planning process for the team.
Coach Sync checkpoints

Every hour or so, the RTE will hold a Coach Sync checkpoint. During the Sync, the
RTE will review a list of activities and the progress the teams are making toward
their goals. The SAFe® PI Planning Toolkit includes a template for the Coach Sync
checklist. Feel free to tailor it to your ART and the timeboxes when adjusting for
distributed PI Planning.
PRO TIP
Give your Scrum Masters/Team Coaches the Coach Sync checklist before PI Planning so they know
where they need to be in the process hour by hour.
The Coach Sync creates several opportunities. First, it gives the Scrum
Masters/Team Coaches a chance to break away from teams for a few moments to
catch their breath. Second, it provides an opportunity in the meet-after to discuss
any dependencies. Third, it’s a good time to spend a few minutes updating the ART
Planning Board. Fourth, it creates a natural break in the timebox for folks to get
coffee, use the facilities, and so on.
At the end of the Team Breakout session, consider taking a short break and then
bring the groups back together for the Draft Plan Reviews.
Draft Plan Reviews

The Draft Plan Reviews follow a structured format for each team. It is helpful if the
teams know what order they will be presenting in, but not absolutely necessary.
Anyone from the team can present the draft plans.
We are looking for the teams to present the following information:

The Capacity and Load for each Iteration
The Draft PI Objectives
The ART PI Risks and Impediments
Q&A
We advise you not to dive into the stories, as this can quickly cause the review to
become extremely lengthy. Additionally, your PI Objectives should be clear enough
that there isn’t a need for additional clarification. ART members should take the
opportunity to ask questions about the work and the plans the teams are planning to
deliver.
PRO TIP
I have rarely found that teams are able to write clear SMART PI Objectives, even with extra work and
training, but I have found that teams are easily able to summarize the work they are planning to
complete in an iteration with a single sentence, which is why I promote the use of Iteration
Headlines/tweets.
I typically give the team a script pattern to follow. Here is an example:
“In Iteration 1, Team Lizard has a capacity of 26 and a load of 25. Our headline is: Building the initial
UI and data structure for the shopping cart.
In Iteration 2, we have a capacity of 28 and a load of 28. Our headline is: We will finish the shopping
cart Feature.”
Note the call-out here of when the Feature will be completed. I even encourage the teams to capture
the Features as sticky notes on their boards, not just on the ART Planning Board.
After going through each iteration, the presenter then shares their PI Objectives and any risks and
impediments. I have encouraged Business Owners to take some notes and they can help the teams
improve their PI Objectives during the Team Breakout on Day 2.
At the end of the Draft Plan Reviews, make sure to thank all the ART members for
their hard work and celebrate with cheers and applause. Some ARTs even have
optional dinners or happy-hour options arranged. If yours does, share the details
and then dismiss the ART, except for those needed for the Management Review and
Problem-Solving.
The Management Review and Problem-Solving part of PI Planning can be the
hardest. The RTE or Coach facilitates it. It should be allotted one hour; however,
depending on the challenges faced by the ART, some discussions and work may
continue beyond the timebox. The facilitator will need to pay attention to the
timebox and keep discussions moving.
One technique is to have the participants move around the room, leveraging the
ART Board and each of the Team Boards.
Some key questions to address during this session are as follows:

What did we just learn?
Where do we need to adjust the vision? Scope? Resources?
Where are the bottlenecks?
What Features must be de-scoped?
What decisions must we make between now and tomorrow to address these issues?
You will want to capture notes and action items and decisions that are made during
this time, as they will be presented to the teams to make the necessary adjustments
in their Day 2 breakouts.
PRO TIP
Do not bring in dinner (coffee could be helpful) for the participants in the Management Review and
Problem-Solving session. It prolongs the day and hunger is a good deterrent to lengthy
conversations.
Encourage participants to make decisions quickly and then join their colleagues at dinner/happy hour.

Participants
Identifying the participants for the Management Review and Problem-Solving
session can be difficult. You will find that a lot of people want to be involved or
believe they should be involved. Setting expectations prior to the PI Planning Event
helps to smooth the process.
Depending on your organization, the participants will vary. Keep the group as small
as possible. If you find that there are more than your typical Agile team size of
7+/-2 participants, you will want to work to minimize that number. Here is a
general success pattern for participants:
The RTE
Product Management
System architects
Business Owners
Executive leadership (Epic owners)
PRO TIP
I often see Product Owners and Scrum Masters/Team Coaches included. If you do choose to include
the Product Owners and Scrum Masters/Team Coaches, ensure they understand the expectations
and that they should be observers, not active participants. It’s my experience that they often cause
delays in decision-making and lengthen the session.
Instead, encourage them to retire and get a good night’s sleep and then update them in the morning,
prior to the start, with anything they specifically need to be aware of.
By the end of this session, participants should agree regarding the decisions that
have been made. Identify who will present the changes and decisions to the teams
and who will create a slide with these decisions.
If following the traditional schedule, this formally concludes Day 1 of Planning.
Day 2
In the same spirit as Day 1, kick off and welcome the participants back to PI
Planning.
Planning adjustments
A 30-minute timebox is allocated to review the decisions made during the
Management Review and Problem-Solving session. Typically, the person that owns
the actions and adjustments will present the adjustment and answer any questions.
For example, if it is a scoping issue, then Product Management will discuss it while
if it is related to Architecture, then the System Architect would clarify the changes.
Ensure that the teams have an opportunity to ask questions about the changes. You
may want to consider planting a question or two to break the ice.
Day 2 team breakouts

Teams use the breakout on Day 2 to refine and adjust their plans based on feedback
from the Management Review and Problem-Solving session. Teams may need to
replan based on Features that have been de-scoped or risks that have been resolved.
The teams have 2 hours for this session. Encourage the Business Owners to
circulate to each team early and provide feedback and guidance on the PI
Objectives, allowing the team to refine them before the Business Owner assigns
Business Value near the end of the time box.
As on Day 1, the RTE, the System Architect, and Product Management should also
circulate, and the RTE will continue to hold Coach Syncs.
Here are some key reminders before sending the teams into the second breakout
session:
Teams have 2 hours or until the end of the timebox to complete their plans
Business Owners will circulate to provide guidance and Business Value to the PI Objectives
Coach Syncs will occur at the specified time(s)
Continue to identify dependencies, ensuring the ART Planning Board is updated
Make sure to capture any Risks and Impediments
Lastly, remind the teams to have fun
These are critical for the teams to stay on track and complete their plans. If teams
find they have some extra time, you can encourage them to review the other teams’
boards prior to lunch and the Final Plan Review.
Final Plan Review and Commitment

Per the standard schedule, this section is titled Final Plan Review and Lunch. We
encourage you to consider holding lunch first and then starting the Final Plan
Review. This gives the teams a bit of a buffer to wrap up planning if needed.
The Final Plan Reviews occur in the same fashion as the Draft Plan Reviews.
SAFe® guidance is to share any changes made to the draft plan; however, consider
restating the entire plan, as some ART members may have a different perspective
by this point, which may lead to additional questions.
Once the team has shared the Capacity and Load, PI Objectives, and Risks and
Q&A is completed, there is one step that is often overlooked that needs to be
completed for each team; the Business Owners are asked whether they accept the
team’s plan.
Ensure that this step is not skipped. Ideally, any worries or concerns from the
Business Owners will already have been addressed; however, questions asked by
other ART members may shed new information that may cause the need to replan.
If the team’s plan is not accepted, the PI Planning schedule has time built in for
additional rework. Whatever has caused the plan to not be accepted may determine
the remaining schedule for the day. You may need to decide to replan for a certain
amount of time and then restart the review, or you may want to continue the reviews
and Risks and then replan and finish the event activities.
PRO TIP
You may find that after lunch, PI Planning participants are in a bit of a food coma. If you find this to be
the case, you could have everyone stand up for 15 seconds between presentations to help keep
participants actively engaged.
Once we have completed the Final Plan Reviews, it’s best to take a short break and
then begin addressing ART PI risks.
ART PI Risks
During the course of the PI Planning Event, teams have added items to the ROAM
Board. ROAM is the methodology we follow to address risks. A common format to
capture risks is “if X, then Y.” Consider leveraging this format and capture the team
or individual that identified the risk for additional follow-up.
Each risk will need to be ROAMed and placed in the appropriate quadrant:
Resolved: The risk has been addressed and is no longer a concern
Owned: Someone has taken responsibility for the risk
Accepted: Nothing more can be done and if the risk occurs, the release may be compromised
Mitigated: There is a plan to adjust as necessary
Figure 10.5 – Example ROAM Board
As you go through the Risks, you will want to capture additional notes about the
Risk, including who owns the Owned Risks or notes on the mitigation strategy.
Once all the ART PI risks have been ROAMed, we can move on to the Confidence
Vote.
The Confidence Vote

The Confidence Vote is held once the ART PI Risks have been addressed. There are
technically two votes that occur. The first vote is the teams voting on their own
confidence in meeting their PI Objectives as a team. The second vote is held to
express confidence in the collective plan of the ART and all the teams.
The Confidence Vote is usually conducted as a Fist-of-Five vote, where members

hold up the number of fingers corresponding to their level of confidence, with 1
being the lowest and 5 the highest.
Figure 10.6 – Fist-of-five Confidence Vote (© Scaled Agile, Inc.)
The confidence vote comes with a level of commitment to the following:

The teams agree to do everything in their power to meet the agreed-to objectives
If the teams identify that they will be unable to meet the agreed-to objectives, they will escalate
immediately so that corrective action can be taken
For each vote, if the average is 3 or above, we should accept the commitment; if
less, then we need to understand why and rework the plan. Any person voting 2 or
below should be given an opportunity to voice their concerns. Based on the
concerns, you may need to consider re-voting and subsequently replanning if
confidence drops.
PRO TIP
As the Confidence Vote occurs toward the end of the day, often, attendees are tired and ready to go
home. If this isn’t their first PI, they are more aware that low confidence means staying later and will
sometimes vote 3 to avoid having to stay longer or being called out.
You may want to consider an approach where you hear from everyone with a level of confidence of 1
or 2, and then get a couple of volunteers from the 3s, 4s, and 5s to share why they voted as they did.
Once you have agreement on the Confidence Vote and no replanning is necessary,
or replanning is completed, it’s time for the PI Planning Retrospective.
PRO TIP
One of my colleagues uses the Palm-of-Four instead of the Fist-of-Five. This prevents people from
sitting on the fence with a 3. You are either a 1 or a 2 with relatively low confidence or a 3 or a 4 with
relatively high confidence.
The Retrospective
The PI Planning Retrospective is a key part of the Planning Event, as this provides
insight into how we can continuously improve. One of the challenges of the
retrospective is leveraging the feedback constructively.
You won’t be able to please everyone and will regularly get feedback about
common items. The food was good or bad, the room was hot or cold, there weren’t
enough power cords, the technology sucks, and there was too much time or not
enough time for breakouts. When reviewing the retrospective results, look for
improvement areas beyond these types of items.
PRO TIP
Consider adding and subsequently reviewing a Kudos board before dismissing the ART and closing
out PI Planning.
You may also want to capture the retrospective items as folks exit the PI Planning Event. Usually,
folks are pretty tired by the end of the event, and asking folks to add a sticky note to each board
before leaving is the exit criteria for the event.
There are plenty of options for Retrospectives you can execute at the end of the PI
Planning Event; ensure you keep it simple to ensure that participants are able to
easily provide valuable feedback.
Close Out
Depending on how you execute the retrospective, you may want to combine or
provide close out guidance prior to the retrospective.
In the Close Out, you will want to provide instructions to the team on how they
should leverage the plans into their Agile Tools. Remind them of key dates and
events. Ask for any necessary help cleaning up the rooms/spaces if necessary.
Be sure to celebrate the hard work that all the teams have completed. Also, don’t
forget to take some pictures. Get photos/screen captures of the teams and the ART.
You can leverage these photos at future PI Planning Events and in I&A.
Lastly, be sure to grab photos or screen captures of each of the team boards, the
ART Planning Board, and ROAM board. You may need these for reference in the
future and to facilitate transcription into an Agile Tool.
Congratulations on a successful PI Planning Event. It’s a long event with lots of

details, coordination, and decision-making. In this section, we reviewed all of the
key parts and understood the various aspects of the event. Let’s now take a look at
some of the challenges you may encounter with remote or distributed PI Planning.
Remote/Distributed PI Planning
Let’s begin by clarifying the differences between remote and distributed PI
Planning. Remote PI Planning is PI Planning where all participants are not located
together. Distributed PI Planning is when we have participants executing PI
Planning from multiple locations, where they are face-to-face in those locations.
We do not recommend having combined Remote and Distributed PI Planning if you

can avoid it, although it is much easier post-Covid-19 than it was before due to the
technological improvements made by most organizations.
When executing either type of planning, you will want to pay particular attention to
several items. You will want to ensure that you have the best possible technology
and tools you can get and that the participants know how to use and leverage them.
This includes the breakout rooms, chat functionality, whiteboard functionality, and
multiple concurrent users in the same workspace.
Particularly at a remote PI Planning Event, you may want to consider spreading the
event over a greater number of days for shorter durations. For example, consider
four 4-hour days rather than two 8-hour days. Zoom fatigue is a real thing, and by
shortening the days, you will likely get better engagement. Be sure to check out
Appendix B for some example schedules.
For both remote and distributed events, you will likely need to consider the time
zones that individuals and teams live in. Leveraging multiple shorter days is one
option; another consideration is to alternate staying up late or getting up early from
PI Planning Event to PI Planning Event.

An ART had team members from the US and India. The US participants were located primarily in
Phoenix, Chicago, and Baltimore, spanning 3 or 4 time zones depending on the time of year. The
teams in India were primarily located in Chennai.
To minimize the number of locations, the team members from the US would fly into Baltimore, and PI
Planning was held at two distributed sites. At each site, we had one large room and five breakout
rooms, one for each team, with conferencing technology so that the teams could hear and see each
other between the sites. (Holding distributed PI Planning in a single room is too noisy for teams to
effectively communicate with each other.)
For the first few PI Planning Events, we held them from 8AM EST to 4PM EST and colleagues from
India would end up working late into the night. Based on feedback from the teams, we began
experimenting with alternating schedules and changed locations. The teams decided it wasn’t fair for
the teams in India to always work late.
We first tried starting at 3:00 AM Eastern Time/1:30 PM in Chennai to have more overlap. The teams
decided that staying up late was easier than getting up that early.
For the second experiment, we held PI Planning in Phoenix and started at 6:00 PM Pacific Time/7:30
AM in Chennai and planned until 2:00 AM Pacific Time/3:30 PM in Chennai. The teams preferred this
experiment to the first.
The teams continued various experiments and ultimately settled on spreading PI Planning over 3
shorter days and alternated between locations and start times. Sometimes, they would start at US
5:00 AM Eastern Time, and the next time, they would start at 5:00 PM Pacific Time.
The key here is that the teams worked to identify a plan where the burden wasn’t always on one
group to stay late or get up early. The executives appreciated that the teams were working together
and accommodated their schedules to participate.
Remote and Distributed PI Planning are challenging, so be creative in finding

solutions to make them easier. Consider sending PI Planning packages to
participants; these could contain food, funny hats, and so on. Make it fun and have
a good time, even if everyone can’t be together.
PI Planning is a key event for the ART. A successful PI Planning Event sets the
ART up for future success and the ability to deliver on their commitments. PI
Planning is fairly rigid and prescriptive in its schedule and outcomes. When first
starting, we recommend staying as close to the actual timeboxes and schedule as
possible. Ensure that teams are coming in prepared but not planned, and most of all,
have fun.
The I&A Event

The last formal event of the PI is the I&A event. This is a three-part event that
occurs during the IP Iteration before PI Planning. The three parts are the PI System
Demo, Quantitative and Qualitative Measurement, and the Retrospective and
Problem-Solving Workshop. All ART members and Stakeholders participate. The
intent of the event is to foster relentless improvement and drive a Continuous
Learning Culture.
The PI System Demo

The PI System Demo is the first part of I&A. This demo shows all the Features that
the ART developed during the PI. It is different from the Iteration System Demos in
that the audience is broader and the demo tends to be more customer-focused and
polished.
This demo should tell a story. Explain and show the customers’ journey to using the
Features that were developed. We expect this demo to take about 1 hour. There is
no requirement that every team presents individually.
Product Management typically leads this demo and works with the teams ahead of
time to plan the demo, stage data, and execute a dry run.
PRO TIP
The PI System Demo requires preparation. The RTE should consider scheduling several meetings
leading up to the demo to ensure adequate preparation. You may want to consider having the
Business Owner be the practice audience so they can already begin thinking about the Actual
Business Value (ABV) for the PI Objectives.
Product Management should show the Features that have been completed and want
to show and tell the story from the user’s perspective. Be sure to highlight and call
out the benefits that the Features deliver provide, as defined in the Benefit
Hypothesis for each Feature.

One of the worst PI System Demos I ever attended was over 4 hours long and each team showed
almost every story they had worked on during the PI. There was no continuity between the teams, no
alignment with the Features they had completed, and it felt like a big, long iteration demo.
There was a misunderstanding of the intent of the PI System Demo and the belief was that the teams
should show all of their work so that the Business Owners could see what they had accomplished so
they could get the maximum Business Value.
Quantitative and Qualitative Measurement

The Quantitative and Qualitative Measurement section of I&A is an opportunity to
review and reflect on what has been delivered. We use this opportunity to review
any quantitative and qualitative metrics that are being collected and understand
their data and trends.
A key metric we look at is the Predictability Measure. The Predictability Measure is

derived from the Planned and Actual Business Value (ABV) from the PI Objectives.
PRO TIP
Work with the Business Owners in advance to determine the Business Value. The dry runs of the PI
System Demo are a great time to start socializing this. Also, consider setting up a meeting with each
team and the Business Owners to review the PI Objectives and to have a conversation about each.
This serves two purposes. First, it helps the teams and the Business Owners understand each
other’s perspective, and, second, it often helps drive improvements in writing better PI Objectives in
the future.
The Predictability Measure is a calculation that uses the planned versus the Actual
Business Value of all the teams collectively.
Remember, when assigning Business Value at PI Planning, the Business Owner

uses a scale of one (lowest) to ten (highest) and will typically assign the highest
values to the customer-facing objectives. However, they should also seek the advice
of technical experts, including the System Architect, who know that architecture
and other concerns will increase the team’s velocity in producing future Business
Value.
Then, when Business Owners review the PI Objectives at the end of PI and assign
ABV, they ask whether you completed all the work, in the required time frame, at
the agreed level of quality. The PI Predictability Measure is a measure of work
completed, not the “actual value” received, which is why many find the term
“actual value” misleading and often misunderstand it.
This metric is a trend metric that needs at least three PIs worth of data to really
begin to be of value to the ART’s ability to predictably deliver work.
Figure 10.7 – ART Predictability Measure example (© Scaled Agile, Inc.)
PRO TIP
Don’t let the teams game the Predictability Measure by having too many Uncommitted PI Objectives
during PI Planning.
Also, ensure that teams don’t become demoralized if they don’t receive all the Planned Business
Value. This is why the conversation between the Business Owner and teams is important. It’s
possible that the landscape has changed and what was initially very important no longer is, or that
the expected benefits weren’t realized.
While the key focus is on predictability, many factors feed into an ART’s ability to
deliver predictably. Consider leveraging other metrics during this conversation as
well, including the following:
The number of deployments and releases
An ART Cumulative Flow Diagram
The Average Cycle Time for Features and Stories
PI Feature Throughput
Defect counts and ratios
DevOps pipeline metrics
Ensure that whatever metrics you present have context and aren’t being used in a
way that will “punish” teams. Use the metrics to highlight areas that teams may
want to consider as opportunities to look at during the Problem-Solving Workshop,
or celebrate where the teams are doing a great job.
The Retrospective and Problem-Solving
Workshop
The Retrospective and Problem-Solving Workshop is the last part of I&A.
Attendees include all ART members, key Stakeholders, Business Owners, and
management. The timebox for this is typically 2 to 2.5 hours.
The Retrospective
The retrospective typically takes 30 minutes or less to identify a few issues that
need to be addressed during the Problem-Solving Workshop. Once the issues have
been identified and agreed to, they become the input for the Problem-Solving
Workshop.
You can use any format you want for the retrospective; however, we recommend
keeping it simple, as the intent is to identify challenges. Most of the time, the
facilitator (typically, the RTE) will use a “what went well, what didn’t go well”
format. Celebrate what went well and then leverage a quick dot vote on what didn’t
go well to identify the key problems to solve.
PRO TIP
The size of your ART can inform the number of problems you may want to take on during the
workshop. I typically use the number of teams as a guide for the number of problems to be solved.
Due to additional Stakeholders, Business Owners, and so on, the teams solving each problem will be
slightly larger than a typical Agile team.
Once you have identified your problems, let folks vote with their feet and go work on the problem that
resonates the most with them. Encourage teams to split up. If you notice one problem has a lot of
people and another has only one or two people, consider splitting the large group into two and asking
the small group to join another.
If this isn’t your first I&A, make sure during the retrospective (or potentially as part
of the PI System Demo if applicable) to recognize the progress made toward
delivering the identified improvement items from the last I&A Problem-Solving
Workshop.
The Problem-Solving Workshop

The Problem-Solving Workshop is designed to identify the root cause of problems
or issues that the ART is experiencing and identify solutions to improve them. The
Problem-Solving Workshop is typically allotted 2 hours and has six key steps,
concluding with a readout and adding the improvement items to the Backlog and PI
Plan.
Each group will need a Problem-Solving Board to capture their work. The board
has an area for each step in the process and a fishbone diagram.
Figure 10.8 – Problem-Solving Board (© Scaled Agile, Inc.)
PRO TIP
Ensure that you have identified the number of problems you will solve during the event and have
facilitators lined up to support each group. Spend time with the facilitators prior to the event to ensure
they know how to facilitate each of the steps in the workshop and what to do or who to go to if they
get stuck.
Step 1 – agreeing on the problems to solve

This step will set the context for the remaining five steps. You will want to ensure
that the teams are clear on the problem. They will want to state what the problem is,
when it occurred, where it is happening, and, most importantly, the impact the
problem is causing.
As we previously mentioned, the retrospective is a great place to identify problems.

You might also consider leveraging Team and Technical Agility Assessment results.
Don’t be afraid to use a pre-identified issue as one of the problems.
Step 1 is typically allotted 15 minutes.
Step 2 – performing a root-cause analysis

Once you understand a problem, your groups will want to really understand the root
cause of this issue. SAFe® leverages a fishbone diagram, also known as an
Ishikawa Diagram, and the 5 Why’s.
One common mistake folks make is misunderstanding that the bones on the fish are
not static. Teams can leverage those as a starting point and add or change the bones
as needed.
Step 2 is typically allotted 25 minutes.
Step 3 – identifying the biggest root cause

When teams get to this step in the process, they often get stuck realizing that they
are just looking for the team to generally agree on what they believe ultimately was
the root cause of the problem. We recognize we won’t get 100% agreement, and we
are looking to identify 20% of the causes that are responsible for 80% of the
problem. This is known as a Pareto Analysis.
PRO TIP
Make sure that the facilitators don’t let teams go down a rabbit hole of solutions during this step.
Remind them they will get the chance to brainstorm solutions in Step 5.
The simplest way to identify biggest root cause is by letting the team dot-vote on
what they believe the biggest root cause is and then counting the votes. Now that
the team has “agreed” on the root cause, we can restate the problem.
PRO TIP
The 5 Why’s are often overlooked or shortened by teams. It seems redundant to ask the same
question over and over and over and over and over again. However, teams that are diligent in this
process and continually work to answer the question will often discover that what they thought was
the real reason isn’t. Asking five times helps ensure that teams are putting in the work and effort to
really understand the issue at hand.
Here’s a great video to check out about the 5 Whys: https://www.youtube.com/watch?

v=BEQvq99PZwo
Note: sometimes, four whys are sufficient and sometimes it takes six. As a facilitator and Coach, the
key is to not let the teams stop asking why too early.
Step 3 should only take a few minutes to complete.
Step 4 – restating the problem

Now that the team understands the challenges around the problem and has agreed
on the root cause, we want the team to take a few minutes and restate the problem
with their new understanding. The teams should ensure they include the What,
When, Where, and Impact in a problem statement, similar to Step 1.
Step 4 typically takes about 10 minutes to complete.
Step 5 – brainstorming solutions

The brainstorming session tends to be the most fun and easiest for the teams.
Encourage the team to come up with as many ideas as possible. Consider
timeboxing this so that the ideas can be reviewed, aligned, and combined, and then
dot-vote to identify the three solutions the team believes will solve the problem.
Step 6 – creating Improvement Backlog Items

From the brainstormed solutions, create stories and Features that can be consumed
in the following PI Planning. Depending on the number and type of solutions
identified, the RTE will work with those necessary to ensure the identified
improvements are planned.
PRO TIP
Sometimes, the challenges that the ART identifies and provides solutions for aren’t within the scope
of the ART to resolve. The RTE may need to leverage the Business Owners and management to
address the problems and the backlogged solutions that the teams have created.
Closing out
Give each team the opportunity to share their results and recommendations.
Timebox this activity to 10 to 15 minutes if possible.
As the Coach or RTE, we encourage you to review all of the causes the teams
identified, as well as the brainstormed solutions. You may identify some additional
quick-win items that can be incorporated that didn’t potentially meet the 80/20 rule
or receive the most votes but would still improve and help the ART.
PRO TIP
Discuss the improvement item progress at various ART Events, such as the ART Sync, Coach Sync,
and/or the Iteration System Demos.
Logistic considerations
When holding the Problem-Solving Workshop, you will need to work through some
logistics, both face-to-face and remotely:
Ensure you have a space for each group to work in. If face-to-face, you can send teams to different areas
around the room. If virtual, you will want to have breakout rooms set up for each problem.
Make sure you have the instructions for the steps with examples available for reference during the event.
Consider paper handouts if face-to-face.
Pre-draw or pre-print the fishbone templates. If virtual, make sure that the workspaces can have multiple
contributors and that the template is available online.
Keep timers for each step and make timebox announcements to help keep the teams on track. Virtual
groups may need to consider a way to message multiple teams at once.
There are a few key takeaways from I&A. First, we see how we are doing by
demonstrating the actual system. Second, we leverage hard data to verify and
validate our progress. Third, we take the opportunity to reflect and then determine
how we can improve in the future. Too often, many folks gloss over the importance
of I&A. Make sure you work with your teams to get the most value possible.
Summary
The PI Events are key events and define the success of the ART. PI Planning kicks
off the ART and ensures alignment between the teams in order to deliver a quality
solution. I&A at the end of the PI highlights the work that was delivered and creates
an opportunity for improvement, enabling the ART to deliver even higher-quality
results faster and with greater predictability.
Further reading
1. PI Planning: https://www.scaledagileframework.com/pi-planning/
2. Vision: https://www.scaledagileframework.com/vision/
3. SAFe® PI Planning Toolkit: Available from SAFe® Studio for RTEs and SPCs in good standing
4. ART Kanban: https://www.scaledagileframework.com/art-and-solution-train-backlogs/
5. Features: https://www.scaledagileframework.com/Features-and-capabilities/
6. Inspect and Adapt: https://www.scaledagileframework.com/inspect-and-adapt/
7. The Rollout by Alex Yakima

Part 3: Portfolio
This part will cover what isn’t team- or Train-specific but is needed by a Lean-
Agile enterprise. We will learn to avoid pitfalls in the portfolio and we will cover
why Enterprise Strategy, Leadership Alignment, and Continuous learning are
important in shaping and changing the culture; the implications of not having these
pieces; and how to garner alignment at the highest levels of the organization. In
addition, we will look at the mechanics of building, operating, and governing your
portfolio.
This part has the following chapters:

Chapter 11, Enterprise Strategy
Chapter 12, Building Your Portfolio
Chapter 13, Establishing Lean Budgets
Chapter 14, Portfolio Backlog Management
Chapter 15, Measuring Progress
Chapter 16, Leadership Alignment

11
Enterprise Strategy
If a man does not know what port he is steering for, no wind is favourable.
– Roman philosopher Seneca
If an organization does not have a clear strategy, parts of the organization will, at
best, not be aligned and, at worst, compete against each other like a tornado leaving
a path of destruction. Whereas if you have a strategy that creates alignment, it is
like a trade wind pushing faster to your destination.
An Enterprise Strategy makes it possible to create a long-term plan and have a

method to achieve objectives and goals, which are key to any type of strategic
planning.
In addition, in this chapter, we will consider how Enterprise Strategy for an

organization needs to adapt in the same fashion that teams adjust. Leveraging the
ability to adapt and change is what keeps organizations relevant and allows them to
continue to grow.
We’ll cover the following topics in this chapter:

What do we mean by strategy agility?
How is Enterprise Strategy different from portfolios?

Enterprise Strategies – often called competitive strategies – identify how each
individual enterprise will compete within its respective market and industry.
Superior enterprise strategies are imperative to the success of the business because
they link the business to its markets. So, enterprise strategies form the foundation
for a successful business.
Unfortunately, most enterprises don’t have a clear understanding of strategy! The

following quote from Geoffrey Moore is indicative of the conversations that we
have had with senior leaders, which is really concerning:
“Most strategy dialogues end up with executives talking at cross-purposes
because…nobody knows exactly what is meant by vision and strategy, and no
two people ever quite agree on which topics belong where.
That is why, when you ask members of an executive team to describe and
explain the corporate strategy, you frequently get widely different answers. We
just don’t have good business discipline for converging on issues this
abstract.”
– Geoffrey Moore, Escape Velocity [1]
PRO TIP
I try to research a company’s strategy before starting an engagement; you can gain valuable insights
from its website or its published financial statements. Failing which, ask them for their strategy
(which, more often than not, has been created by a third-party consulting firm that is now gathering
dust somewhere in someone’s drawer!).
A strategy is best described as a plan of action to achieve the mission of the

enterprise. Therefore, defining a strategy may be the most critical activity of every
enterprise, which makes it even more surprising many companies outsource this to
a third-party consulting firm to devise.
An effective strategy answers four critical questions about the business:

What customers and markets do we serve?
What products and solutions do we provide?
What unique value and resources do we bring to the endeavor?
How will we extend them in the future? (© Scaled Agile, Inc.)
From a Scaled Agile Framework (SAFe®) perspective, we recognize that we are

not experts in defining strategy. It is not what we do as SAFe® Practice Consultants
(SPCs); we need to understand the basic constructs that make them up and
recognize that it needs to exist because it provides two critical outputs:
Portfolio budgets
A set of Strategic Themes for each portfolio
Businesses have various approaches to developing an Enterprise Strategy; however,

a model adapted from Jim Collins’s Beyond Entrepreneurship shows a number of
elements of Enterprise Strategy formulation [2]:
Vision: This represents the future state of what the business wants to be. It’s persistent and long lasting.
PRO TIP
If you are presented with a vision that is a 200-slide PowerPoint deck, then talk to the leadership
team to try and persuade them to make something more engaging. There are a lot of good examples
of visual and engaging representations of a vision, for example, a short video or a postcard from the
future. My favorite example is from Bosch – Live like a Bosch [3].
Mission: This identifies the business objectives that implement the enterprise vision and frame the
strategy. They may be somewhat more temporal and likely be incremental in that each builds on the one
that came before.
Core values: Core values are the fundamental beliefs of the organization. These guiding principles dictate
behavior and can help people understand the difference between right and wrong. Core values also help
companies to determine if they are on the right path and fulfilling their goals by creating an unwavering
guide.
PRO TIP
Create core values that have been co-created by the people that work in the organization and have to
live by these values. Then make sure that they are published on the internet and on the office walls,
so they are there for all to see. I still have mine on a laminated credit card I carry in my wallet from a
company I left over 10 years ago.
Enterprise business drivers: Reflect on the emerging industry themes and trends that affect the business.
Distinctive competence: Strategy naturally leverages distinctive capabilities, the unique advantages that
differentiate this business from others, and provides a competitive edge.
Financial goals: Whether measured in revenue, profitability, people market share, or other metrics,
financial performance goals should be clear to all Stakeholders.
Competitive environment: Competitive analysis identifies the most significant competitive threats to the
business.
So, now we understand at a high-level what Enterprise Strategy is and why it is

critical. We also considered the elements for strategy formulation, but let’s now
consider what happens when market conditions change, and we have to adapt our
strategy.
Strategy Agility
Strategy Agility is the ability to sense changes in market conditions and implement
new strategies quickly and decisively when necessary; by that, we mean that it has
to be dynamic and more frequent than the traditional yearly, or worse, five-year,
cadence that we see in many organizations.
In recent years, we have seen several extraordinary global events that have
disrupted the market, and in these situations, your strategy cannot remain static. The
global pandemic of 2020 was a recent example where whatever strategy you had in
place needed to be ripped up and rethought; retail shop doors closed, the travel
industry stopped, doctors couldn’t see you in person, cash payments were no longer
accepted, to mention just a few of the many disruptions that forced companies to
rethink their strategy. But it is easy to adapt when a gun is put to your head, as it
was during Covid-19; the skill is being able to do it when there isn’t one, or you
can’t see the gun.
CASE STUDY
Primark, a European fashion retail store, was forced to close all 375 stores 12 days after the initial
Covid-19 lockdown in March 2020. They did not reopen for 6 months and reportedly lost £800m in
revenue because they could not sell online [4].
Market sensing represents the culture and practice of understanding changing

market dynamics based on the following:
Market research
Analysis of quantitative and qualitative data
Direct and indirect customer feedback
Direct observation of the customers in the marketplace
Savvy, lean-thinking leaders go see and spend significant time in the place where
the customer’s work is actually performed. They return with current, relevant, and
specific information about the realities of their products and services instead of
opinions filtered through other perspectives. There is no substitute for hands-on
learning; data and reports don’t cut it.
Go see is often called Gemba, a Japanese word. A Japanese police officer will often
be heard saying “I’m at the gemba” – the scene of the crime [5].
Identifying and defining a new strategy is only the first step. Once determined, the
strategy must be communicated to all Stakeholders in a new vision and roadmap
and then, of course, be implemented. After all, significant changes to strategy often
affect multiple solutions in the portfolio and require coordination and alignment.
Consequently, most large strategy changes require new Epics [6] to implement the
change across Value Streams, and work that is no longer aligned with the strategy is
purged from the backlog or even stopped during execution. In Chapter 16, we will
consider how we equip our leaders to lead the change in an Agile way. However,
the one thing that the global pandemic of 2020 and 2021 taught us was that
whatever strategy you had in place at the start of the pandemic had to change
almost overnight. With an ever-changing world, we can now assume that our
strategies will not be long-lived but need constant revisiting. If the strategy has to
change, then this will have an impact on your portfolios so, let’s have a look at what
we mean by a portfolio.
How is Enterprise Strategy different from

Portfolios?
The enterprise represents the business entity to which one or more SAFe®
portfolios belong, and a SAFe® Portfolio funds one or more development Value
Streams – each dedicated to building, deploying, and supporting a set of solutions
the enterprise needs to accomplish its business mission.
The portfolio is a ‘business’ that serves a market or set of customers with a
collection of solutions that are under common strategic and budgetary control.
– Isaac Montgomery, SAFe® Fellow and SPCT
SAFe® is not two-dimensional because an enterprise might have multiple

portfolios, and a portfolio could have development multiple Value Streams and
Solution Trains and/or Agile Release Trains (ARTs).
Let’s look at an example of a bank. The enterprise, Big Bank Group, has within it a
number of business units, for example, retail, credit card, capital markets, and
wealth, which each have its own portfolio.
Within retail, we will assume lending has its own portfolio. By completing a Value
Stream identification workshop (see Chapter 12), we can identify a number of
operational Value Streams that could include (but not be limited to) Mortgages,
Personal Loans, and Overdrafts.
We will go on to determine we need a Solution Train for Mortgages and also

Personal Loans and a single ART for Overdrafts:
Figure 11.1 – A portfolio view with two large solutions and a single ART
Figure 11.1 shows an expanded view of the portfolio with Mortgages and Personal
Loans both configured as a Large Solution and Overdrafts only requiring an
Essential SAFe® configuration.
One of the great advantages of SAFe® is the ability to scale to support large
organizations, however the reality is that the majority of the time you only need the
simplest configuration – Essential SAFe®. A single enterprise with a single Value
Stream (maybe just one product) is realized by a single ART. Figure 11.2 is the
SAFe® Big Picture configuration graphic of Essential SAFe®:
Figure 11.2 – Essential SAFe® (© Scaled Agile, Inc.)
PRO TIP
In the same way that we try to avoid or minimize dependencies across teams and ARTs, we also try
to avoid dependencies across portfolios.
Portfolios tend to be aligned to independent business units; this is often a good starting point when
considering what portfolios to instantiate. Also, consider grouping solutions that are connected,
especially by systems, as they can also be good candidates for portfolios. Either way, try to make
them independent.
Summary
In this chapter, we learned that it is important that an enterprise has a clear strategy;
however, as Coaches, we do not craft that strategy – this is not what we do as SPCs.
That said, we can certainly influence senior leaders to at least present the strategy in
an engaging way.
Recent events have forced organizations to recognize that strategy is not static and
has to be more dynamic to reflect changes in market conditions.
Finally, we learned that a SAFe® Portfolio is a collection of related development

Value Streams under common, strategic, and budgetary control. In the next chapter,
we will look at how to build your portfolio.
Further reading
Escape Velocity, Geoffrey Moore
Beyond Entrepreneurship 2.0, Jim Collins
The Internet of Things presents – #LikeABosch: https://www.youtube.com/watch?v=v2kV6pgJxuo
Primark loses £800m in Covid-19 Lockdowns:

https://www.theguardian.com/business/2020/jul/02/primark-loses-800m-amid-covid-19-lockdowns
Gemba: https://en.wikipedia.org/wiki/Gemba
Epics: https://www.scaledagileframework.com/epic/
Further SAFe® reading around Enterprise Strategy: https://www.scaledagileframework.com/enterprise/
12
Building Your Portfolio

Traditional approaches to portfolio management were not designed for a global
economy impacted by digital disruption. Enterprises now need to work under a
higher degree of uncertainty and be able to deliver innovative solutions much faster
with constrained resources. And yet, many enterprises try to impose a traditional
portfolio approach to govern in this new age:
The problem is not with our organizations realizing that they need to
transform; the problem is that organizations are using managerial frameworks
and infrastructure models from past revolutions to manage their business in
this one.
– Mik Kersten, Project to Product [6]
For many years, SAFe® organizations didn’t begin implementing Lean Portfolio
Management (LPM) until several Agile Release Trains (ARTs) had been launched.
Better business results achieved by Agile Teams and Trains put pressure on the
senior leaders to explore applying Lean-Agile practices at the portfolio level.
There’s a significant change in this pattern. However, today’s prevailing trend is to
launch LPM from the beginning of the transformation in parallel with the activities
needed to launch the first ART. This is why the course badge for LPM appears in
two places on the SAFe® Implementation Roadmap; above Train Executives,
Managers, and Leaders, and above Enhance the Portfolio (see Figure 12.1).
Figure 12.1 – SAFe® Implementation Roadmap (© Scaled Agile, Inc.)
Furthermore, the guidance for building the portfolio has matured through practice
and there are now more resources to support you in getting started with adopting
and implementing LPM within your enterprise.
PRO TIP
If you are a member of the Scaled Agile Inc community, there are many resources with SAFe® Studio
to help to build your portfolio.
In this chapter, we will be covering the following topics:

How to align key Stakeholders in preparation for launching LPM
Guidance for defining your portfolio
The critical task of identifying your Value Streams
Starting with education for the Leaders

By encouraging people and teams to perform at their best, Lean-Agile Leaders
drive, guide, and sustain organizational change. They do this through the following:
Learning about the Lean-Agile mindset, values, principles, and practices (education)
Modeling those behaviors every day (Leading by Example)
Guiding the organization to a new way of working (Leading the Change)
As is the case with implementing SAFe® or launching an ART, when it comes to

adopting LPM, education comes first so that the leaders entrusted with adopting
LPM can learn about the mindset, values, principles, and practices of LPM.
Therefore, we encourage the appropriate people to attend a 2-day LPM class (more
at https://scaledagile.com/training/lean-portfolio-management/).
PRO TIP
In identifying the participants for a 2-day LPM course, consider who makes investment decisions and
supports and facilitates the portfolio, and will implement LPM, foster new initiatives, and execute the
portfolio strategy.
The shared experience of leaders and key influencers is vital. While we understand
that getting senior leaders to commit 2 days of dedicated time to a training event is
hard, evidence from hundreds of implementations demonstrates that education is
critical to establishing a truly shared vision, the benefit of building a common
vocabulary, and the understanding of what needs to happen.
However, that said, it can still be a challenge to persuade senior leaders to devote to
a 2-day education event, so we need to ease them in gently; we have a couple of
options:
Within SAFe® Studio, there is a 7-minute introductory video to LPM
You can also download and provide a half-day workshop, which is an introduction to LPM for executives
Both are intended to be a way to establish the groundwork for senior leadership to
recognize the need and commit to further education and identify the portfolio roles
and who the key Stakeholders are so that a 2-day LPM course can be scheduled – in
essence, enough to persuade them to commit more time to education.
The LPM course is an advanced class that helps answer the following questions:
How do I connect strategy to execution?
How do I manage the flow and solve perpetual overload?

How can I fund and govern dynamically?
How does LPM fit into SAFe®?
PRO TIP
As an SAFe® Practice Consultant (SPC), you have the privilege to be able to teach about a dozen
SAFe® certified courses. But just because you can doesn’t mean that you should! We always advise
Coaches to consider their strengths and weaker areas. For example, I have never been an Architect,
so I would not consider teaching SAFe® for Architects. Similarly, if you have not operated at a
portfolio level, then at least pair with someone who has when you teach LPM (or any other course
where you lack expertise).
This is a 2-day interactive class that teaches the practical tools and techniques
necessary to adopt LPM using a consistent simulation throughout the course –
Terrific Transport Corporation (TTC). It is essential that for the 2-day class, you use
the simulation and are not tempted to use real work; we want people to understand
the theory and not get mired in how this relates to their real work. Later, through the
Workshop and Implementation, we start to put the theory into practice.
There is a 1-day optional, third-day workshop available to help enterprise teams get
started with LPM, and it’s our suggestion that you use this workshop to consider all
the activities for building the portfolio, prioritize them, create an implementation
roadmap, and take an iterative approach to advance LPM within your enterprise,
keeping the urgency high.
PRO TIP
LPM implementation is a journey that typically takes many months, but reaching self-sustenance can
take longer. It requires Coaching and support to fully embed the Lean-Agile mindset.
With an educational foundation of LPM under our belts, the conversations about
portfolios and strategies are easier to align.
Painting your Portfolio with color

In Chapter 11, we talked about the importance of the Enterprise Strategy and now
we need to connect the portfolio to the Enterprise Strategy with Strategic Themes.
Strategic Themes are differentiating business objectives that connect a portfolio to

the strategy of the Enterprise; they influence the portfolio strategy and provide
business context for portfolio decision-making (© Scaled Agile, Inc.). They help
direct what is done and, conversely, what is not done across the portfolio.
Let’s go through a couple of pointers about Strategic Themes:

They are differentiating; that means if you are a bank and you have a set of Strategic Themes and you walk
across the road to another bank and they have the same Strategic Themes, then they are probably not
differentiating! Common bad examples are “reduce costs” and “increase revenue.”
They are relatively short-lived; we suggest that Strategic Themes have a shelf life of 12-18 months and
should be reviewed at the quarterly Strategic Portfolio Review (more details in Chapter 13).
You will start to see increasing use of Objective Key Results (OKRs) within the
framework, but they were first introduced here as the recommended way to
document Strategic Themes:
Objective, as in, a memorable description of what you want to achieve; short, inspirational, and
challenging.
Key Results are measurable success criteria that can be used to track progress.
PRO TIP
For each portfolio, there should be four to six Strategic Themes; too many and you can’t see the
forest through the trees, and they become less effective in influencing the portfolio strategy.
For each objective, there should be two to five key results.
If you want a good introduction to OKRs, then the blog article An Introduction to
Objectives and Key Results (OKRs) [1] from Mark Richards is a good starting
point.
A more detailed introduction is given in Measure what matters [2] by John Doerr.
Strategic Themes influence, among other things, the Portfolio Vision, which
describes the future state of the Portfolio’s Values Streams and solutions.
In the same way that we want the Enterprise Vision to be engaging, we want the
Portfolio Vision to be aspirational – it must be convincing and realistic enough to
be feasible over a substantial period of time. To involve others in the journey—both
customers and staff—it must be motivating.
There are many techniques for describing a vision. In Chapter 11, we gave you a
link to the Live like a Bosch video. Another technique is Postcard from the Future
(from Switch: How to Change Things When Change is Hard, by Heath and Heath)
[3].
We then need to define the portfolio domain and the Value Streams for the
portfolio, which we do with an adaptation of the Business Model Canvas developed
by Alexander Osterwalder. The book [4] provides useful descriptions of the boxes
and prompts to help you complete them and is a recommended companion to
completing the canvas.
The Portfolio Canvas is a powerful way to represent the entire Portfolio on one
page:
Figure 12.2 – Portfolio Canvas (© Scaled Agile Inc.)
The Portfolio Canvas has three main sections:

Value Propositions: These describe the customers and the value delivered by the solutions of each Value
Stream, as well as the customer segments and relationships, budgets, and KPIs/revenue.
PRO TIP
Use a separate row for each Value Stream.
Key Resources and Key Activities describe the important partners, activities, and other resources needed
to achieve the value proposition.
Cost Structure and Revenue Streams describe how the Portfolio’s costs are structured and define how
revenue or value is achieved.
There are many tools and techniques to help us understand the opportunities for the
future state. The one that we want to describe is the SWOT analysis and the TOWS
Strategic Options Matrix.
SWOT is not something new and was accredited to four colleagues at the Harvard
Graduate School of Business Administration in 1965 [5]. The name is an acronym
for the four components that the technique examines:
Strengths: Characteristics of the business or initiative that give it an advantage over others.
Weaknesses: Characteristics that place the business or initiative at a disadvantage relative to others.
Opportunities: Elements in the environment that the business or initiative could exploit to its advantage.
Threats: Elements in the environment that could cause trouble for the business or initiative.
Now, the SWOT analysis is great but it doesn’t create an outcome. As Coaches, we
are big fans of TOWS (which you might think is SWOT backward, and it is!).
Figure 12.3 – TOWS strategic options matrix (©Scaled Agile, Inc.)
Having identified your strengths, what can be done to exploit and maximize
opportunities? How can you apply your strengths to overcome present and potential
threats? How can your opportunities be leveraged to overcome weaknesses? And
finally, how can you minimize weaknesses and threats? (See Figure 12.3.)
The key difference between SWOT and TOWS analysis is the outcomes they
create. By conducting a TOWS analysis, organizations can gain valuable insights
into their current situation and identify potential strategic options to pursue. Some
specific actions that you can take with a TOWS analysis include the following:
Strategy development: Use the insights gained from the TOWS analysis to develop a strategic plan that
leverages your strengths and opportunities while addressing your weaknesses and mitigating your threats.
People allocation: Allocate people to areas that will best position your organization to capitalize on
opportunities and mitigate threats.
Risk management: Use the insights from the TOWS analysis to identify and manage risks associated with
external threats and internal weaknesses.
Competitive positioning: Use the TOWS analysis to evaluate your organization’s competitive positioning
relative to other players in your industry and identify potential opportunities to differentiate yourself.
Decision-making: Use the TOWS analysis to inform decision-making across a wide range of areas,
including product development, marketing, and organizational structure.
Overall, the TOWS analysis is a powerful tool that can help you gain a deep
understanding of your organization’s internal and external environment and identify
potential strategic options to pursue.
Value Stream Identification (VSI)

Identifying Value Streams is one of the most difficult things you will do as a Coach
and, as a consequence, we often see this step missed. Yet it is critical if we are
going to shift the enterprise from being Project led to product led.
We are not going to explain in detail how to run a VSI workshop; you should have
experienced that as a simulation in your Implementing SAFe® class. Plus, if you
are an SPC in good standing, then you will have access to the VSI Workshop
toolkit. If you are not an SPC or an SPC in good standing, then the article on the
SAFe® Framework provides a good narrative
(https://scaledagileframework.com/organize-around-value-2/).
What we want to do is give you practical advice on how to prepare and run the
workshop and then implement ARTs that realize the Value Streams.
But first, a very quick refresher!
A Value Stream is the primary construct for understanding, organizing, and

delivering value in SAFe®. Each Value Stream is a long-lived series of steps used
to create value. These steps contain the flow of information and material and the
people who develop solutions.
Within SAFe®, there are two types of Value Streams:

Operational Value Streams (OVS): These contain the steps and the people who deliver end user value
using the business solutions created by the Development Value Streams (© Scaled Agile, Inc.)
Development Value Streams (DVS) – These contain the steps and the people who develop the business
solutions used by OVS (© Scaled Agile, Inc.)
The DVSs are managed by a SAFe® Portfolio. Our only interest in identifying the
OVS is the ability to allow us to determine the DVS that support them.
There are five steps for identifying DVS and ARTs:

1. Identifying an OVS.
2. Identifying the solutions the OVS use or provide to customers.
3. Identifying the people who develop and support the solutions.
4. Identifying the DVS that build the solutions.
5. Realizing DVS into ARTs.

PRO TIP
A solution is a product, system, or service that provides value to internal or external customers.
Let’s dive into each of these steps in a little more detail.
Pre-work and preparation

Make sure that everyone that attends the VSI workshop has had some SAFe®
education, ideally Leading SAFe®. Otherwise, you will spend most of the
workshop trying to educate and shift people’s traditional mindsets rather than
actually doing identification.
Do not go into a VSI workshop without preparation! Do your research and try to
understand the products and services that the enterprise offers. These are easily
researched from the enterprise website. These are great candidates for your OVS.
Don’t declare them up front but have them in your back pocket because you want
the organization to discover them first to get better buy-in.
Consider your attendees; clearly, you will need Architects and Development
Managers because they know the systems and the people working on them. You
also need to consider those folks that know the end-to-end flow, from sales and
marketing to finance. Also, having these folks involved in the early days will help
with advocating for the change.
The workshop will take longer than you think! Even for a similar enterprise that
only had two OVS, it took me a day and a half. My advice would be to plan for 2
days. Having an overnight break is recommended for you to decompress and reflect
and also so that attendees can consider their thoughts and maybe calm down – it can
get quite heated.
Do not try and do the workshop on your own. You need at least two pairs of eyes,
even for the simplest workshop. Where you have multiple OVS, then many
Coaches might be required.
Step 1 – Identifying the OVS

There are typically four types of OVS: fulfillment, manufacturing, software
products, and supporting. You will often find that the steps in these OVS will need
minimal changes/updates from enterprise to enterprise.
The common example given in SAFe® and something I helped develop is the OVS
of a customer wanting a consumer bank loan, as shown in Figure 12.4:
Figure 12.4 – Bank OVS (© Scaled Agile, Inc.)
PRO TIP
When executing the first step, you may want to show the 4 different OVS and then solicit feedback
from the group on which one matches your organization best. Once you have that general
consensus, you can then make the necessary adjustments for your organization.
Also, try and limit the OVS to less than 12 steps and more than 5 steps; more than 12 and the steps
are too fine-grained, less than 5 and the steps are too coarse-grained. We are looking for a
significant hand-off between each step.
Step 2 – Identifying the solutions the OVS

use or provide to customers
This is a key step that folks often have challenges with and discover that there are
often many systems within the organization that are necessary to deliver value.
Don’t let the word “solution” in the step confuse you or the participants in thinking
you are identifying a Solution Train. In this step, we are trying to identify the
underlying systems that support the OVS.
In Figure 12.5, there are 4 major systems that this bank uses: Channels, Loan
Origination System, Credit Scoring System, and Core Banking.
In this step, you will also want to identify the customers of each step. This could be
external customers or internal users. If you have personas already established in
your organization, this is a great time to leverage them.
Figure 12.5 – The systems that support the OVS (© Scaled Agile, Inc.)
PRO TIP
Make sure that you take each of the steps sequentially and try not to let the participants work ahead
as this often complicates the activity.
Step 3 – Identify the people who develop and

support the solutions
In this step, we want to understand who and how many people are working on each
system and their location. This is a critical step as it feeds into who will be on the
ART and how many ARTs we will have.
Figure 12.6 – People who develop and support the solutions (© Scaled Agile, Inc.)
PRO TIP
Depending on who is in the workshop, participants may not know who or how many or their locations.
You may have to assign this as homework or consider breaking the workshop into several shorter
days to allow time for participants to have time to identify these individuals or even get clarification on
the systems from the previous step. And don’t forget to include 3rd Party Vendors.
Step 4 – Identify the DVS that build the

solutions
In the next step, we identify the DVS whereby each individual DVS should be able
to develop and release value independently without too many intra-Value Stream
dependencies.
As the four OVS patterns serve very different purposes, it stands to reason that the
design and outputs of each DVS are driven by the type of OVS it supports. While
there is no obvious limit or constraint to the ways an organization can configure
DVS, specific patterns have emerged – fulfilling a product, manufacturing a
significant cyber-physical solution, developing a software product, and a supporting
Value Stream.
The pattern in Figure 12.7 revisits the bank loan example. Patterns like this one are
common in insurance, banking, financial services, and related industries that offer
complex, digitally enabled products and services to consumers (B2C) and
businesses (B2B). In this example, one DVS supports the frontend loan origination
and credit scoring; another builds the core banking services.
Figure 12.7 – Fulfilment DVS pattern (© Scaled Agile, Inc.)
PRO TIP
DVS should be able to develop and release value independently, so consider carefully and try and
design your DVS without too many intra-Value Stream dependencies. I often see that people will try
and design their DVS by the individual systems (vertical silo thinking) rather than considering the
systems that need to be released together to create value (horizontal flow thinking). Try and switch
their mindset from vertical to horizontal.
Step 5 – Realize DVS into ARTs

Finally, we realize DVS into ARTs, which can contain 50 to 125 people, are long-
lived, and are focused on a holistic solution or a related set of products and services.
Depending on how many people do the work, there are three possible scenarios for
the ART design:
Multiple DVS can fit within a single ART – When several related products or solutions can be produced
with a relatively small number of people, a single ART may deliver multiple Value Streams.
A single DVS can fit within an ART – Often, a Value Stream can be realized with 100 or fewer
practitioners. Many development groups are already organized into units of about that size, so this is a
common case. In this case, the ART is roughly the same as the Value Stream, and everyone is in that ART.
Multiple ARTs are required for large DVS – When a lot of people are involved, the DVS must be split into
multiple ARTs, and form a Solution Train.
See an example of each scenario in Figure 12.8:

Figure 12.8 – Realizing DVS with Solution Trains and ARTs (© Scaled Agile, Inc.)
Then we need to consider organizing the ARTs with ART Topologies if we have a
Solution Train. Remember the first rule of scaling is “don’t”, so if you don’t need a
Solution Train then try and avoid it. There are three patterns:
A Stream-Aligned ART, just like a stream-aligned team, will have the necessary personnel, skills, and
authority to deliver value, whether it’s a full product, service, subsystem, or whatever portion of the
solution they have been tasked with.
Most large systems also include extensive subsystems. This means that Complicated Subsystem ARTs
are common when building large-scale systems, again to reduce the cognitive load on the Stream-Aligned
ARTs.
Similarly, it’s common for a Solution Train to have Platform ARTs providing services that the Stream-
Aligned ARTs extend and build on.
Continuing our banking example in Figure 12.9 we have a Large Solution with 3
ARTs (Channel support, Loan Origination, and Credit) and a single ART for Core
Banking.
Figure 12.9 –Combination of ART Topologies in the consumer bank loan example (© Scaled Agile,
Inc.)
At the end of the workshop, you might have several candidate ARTs and will need
to pick one to start – do not try and launch all the ARTs at once. Start with one, run
it for a PI, gather the learning, and then launch the next ART based on that learning.
But which one to start with?

Now, I used to be a bank Manager, and every 18 months to 2 years, I used to be promoted to another
branch because I was doing well. The bank always offered a good branch, one that was performing
well. I always turned it down! I insisted on a branch that was not performing well as my next move.
Why? Because a poor-performing branch generally can’t get worse, so I was able to demonstrate
improvements and then move on to my next promotion.
Identify the ART with the burning platform, where you can get a quick win.
PRO TIP
I like to pick an area for my first ART that is under pressure so that I can quickly and empirically
demonstrate after the first PI how we have turned the dial and made significant improvements. This
becomes your mandate for continuing the change.
CAUTION
Make sure you understand the difference between Value Stream Identification and Value Stream
Mapping; you will find that people will use the terms interchangeably but they are very different
things.
The VSI workshop is a guided event to identify your Value Streams, as described earlier. It includes
organizing your teams of Agile Teams or ARTs around Value Streams.
A Value Stream Mapping workshop helps measure the health of your current Value Streams,
identifying the biggest bottlenecks and creating an actionable plan to optimize your Value Stream.
Summary
Many organizations now start by building the portfolio level before they launch any
ARTs because they need to solve the problem of having more demand than capacity
sooner rather than later.
If this is the case, then make sure your leaders are properly informed within the
critical education steps and then incrementally build out your portfolio artifacts;
Strategic Themes, the Portfolio Canvas, and SWOT/TOWS analysis.
One of the most difficult things you will do as a Coach is VSI so be sure to use the
toolkit, have an experienced Coach support you, and do your preparation.
In Chapter 13, we will look at how we move from traditional Project cost
accounting to Lean-Agile Budgeting.
Further reading
1. An Introduction to Objectives and Key Results, by Mark Richard
(http://www.agilenotanarchy.com/2017/03/an-introduction-to-objectives-and-key.html)
2. Measure what Matters, by John Doerr
3. Switch: How to Change Things When Change is Hard, by Heath and Heath
(https://heathbrothers.com/books/switch/)
4. Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers, by
Alexander Osterwalder and Yves Pigneur (https://www.strategyzer.com/books/business-model-generation)
5. SWOT (https://en.wikipedia.org/wiki/Harvard_Graduate_School_of_Business_Administration and

https://en.wikipedia.org/wiki/Kenneth_R._Andrews)
6. Project to Product by Mik Kersten: https://Projecttoproduct.org/the-book/

13
Establishing Lean Budgets

Traditional Project portfolio approaches inhibit the flow of value because of several
factors, but here are some of the most common challenges that we encounter:
Project cost accounting
People are organized in functional silos
Overly detailed business cases
Projects governed by waterfall phase gates measuring task completion
If we are to operate in a Lean-Agile way, then we fundamentally need a different

way to govern, which will require a mindset change at the portfolio level.
In this chapter, we will explore the following:

The investment horizon model
How to move away from traditional Project cost accounting to Lean-Agile budgeting
How we can use the technique of participatory budgeting to help establish the funding for each Value
Stream
Seeing the horizons

The SAFe® Investment Horizon model highlights spending allocations for
solutions that are created by individual Value Streams. This model is an adaption of
Geoffrey Moore’s Zone to Win [1]:
Figure 13.1 – SAFe® investment horizon model illustrating solution investments by horizon (©
Scaled Agile, Inc.)
Let’s explore each of the Horizons in turn. First, we need to explain that, in Figure
13.1, each cube represents a solution and that the size of the cube is meant to
relatively reflect the size of the investment in that solution.
Horizon 3 (Evaluating): You will notice that the size of the “solutions” (cubes) in
Horizon 3 is smaller compared to some of the other solutions in Horizon 2 and 3
because these are experiments dedicated to investigating new potential solutions.
Often, an initial experiment is defined to test the Benefit Hypothesis. The
investment continues until the initiative is stopped or allowed to continue to
Horizon 2. Not all solutions in Horizon 3 make it into Horizon 2. Horizon 3
investments are dedicated to investigating new potential opportunities for profitable
growth in the future, typically within 3-5 years.
Horizon 2 (Emerging): You will also notice in Horizon 2 that there are only two
solutions because Horizon 2 is WIP-limited. This Horizon reflects the investments
in solutions that have been selected to emerge from Horizon 3. Because Horizon 2
is WIP-limited, the potential solutions from Horizon 3 are competing to be
considered for Horizon 2. So, why is Horizon 2 limited? Geoffrey Moore reminds
us of the following:
“In our company, we like to lay eggs one at a time. By the way, we find most
chickens do too.”
-Zone to Win, Geoffrey Moore
We have to consider how much change an organization can absorb; too much
change can be very disruptive and could traumatize the organization. That’s why we
need to limit the number of solutions we progress in Horizon 2 and only lay one or
two eggs at a time. Horizon 2 reflects the investments in promising new solutions
from Horizon 3 and these investments are anticipated to provide a profitable return
within 1-2 years.
Horizon 1 (Investing and Extracting): Most enterprises that we work with will
focus on Horizon 1 – that is, the current solutions that they have developed and are
still developing (investing in) and those existing solutions that require little
investment capital and perennially provide positive cash flows (extracting). The
latter is often referred to as cash cows, a metaphor for a dairy cow that produces
milk throughout its life and requires little to no maintenance.
Horizon 0 (Retiring): At some stage in the life cycle of the solution, it will need to
be retired because it doesn’t generate much cash for the enterprise since it has a low
market share and little to no growth. As a consequence, this solution can turn out to
be a cash trap and for this reason, it is a prime candidate for divestiture. And yet,
how often do we see enterprises not investing in decommissioning or sunsetting
these solutions that are consuming company funds for long periods?
The SAFe® Investment Horizon model highlights the spending allocations for the
solutions that are created by the individual Value Streams. That is why, in SAFe®
we fund Value Streams, not Projects.
We fund Value Streams, not Projects

Traditional Project-based, cost-center budgeting creates overhead and friction. Let’s
explain this with a story from the real world. Please note that the names have been
changed to protect the innocent!
Story from the real world

I was working for a ferry company whose financial year was from January to
December. The budgeting cycle was 3 months; it started in August and ended in
October so that it could be approved by our single shareholder in November and
then loaded onto the ledgers in December so that we were ready to “rock n roll” in
January.
Starting a budgeting cycle in August is not great because many people are on
holiday vacation; the busiest time of the year for this ferry company was the last 2
weeks of July and the whole of August because of the school holidays / summer
vacation.
So, I never started the budgeting cycle in August and waited until September.
I would then visit all the directors in turn to ascertain their IT budget requirements
for the following year. I would start with Phil, the Onboard Services Director.
Me: “Phil, have you got a few minutes?”
Phil: “What do you want?”
Me: “I need to talk about your budget for next year.”
Phil: “Seriously?”
Me: “Yes!”
Phil: “You know that we have just finished the summer season and I have no end of
issues on board that I need to solve.”
Me: “I know, but we need to think about your budget for next year.”
Phil: “I can barely think about next week, let alone next year.”
Me: “I understand, but we need to have something in the budget.”
Phil: “Well, I just can’t think about it now, what do you want me to do?”
Me: “Can you make some stuff up?”
Phil: “If I make some stuff up, will you leave me alone?”
Me: “Absolutely.”
I would then seek out Jim, our Fleet Director:
Me: “Jim, have you got a few minutes?”
Jim: “What do you want?”
Me: “I need to talk about your budget for next year.”
Jim: “You know that we have just finished the summer season and now I have to
plan for 30 ships to go to refit starting in October.”
Me: “I know it is a very busy time of year for you, but we need to put something in
the budget for next year.”
Jim: “I am completely up to my eyes in sorting out the refit schedule that starts next
month; I don’t have the mental capacity to think about next year. What do you want
me to do?”
Me: “Can you make some stuff up?”
Jim: “If I make some stuff up, will you leave me alone?”
Me: “Absolutely.”
So, the cycle continued with all the other directors but at least I had a list of
Projects for next year! The next stop was my developers to estimate the Projects:
Me: “Good news – we have a list of Projects for next year. Can you estimate
them?”
Developers: “Can you explain them to us?”
Me: “Nope, they are all made up.”
Developers: “So, you want us to estimate made-up Projects?”
Me: “Yes! That feels like a completely reasonable request.”
Developers: “We are not doing that!”
Me: “Well, that is very disappointing.”
The only option is that I do the estimates myself, but the estimates must look like
they haven’t been made up as well. So, be careful and avoid round number
estimates – every estimate needs to look like it has an element of precision, so no
estimates that are £750,000; rather £739,286.
Having assembled my budget with estimates in September, the next round was the
review with the finance committee in October, where their sole objective is to “red
line” as many Projects as possible:
Finance committee: “Come in and sit down. Right, let’s have a look at this IT
Budget. £70m? That’s ridiculous!”
Me: “Oh, that’s disappointing.”
Finance committee: “Right, let’s have a look at this first Project from Phil. Nope,
we are not doing that one.”
Me: “Oh no! (Bearing in mind that this is a made-up Project from Phil.) Ok, I think
as long as we do this other Project (also made up) from Phil, I can persuade Phil to
accept this deletion.”
Finance committee: “Good. Right, let’s look at this Project from Jim. Well, we are
not doing that either.”
Me: “Oh no! (Bearing in mind that this is also a made-up Project from Jim.) Ok, I
think I have a good enough relationship with Jim to convince him that we don’t
need to do it.”
And so the process would go on until they had reduced my budget from £70m to
£50m.
Finance committee: “There you go, £50m – think yourself very lucky.”
Me: “Thank you so very much, I am very grateful.”
I then walked outside the committee room laughing inside because I knew that I
could only deliver £30m worth of Projects, but I have a £20m buffer. Happy days!
So, I start the new year with Projects that are rollovers from the previous year.
However, by March, I normally get a call from Phil wanting a chat:
Me: “You ok Phil?”
Phil: “Yep. You know those Projects we put in the budget last year?”
Me: “Yes.”
Phil: “Well I don’t want to do them.”
Me: “I know – because they were made up!”
Phil: “Instead, I would like to do this.”
Me: “That’s a great idea.”
I then go to my development team and ask them to estimate it:
Developers: “Is this a real Project?”
Me: “Of course!”
Developers “Ok, give us a day to get back to you.”
Armed with that estimate, I found a similar-sized Project (but made up) in the
budget to swap it with. But I couldn’t swap it out without getting approval from
finance:
Me: “Can I swap out this new Project that Phil wants with a similar-sized Project
that is in the budget?”
Finance: “No, you can’t. This new Project is not in the budget. Why did you put that
other Project in the budget if you don’t need it?”
I couldn’t say because the Project was made up, so…
Me: “Well, that was back in September and the world has moved on. Phil would
rather do this Project than that one, blah, blah blah…”
Finance: “Well, I am not happy but on this occasion, we will swap it out.”
Me: “I am very grateful.”
However, this was a conversation that I had over and over again with Finance
because all the Projects were made up. I did this for 3 or 4 years and it wasn’t very
edifying.
Fortunately, our CFO left and a new CFO arrived; I remembered that one of the
values of Scrum is courage. So, I knocked on the new CFO’s door.
Me: “Hello, can I have a very open and honest conversation with you?”
CFO: “What about?”
Me: “Er, Finance!”
CFO: “Ok.”
So, I told her how I arrived at my annual budget. Now, she could have said, “you
have been corporate lying for 3 years, there is my door, never darken it again!”
Fortunately, she said, “that’s not a great process; tell me how I can improve it.”
Fortunately, I had an idea:
Me: “Let’s stop the game of I ask for £70m, you cut me down to £50m but I only
need £30m. Let’s agree from the outset that I have £40m for the year.”
CFO: “I like that a lot because it means that I can remove £10m as a provision for
capital Projects.”
Me: “Talking to all the Directors in September is not helpful; they are too busy and
they can’t forecast beyond 3 months. Instead, let’s get all the Directors together in
December and, collectively, they tell me what they want to achieve in quarter one.
In return, you release one-quarter of my annual budget to fund £10m.”
CFO: “You don’t want the whole £40m?”
Me: “Nope; just enough to fund the first quarter.”
CFO: “What happens at the end of the quarter?”
Me: “We demonstrate all the work that we have created. Plus, if we can, we will
even try to put our work live so that we can get some feedback and generate value.”
CFO: “I like the sound of early value because that, in turn, can help me fund the
remaining capital Projects for the year. What happens next?”
Me: “We repeat the process and agree on the work with the Directors that we need
to do for the next quarter.”
CFO: “We should try this!”
Why did I know that I could only deliver £30m worth of Projects every year?
Because, effectively, I am funding the people that do the work.
Previously, the budgeting process was slow and complex and caused a lot of wasted
time and effort. In addition, I was constantly moving people to the work and
moving people from one project to another, even if the project wasn’t finished
because I needed to start another project.
With this new process we stopped the moving the people to the work, and moved
the work to the people.
We created long-lived teams aligned around a solution (the Value Stream) and
funded the Value Stream (the capacity) and just prioritized the work for every PI for
that Value Stream.
Lastly, because we funded our development Value Stream, people were committed
to the ART for an extended period. This also increased empowerment as many of
the day-to-day budget decisions could become decentralized and shifted as needed.
This increased the trust and transparency across the organization.
There was one additional benefit. Our budgets were not affected by Feature
overruns and changing priorities. I never had to go back to finance and ask for more
money, which is always a painful conversation. Let’s take a look at why.
In Figure 13.2, we have planned two Features; however, Feature 1 takes longer than
planned. Because we have a built-in capacity margin within our PI and we can
agree that finishing Feature 1 would provide more value than starting Feature 2, we
can absorb this overrun within our capacity margin within the fixed cost of the PI:
Figure 13.2 – Feature overrun (© Scaled Agile, Inc.)
When we fund a Value Stream, the local content authority can decide whether to
keep investing in a Feature that requires more investment or shift direction.
We have many options when we overrun, and they’re all based on the economic
decision-making framework.
This is all good, but if we have several Value Streams within our portfolio, how can
we decide how much funding to allocate to each Value Stream? Participatory
Budgeting (PB) is an advanced technique that can help with this; we will take a
look at it in the next section.
Participatory Budgeting
First, I will provide a quick history lesson that might help when you are explaining
the concept of PB.
The concept of PB has its roots in the participation and empowerment movements
of the 1960s and 1970s, which sought to increase the involvement of ordinary
people in decision-making processes. The first known PB process was implemented
in the Brazilian city of Porto Alegre in 1989, and it has since spread to cities and
regions around the world.
Where PB has been used in a government, it is a democratic process in which

community members directly decide how to allocate a portion of a government
budget. It is a way for people to have a say in the decisions that affect their lives
and communities, and it can also help to build trust between the government and the
public.
In PB, community members are typically organized into committees or working

groups that are responsible for identifying, prioritizing, and proposing Projects for
funding. These proposals can range from infrastructure improvements and public
services to cultural and recreational programs. The proposals are then put to a vote,
and the proposals with the most support are funded.
PB has been successful in engaging diverse groups of people, particularly those

who may not normally participate in traditional democratic processes. It has also
been shown to increase transparency, accountability, and the effectiveness of
government spending. However, it can be challenging to implement, as it requires
significant resources and buy-in from both government and community
Stakeholders.
It was from these roots that the SAFe® framework took PB as the process that Lean
Portfolio Management (LPM) recommends to allocate the total portfolio budget to
its Value Streams.
The enterprise provides a portion of its total budget to each portfolio. In turn, each
portfolio, through LPM, allocates the portfolio budget to individual Value Streams.
These Value Streams then fund the people and resources needed to achieve the
current Portfolio Vision and Roadmap.
Empowered Agile Release Trains (ARTs) advance solutions and implement Epics
approved by LPM. LPM establishes Lean Budget Guardrails to provide the right
mix of investments to address both near-term opportunities and long-term strategy.
These guardrails also ensure that large investments are approved at the appropriate
investment level in technology, infrastructure, and maintenance. These guardrails,
coupled with KPIs, promote decentralized decision-making and execution while
providing the necessary oversight.
In this chapter, we will not discuss PB in detail; please refer to the article from
SAFe® in the Further reading section[2] to learn more. However, I do want to give
you some top tips for running a session.
PRO TIPS
Here are some tips:
Involve a diverse group of Stakeholders: It is important to ensure that the process is inclusive
and representative of the portfolio. This may involve providing support to help them participate.
Communicate clearly: Clear communication is key to ensuring that the process is understood
and that all Stakeholders feel included. This may involve providing information in multiple
languages and using multiple channels of communication.
Establish clear guidelines: Establishing clear guidelines and rules for the PB process can help
ensure fairness and transparency. This may include setting eligibility criteria for Epics and
explaining the process for reviewing and selecting Epics.
Provide support: Providing support to those participating in the process can help ensure that it
is successful. This may include training and technical assistance and additional facilitation on the
day of the event.
Ensure accountability: It is important to establish mechanisms for monitoring and evaluating

the process to ensure that it is transparent and accountable. This may involve establishing a
system for tracking the progress of funded Epics and providing regular updates to the portfolio
(see the Lean Portfolio Management events and Governance section in Chapter 14).
Foster collaboration: Collaboration between all Stakeholders can help ensure that the PB
process is successful.
Moreover, preparation is vital. If you haven’t done this before, try and find an experienced Coach (or
SPCT) that has done the event before to help guide you.
Summary
Traditional portfolio management presents several challenges, including funding
Projects and Project-cost accounting and big up-front, top-down annual planning
and budgeting.
In this chapter, we explored how we fund Value Streams instead of Projects and
move the work to people rather than people to the work. In addition, we showed
how you can consider allocating investments across a series of Horizons to our
solutions within our portfolio.
Finally, if you have more than one Value Stream in your portfolio, we shared how
you can use the advanced technique of PB to allocate portfolio funds across your
Value Streams.
In the next chapter, we will look at how to establish a Portfolio Flow.
Further reading
1. Zone to Win, by Geoffrey Moore
2. Participatory Budgeting: https://www.scaledagileframework.com/participatory-budgeting/

14
Portfolio Backlog Management

In previous chapters, we have looked at the importance of an Enterprise Strategy,
how we connect the portfolio to the Enterprise Strategy via Strategic Themes, the
various tools and techniques to help define the portfolio, and then the critical stage
of identifying our Value Streams. Having identified our Value Streams, we then
explored how we fund Value Streams rather than Projects moving away from
traditional Project cost accounting.
So, now we need to consider how we visualize the progress of our work, in this
case, the Epics, using our Value Streams.
The Portfolio Kanban is particularly important in that it helps align the strategy and
its execution by identifying, communicating, and governing the selection of the
largest and most strategic initiatives (Epics) for a SAFe® Portfolio. The Portfolio
Kanban is operated under the auspices of Lean Portfolio Management and uses the
Strategic Portfolio Review and Portfolio Sync events to manage and monitor the
flow of work.
In this chapter, we will cover the following:

Portfolio Epics
The Portfolio Kanban system and the various states that manage the flow of Epics from ideation to
implementation and completion
The Portfolio Sync events and related governance
But first, what do we mean by a Portfolio Epic?
Portfolio Epics
A Portfolio Epic is a significant solution initiative. There are two types of Portfolio
Epics:
Business Epics that directly deliver Business Value
Enabler Epics that support the Architectural Runway and future business functionality
CAUTION
Epics are not merely a synonym for Projects; they operate quite differently. Epics represent a
significant opportunity and also are not a large collection of Features. There can be lots of great ideas
that don’t qualify as Epics. They may be more appropriately planned as Features.
Portfolio Epics are typically cross-cutting, spanning multiple Value Streams and
PIs.
PRO TIP
Even though Epics can span multiple PIs, I always try and create Epics that span maybe three or four
PIs at most. Try and break a larger Epic into smaller Epics; otherwise, it will distort the prioritization.
The larger Epics will naturally fall to the bottom of the Portfolio Backlog because of the effort/duration
when we use economic prioritization (Weighted Shortest Job First (WSJF)). Plus, with a “smaller”
Epic, you get feedback earlier.
Each Epic will need an Epic Owner. Epic Owners are responsible for coordinating
Portfolio Epics through the Portfolio Kanban system. They collaboratively define
the Epic, its Minimum Viable Product (MVP), and its Lean Business Case, and
when approved, facilitate its implementation.
Figure 14.1 illustrates the four primary responsibilities of an Epic Owner:
Figure 14.1 – The Epic Owners’ four areas of primary responsibility (© Scaled Agile Inc)
PRO TIP
Because the Epic Owner needs to shepherd the Epic through the Portfolio Kanban system (which will
require an understanding of Lean Portfolio Management and a significant degree of collaboration with
various senior Stakeholders), we often see a senior Project Manager or portfolio Manager undertake
this role, supported by enterprise business and system analysts.
In the next section, we will look at how we can define an Epic, its MVP, and the
Lean Business Case.
The Portfolio Kanban

The Portfolio Kanban system is a method for visualizing and managing the flow of
Portfolio Epics, from ideation through analysis, implementation, and completion, as
illustrated in Figure 14.2:
Figure 14.2 – Portfolio Kanban (© Scaled Agile Inc)
There are several Kanban systems used throughout SAFe®, including the Team,
ART, Solution, and Portfolio Kanban systems. These systems help match demand to
capacity based on Work in Progress (WIP) limits; visualizing bottlenecks in each
process state helps identify opportunities for relentless improvement.
It’s important to note that the Portfolio Kanban in Figure 14.2 is a prototypical
Kanban; the design of the Kanban should evolve to reflect improvements to the
default Kanban states based on relevant portfolio experience. These improvements
may include adjusting WIP limits, splitting or combining Kanban states, or adding
classes of service to optimize the flow and priority of Epics.
PRO TIP
I find that the Kanban designed in Figure 14.2 is a good starting point and tends to “work out of the
box” but then you should evolve your Kanban over time with your experience and context. This is
only true of the Portfolio Kanban; the other Kanbans need to be designed based on your context.
However, all Kanbans should evolve over time.
We will now briefly explore the states of the Portfolio Kanban.
The Funnel
We want a system where all ideas are welcomed; it could be anything from a simple
email inbox to a page on a collaborative website (e.g., Confluence), but the key
here is that we just want a simple expression of the idea – more often than not, a
one-liner. We can then assess this one-liner to see whether it is aligned with our
Strategic Themes and whether it meets the following criteria:
Desirable
Viable
Feasible
Sustainable
If it doesn’t fulfill these criteria, then we need to archive that particular idea. Let me
give you a real-life example.

Let’s refer back to my ferry company that we discussed in Chapter 13. This ferry company had
already survived two existential events:
1. The loss of duty-free goods that could be sold onboard
2. The introduction of the Eurotunnel connecting England to France
However, early in the 2000s, low-cost airlines started to penetrate the travel market, whereby you
could now fly from the UK to the south of France for less than €10, as opposed to getting on a ferry
from Dover to Calais and then driving the 10 hours or so down to the south of France. Moreover,
these low-cost airlines were very lean compared to the ferry company, which had significant fixed
costs.
The CEO stated that in order to survive, we had to become a leaner organization, and while the
executive had some ideas, she also recognized that they didn’t have all the answers. The CEO asked
everyone to think of ideas that would generate cost savings and all that the CEO demanded was a
simple statement to be sent to a collection email.
At the time, the cost of a barrel of oil was at an all-time high and we burned a lot of oil on our ferries.
Therefore, one of the suggestions was to convert all our ferries into using nuclear power!
Now, that certainly met the Strategic Theme in terms of cost reduction (over time) but not the four
measures of desirable, viable, feasible, and sustainable. That idea was quickly discounted. However,
some ideas will meet the initial test and progress to the next stage of Reviewing.
Reviewing
This is where we convert the one-liner into a one-pager and create an Epic
Hypothesis Statement (EHS), as shown in Figure 14.3:
Figure 14.3 – EHS (© Scaled Agile, Inc.)
This is the point at which we assign an Epic Owner, who won’t always be the
person that created the idea but will be someone that can shepherd the Epic through
the Portfolio Kanban and help create the necessary information to ultimately get
approval from Lean Portfolio Management. As suggested earlier, often, a Project
Manager who knows the business and can collaborate with key Stakeholders makes
a very good candidate for Epic Owner.
The EHS is like an elevator pitch for the idea. An elevator pitch is a brief (think 30
seconds!) way of introducing the idea, getting across a key point or two, and
making a connection with someone. It’s called an elevator pitch because it takes
roughly the amount of time you’d spend riding in an elevator with someone. If you
happen to bump into someone you want to tell about your idea in an elevator, what
will you say to get your point across — all before that person exits the elevator?
Most people are fairly comfortable with completing the Epic Description and the
Business Outcomes but then start to struggle with the Leading Indicators. We will
discuss Leading Indicators in Chapter 15 but for now, Leading Indicators are the
metrics that demonstrate that, as we develop the Epic, it will meet the Business
Outcomes. Generally, we are very good at Lagging Indicators – as in, what value
the Epic will generate when completed, but that might be months and years later.
As we develop the Epic, what comfort can we take to generate confidence that we
will meet these outcomes?

An example we often use is Tesla. When launching the Model 3 in March 2016, Tesla wanted a
$1,000 refundable deposit and expression of intent. Almost half a million put down $1,000, even
though it was a 2-3 year wait. This was a clear leading indicator that there was a demand for a car
that was not even built!
Again, after completing the EHS, if this Epic has merit, then it will be pulled to the
next stage, proving the Epic Owner has the capacity and/or the Portfolio Kanban
WIP isn’t also exceeded.
Analyzing
This is where we go from a one-pager to a slide-deck presentation, and the
presentation must include the following:
1. The high-level Features of the Epic
2. A defined MVP
3. Solution alternatives
4. Refined cost estimates from the EHS
5. A Lean Business Case
Let’s have a look at these in turn.
The High-Level Features of the Epic

Break down the Epic into high-level Features based on the business objectives and
user roles. Use the following guidelines to create Features:
Each Feature should align with one or more business objectives.
Each Feature should address the needs of one or more user roles.
Ideally, each Feature should be small enough to be delivered in a single PI or less; however, at this stage,
don’t worry if the Feature is bigger than a single PI because we will have time later to refine that Feature
as part of the preparation for PI Planning.
A defined Minimum Viable Product (MVP)

MVP is the most misunderstood term in Agile – it is not the crappiest version that
we can release to the market as soon as possible, which is a common
misconception, and, as a consequence, has created an allergic reaction to MVPs.
Our preference is the definition from Eric Rees and his book Lean Start-up:
“[the] version of a new product which allows a team to collect the maximum
amount of validated learning about customers with the least effort”
In his book, Eric explains that MVPs range from extremely simple smoke tests
(little more than an advertisement) to actual early prototypes, complete with
problems and missing Features.
What is the minimum we can do to validate or invalidate our hypothesis– that is,
our MVP?
Solution alternatives
We also need to understand that at this early stage of the Epic, we may not have all
the answers and there may be various solution alternatives; we don’t want to be
forced into making point solutions too early; rather, we would prefer to preserve
options and the ability to explore these options through Set-Based Design (SBD).
[1]
SBD is an approach to product or system design that emphasizes exploring multiple

possible design solutions simultaneously before making a final selection. The
process involves creating sets of possible design alternatives, evaluating their
strengths and weaknesses, and then selecting the best alternative based on a set of
predefined criteria.
The goal of SBD is to reduce the risk of making a poor design decision by
exploring a broad range of potential solutions before committing to a single design.
By considering multiple design alternatives simultaneously, SBD encourages
designers to think creatively and explore a wider range of possibilities.
SBD is often used in complex engineering Projects, where design decisions have
far-reaching consequences and a high degree of certainty is required. By using this
approach, designers can reduce the likelihood of costly redesigns and minimize the
risk of solution failure.
This is the opposite of “just picking one.” In SBD, teams identify and
simultaneously vet possible options, committing to implementing a technical
solution only after testing and validating assumptions. SBD is best suited to
situations with a high degree of innovation or variability involved, or problems with
immovable deadlines.
Refined cost estimates from the EHS

You will have created an initial cost estimate in Reviewing when defining for EHS.
However, having now created the high-level Features and the solution alternatives,
you will need to refine these cost estimates.
For example, you can estimate the costs associated with each Feature of the Epic
using a combination of top-down and bottom-up approaches. Use data from past
Epics, industry benchmarks, and expert opinions to refine the estimates.
You should also refine the cost estimates based on feedback from Stakeholders and
any changes in the scope of the Epic.
A Lean Business Case

Finally, we need to complete a Lean Business Case; Lean because it only extends to
two pages! Scaled Agile, Inc. has created a template that you can download from
their website (https://scaledagileframework.com/epic/).
It is at this stage that we present our case to the Lean Portfolio Management
function to make a go/no-go decision.
Our experience from the many organizations that we have supported is that this
function normally exists, but it may go under a different title – for example, the
Steering Committee, Investment Committee, or something similar. We just need to
re-purpose that function to operate in a more Lean-Agile fashion, and this is where
the education that we describe in Chapter 12 becomes important.
The Portfolio Backlog

If the Epic is not approved, it might cycle back through Reviewing and/or Analysis
of the Portfolio Kanban or be archived. If it is approved, it is moved into the
Portfolio Backlog, which is a lightweight holding area for all approved Epics.
These Epics will be prioritized using WSJF.
These Epics will only be pulled into Implementing when there is the budget
available, as determined by Participatory Budgeting (PB) (if used), and if there is
capacity.
Implementing
This is where we start to build our MVPs, although we would suggest that maybe
some MVP work could be done in Analyzing, particularly if it was simple smoke
testing.
For Implementing, we follow the lean start-up cycle, a highly-iterative process of

building, measuring, and learning (see Figure 14.4).
Figure 14.4 – Epics in the Lean Start-up Cycle (© Scaled Agile, Inc.)
At each iteration of the MVP, we ask ourselves “Is the hypothesis proven?” If not,
then we pivot without mercy or guilt. If yes, we persevere until portfolio
governance is no longer required. These MVPs and the related Features will be
developed by the appropriate ART for that Value Stream.
Done
After evaluating an Epic’s hypothesis, it may or may not be considered to still be a
portfolio concern. An Epic is considered Done when sufficient knowledge or value
is achieved, or it is no longer a portfolio concern. Completing the fully envisioned
scope from the Lean Business Case is not a criterion. Instead, the Epic is Done if
the following are met:
It is ejected from the Portfolio Kanban by LPM in any of the earlier states.
The hypothesis is proven, and LPM has determined that additional portfolio governance is no longer
required. This WILL vary from organization to organization. However, the Epic Owner may have some
ongoing responsibilities for stewardship and follow-up.
The empowerment and decentralized decision-making of Lean budgets depend on

the guardrails of your particular organization. For example, the Epic is now in
production, creating ongoing value, and we are now only enhancing the Epic, so it
can now be considered in Horizon 1, particularly if we are extracting rather than
investing. That might cause us to determine it to no longer be a portfolio concern.
Lean Portfolio Management events and

governance
We have touched on the need for Lean Portfolio Management to provide approval
for the Epics before we start Implementing, but what are the other events that we
need to establish to support the progress of the Epics through the Kanban system?
We will explore that next.
There are three main LPM events:

The Portfolio Sync
PB
Let’s look at each of these in turn.
The Portfolio Sync

By its very definition, this is focused on a more operational level than the Strategic
Portfolio Review. It is typically held monthly and may be replaced or extended on a
given month by the Strategic Portfolio Review. Topics normally include the
following:
Reviewing Epic implementation: Review in-flight Epics and advance Epics through the Kanban system
Reviewing the status of Value Stream KPIs: Collect portfolio metrics and Value Stream KPIs
Addressing dependencies: Try and remove dependencies rather than manage dependencies
Removing impediments: Address blocks and impediments
This meeting generally lasts for 1 to 2 hours but is dependent on the size of the
portfolio.
PRO TIP
Initially, consider holding this meeting every two weeks and moving to a monthly cadence as the LPM
functions mature.
In addition, a suggested agenda to get you started is as follows:

1. Review the progress of actions from the last meeting.
2. Address blockers and impediments that require LPM assistance by assessing Epics from right to left on the
Portfolio Kanban.
3. Review and decide on MVP results.
4. Discuss go/no-go decisions.
5. Review new Epics (Objectives and Key Results and Threshold) and Epics in progress (enforcing exit
criteria).
6. Reprioritize the Portfolio Backlog, if required.
7. Summary of meet-after topics.

The focus of this event is on achieving and advancing the Portfolio Vision. It is
typically held quarterly, at least one month before the next PI Planning to enable
Value Streams to prepare and respond to any changes. Topics normally include the
following:
Reviewing strategy: Review and update the Strategic Themes and maintain the Portfolio Vision
Reviewing Implementation: Evaluate MVPs and make decisions
Reviewing budgets: Review investment horizons and other Lean budget guardrails
Unlike the Portfolio Sync, this is a more significant event that happens every
quarter and our experience is that this is typically a 1 or 2-day workshop. Again, to
get you started, here is a suggested agenda:
1. Review the progress toward the Strategic Themes and discuss whether they need to be amended.
2. Review the Portfolio Vision via a SWOT and TOWS (see Chapter 12) analysis and revise the Portfolio
Vision.
3. Identify the potential Epics.
4. Review the budgets and verify any adjustments.
5. Build the Portfolio Roadmap of themes, Initiatives, Epics, and Enablers.
6. Review the ART construct for the portfolio and confirm whether it requires adjustment to support the 2-3
year Portfolio Roadmap.
7. Review the portfolio spend performance in the last 6 months and verify adjustments to the funding
Horizon targets.
CAUTION
With the suggested agendas for the Portfolio Sync and the Strategic Portfolio Review, please
remember they are suggestions, and tailoring them to your context and portfolio will be required, but
we wanted to give you some ideas to help you craft an agenda.
Participatory Budgeting (PB)

We have already described this in Chapter 13; however, this event is typically held
twice a year; if budgets are adjusted less frequently, spending is fixed for too long,
limiting agility. More frequent budget changes may seem to support increased
agility but, in turn, may create too much uncertainty.
Summary
With this chapter, we learned that strategy and investment funding ensure the right
work is happening at the right time. Continuous and early feedback on current
initiatives, coupled with a Lean approach to funding, allows the portfolio to make
the necessary adjustments to meet its business targets. Lean governance closes the
loop by measuring portfolio performance and supporting dynamic adjustments to
budgets to maximize value (© Scaled Agile, Inc.).
In the next chapter, we will look at how we measure progress empirically across our
Portfolio.
Further reading
1. Set-Based Design: https://scaledagileframework.com/set-based-design/
2. Lean Portfolio Management: https://scaledagileframework.com/lean-portfolio-management/

15
Measuring Progress
“The problem….is metrics. It is a situation where if you can’t count what is
important, you make what you can count important.”
— James Willbanks (Army advisor)
There’s a challenge that we see consistently with our clients who struggle with
determining how well their ART is performing using concrete measurements. This
gets in the way of the vital Inspect and Adapt cycle that holds such an important
place in the Agile methodology. After all, if there’s no established definition of
success or consistent means of measuring performance against that goal, how will
you know what needs to be improved? And, if you can’t prove your first ART is
succeeding, how will you get approved to launch another ART?
To address this issue, many organizations make the mistake of tracking vanity
metrics.
These are simple measurements that look good on paper but that don’t really say
much about the success of the ART or track improvements that matter. Some
examples include the following:
How many ARTs have been launched
How many people have been trained
Velocity
These certainly are measurements you can (and probably should) track over the
course of establishing and scaling your ARTs, but they don’t really have any
bearing on how successful an ART is. They don’t identify opportunities for
improvement in terms of an ART’s effectiveness. They just report how busy the
portfolio has been.
How do we demonstrate that we have made improvements and that the new way of
working is worth adopting? How do we show that the ART is sustainably
improving in its ability to generate value?
The best way to demonstrate success is empirical. The Scaled Agile Framework
(SAFe®) initially developed its metrics as a “menu” of metrics (a whole list of
metrics that you could choose to measure) and then more recently as a series of flow
metrics, taking a lot of inspiration from Mik Kersten’s book, Project to Product [5].
However, we wanted to give you a set of basic metrics that every organization
should be able to collect and analyze without investing too much time and effort,
but it’s not enough to look at one value in a vacuum. Rather, it requires a balanced
view. In the end, we settled on four domains:
Figure 15.1 – Balanced scores for each ART
In this chapter, we will focus on the metrics that help determine whether the ARTs
within your portfolio are performing well. At the end of the chapter, we will
consider some additional portfolio measures as well.
We will look at each domain in turn but first, we need to understand the difference
between Leading and Lagging Indicators.
Leading and Lagging Indicators

Lagging Indicators are typically output-oriented—easy to measure but hard to
improve or influence. Leading Indicators, on the other hand, are typically input-
oriented—hard to measure but easy to influence.
Let us illustrate this with a simple example:
For many of us, a personal goal is weight loss. Your weight is a clear Lagging
Indicator that is easy to measure. You step on a scale and you have your answer, but
how do you actually reach your goal? For weight loss, there are two Leading
Indicators:
Calories consumed
Calories burned
These two indicators are easy to influence—you just need to eat less and move
more. However, they’re challenging to measure. When you order lunch in a
restaurant, the number of calories may not be listed on the menu. Even if you can
secure a calorie count for everything you eat, accurate figures will require precise
measurements—a digital food scale, measuring cups and spoons, an app to log
every bite you take, and a fitness tracker (with its own app) to estimate the calories
burned — and the self-discipline to keep up with it all.
Keep that example in mind as we break down useful metrics in the four domains
from Figure 15.1 in the upcoming sections.
Domain 1 – team health
Increasingly, talent acquisition is becoming harder and harder in an ever more
competitive world to attract the right people. And then, having secured the right
people, it is even more important that you retain them.
Yet, according to Gallup, 87% of employees worldwide are neutral, disengaged, or

actively disengaged at work. This disengagement correlates with the following:
37% higher absenteeism
18% lower productivity
15% lower profitability
Or, to put it another way, “34% of an employee’s annual salary is lost due to
disengagement.” (Forbes: May 2019)
The three measures in this domain to monitor the health of your people are as
follows:
Staff turnover
Sick days
Employee Net Promoter Score (NPS)
Staff turnover
Staff turnover is a Lagging Indicator—these staff members have already left.
However, trending this metric over time (monthly and annually) might point to an
underlying issue. It’s especially valuable when combined with anecdotal records of
what led to the attrition. Independent Exit Interviews help employers understand the
reasons why people leave. Working closely with your people function can increase
the value of this metric.
Figure 15.2 – Annual employee turnover rate calculated monthly

Staff sickness
Staff sickness is less of a Lagging Indicator. At least they have not left, but they are
still not at work. However, they might be at risk of leaving if ill health persists. This
is a potential indicator that there might be an environmental hygiene factor, or
maybe the individual or team is not working at a sustainable pace. Maybe burnout
is to blame.
CAUTION
Importantly, this isn’t a metric that gets published or discussed in front of the group; we don’t want
people to feel that they have to come to work. If they are ill, they need to recover.
Employee NPS
Most people will be familiar with NPS, but if you think you are not, you have
probably experienced it. You take your car to the garage to be serviced or contact
the customer service department for help with a product you’ve purchased. Soon
afterward, you receive an email with a survey asking the following:
“On a scale of 0 to 10, would you recommend <XYZ service/company> to a

friend?”
The NPS separates respondents into “promoters” who provide ratings of 9 or 10,
“passives” who provide ratings of 7 or 8, and “detractors” who provide ratings of 6
or lower. The NPS is derived by subtracting the percentage of detractors from the
percentage of promoters collected by the survey item.
So, with employees on an ART, we might ask the following:
“On a scale of 0 to 10, would you recommend a colleague to join this ART?”
The first few scores may be negative because of growing pains, so use your
judgment when it comes to publishing the NPS. However, tracking the percentage
improvement from one survey to the next and over time will produce a rolling
average that can demonstrate Continuous Improvement.
Good follow-up questions would be the following:

If you opted for 0 to 6, what do we need to do to improve?
If you opted for 7 to 8, what do we need to get you to 9 or 10?
If you opted for 9 or 10, what do we need to keep doing?
Let’s look at the next domain on our list.
Domain 2 – quality
If you can reduce the number of escaped defects and the Mean Time To Recovery
(MTTR) through test automation (%) and static code analysis, you open up more
time for creating new and exciting Features to delight customers.
However, there’s also a clear financial benefit to reducing the number of escaped
defects. The most recent numbers indicate software bugs cost the U.S. economy
$2.08 trillion each year [1]. A 2003 study [2] commissioned by the Department of
Commerce’s National Institute of Standards and Technology (NIST) offered the
following figures to consider in Figure 15.3. The study is old, so these figures are
low given the salaries and overheads of modern technical teams, but it illustrates
the dramatic escalation of cost if bugs aren’t caught early on.
Figure 15.3 – The cost of a software bug
The four measures in this domain are the following:

Escaped defects
MTTR
Test automation percentage
Code quality (static code analysis)
Escaped defects
The number of escaped defects is definitely a Lagging Indicator. It’s a simple
metric to collect and track as work is released throughout multiple ARTs. Think
about it as a measure of how much your customers have been upset.
There are several tools available for tracking escaped defects, including the
following:
Issue tracking systems such as JIRA or Asana: These tools allow you to create issues for escaped
defects, assign them to specific team members, and track their progress through the resolution process.
Test management tools such as TestRail or Zephyr: These tools can help you identify escaped defects
by tracking test results and generating reports on the status of test cases.
Bug tracking tools such as Bugzilla or Mantis: These tools are specifically designed for tracking and
managing bugs and defects. They allow you to assign priority levels, track progress, and generate reports
on the status of bugs.
MTTR
Closely related to the number of escaped defects, the MTTR tracks how long you
leave your customers upset—how much time it takes your teams to resolve the
escaped defects customers have experienced. To track MTTR, there are several
tools you can use, including the following:
Incident management platforms such as PagerDuty, OpsGenie, or VictorOps: These tools provide a
centralized location to manage incidents and track MTTR. They allow you to assign and escalate incidents
to the appropriate team members, and track the time it takes to resolve them.
Service desk software such as JIRA Service Management or Freshservice: These tools provide a way
to track and manage service requests and incidents. They allow you to track the time it takes to resolve
incidents and provide reports on MTTR.
Application performance monitoring (APM) tools such as New Relic or AppDynamics: These tools
provide real-time monitoring of your applications and infrastructure. They can help you quickly identify
and diagnose issues, and track the time it takes to resolve them.
Test automation percentage

As a foundational principle of DevOps, test automation is an important factor in
reducing escaped defects and simplifying error resolution by catching bugs earlier
in the development process. Automating testing allows for it to occur more quickly
and more often at various stages, and it reduces the impact of human error in the
QA process.
To track test automation, there are several tools you can use, including the
following:
Test management tools such as TestRail or Zephyr: These tools can help you track your test automation
efforts by providing a centralized location to manage and execute automated test cases. They allow you to
track the status of test cases, view results, and generate reports on test automation coverage.
Continuous integration and deployment tools such as Jenkins or Travis CI: These tools can help you
automate the execution of your test cases as part of your build and deployment process. They provide
metrics on test results, including pass rates and failures, which can help you identify areas for
improvement in your test automation.
Test automation frameworks such as Cypress or Robot Framework: These tools provide a structure
for organizing and executing your automated tests. They often include built-in reporting and tracking
capabilities that can help you monitor the status of your test automation efforts.
Code quality (static code analysis)

Static code analysis is a software debugging method that involves examining the
code without executing the Program software. It can provide an understanding of
the code structure and help ensure the code adheres to industry standards.
There are several tools available for code quality, including the following:
Static code analysis tools such as SonarQube, CodeClimate, or PMD: These tools can analyze your
code base to identify potential issues and suggest improvements. They can help you identify code smells,
security vulnerabilities, and other potential issues that can impact code quality.
Code review tools such as GitHub, Bitbucket, or GitLab: These tools can help you ensure that your
code meets your team’s coding standards and best practices. They allow you to review code changes and
suggest improvements before they are merged into your main codebase.
IDE plugins such as IntelliJ IDEA, Eclipse, or Visual Studio: These tools can provide real-time
feedback on code quality as you write and edit code. They can help you identify issues such as syntax
errors, code duplication, and formatting issues before they become bigger problems.
CAUTION
Ultimately, the best tools for Escaped Defects, MTTR, Test Automation, and Code Quality will depend
on the specific needs of your team and organization. It’s important to evaluate several options and
choose the one that best fits your needs.
Let’s move on to the third domain.
Domain 3 – productivity
As noted previously, it’s easy to get caught up in vanity metrics that just report how
busy the ART is. That’s not what productivity metrics should be about. Rather, these
productivity metrics should measure what value the ART produces and how
effectively it does so.
As the Feature Lead Time, Story Cycle Time, and Flow Efficiency are tracked over
time, ongoing successes can be celebrated and opportunities for improvement can
be identified and resolved. Waste is eliminated and productivity increases. As that
occurs, the number of releases—the measure of value reaching the customer —
should first rise, then become predictable.
Most problems with your process will surface as delays. Most of the time spent
getting to market is a result of these delays. Reducing delays is the fastest way to
reduce time to market without anyone working any harder, but you need to identify
the delays.
Visualizing your Continuous Delivery Pipeline is critical. An RTE’s primary

responsibility is to manage and optimize the flow of value through the ART. This
comes down to tracking and acting on these metrics.
This domain contains four measures:

Feature Lead Time
Story Cycle Time
Activity Ratio (aka Flow Efficiency)
Number of Deployments
Feature Lead Time

The Feature Lead Time encompasses the complete time period between when a
Feature is requested and when it’s delivered. A Lean mindset requires that teams
continuously strive to shrink this period since doing so is indicative of improving
speed and efficiency and/or reducing waste in the system.
Story Cycle Time
The Story Cycle Time is a subset of the Feature Lead Time, focusing on just the
period during which a given story or task is considered a work-in-progress, from
the point it is pulled from the backlog to when it is considered done and ready for
delivery.
Like the Feature Lead Time, a reduced Story Cycle Time indicates the team is
working more efficiently and that wasted time—usually due to bottlenecks in the
transition between states of work—is being eliminated.
If the iteration is 2 weeks, a story needs to be small enough to be completed within

one iteration, ideally 1 to 5 days; a good average story cycle time is 2 to 3 days.
And yet we still see stories that take more than 10 days. Now, there may be delays
that we need to focus on, or the story may have just been too big and we need to
look at patterns for splitting User Stories [3].
Activity Ratio (aka Flow Efficiency)

Another subset of the story cycle time is the processing time. Process time refers to
the time during which the story or Feature is being actively worked on.
By dividing the lead time into the process time, you can track the Flow Efficiency
or Flow Efficiency. This ratio describes how much of the total lead time is actually
spent actively adding value—working on moving the Feature or story toward
completion.
Tracking your team’s workflow efficiency is crucial for optimizing the whole
process.
In the following example, the process time is 6 hours and the lead time is 7 weeks
(or 280 hours, assuming a standard 40-hour workweek):
Figure 15.4 – Activity ratio (an example)
The Flow Efficiency is 2% (6/280 x 100). So, 98% of the time the work is in a
waiting state. While this sounds incredibly low, the average worldwide Flow
Efficiency is 1 to 5%.
“All we are doing is looking at the timeline from when the customer gives us
an order to when we collect the cash. And we are reducing the timeline by
reducing the non-value-added wastes.”
—Taiichi Ohno, father of Lean Manufacturing
To track Feature Lead Time, Story Cycle Time, and Activity Ratio, there are several
tools you can use, including Agile Management Tools such as JIRA, TargetProcess,
or Asana. These tools allow you to create and track User Stories and Features, and
estimate the time it will take to complete them. They provide reports on progress
and can help you identify areas where the Activity Ratio can be improved.
But heed the same caution as with quality – it’s important to evaluate several
options and choose the one that best fits your needs.
Number of deployments
First, let me explain the difference between Continuous Deployment and Release on
Demand:
Continuous Deployment is a process that takes validated Features in a staging environment and deploys
them into the production environment, where they are readied for release – they are not released; they are
in a passive state
Release on Demand is a process that deploys new functionality to production and releases it immediately
or incrementally to customers based on demand – it is now in the hands of customers, hopefully earning
revenue
I generally recommend organizations focus on deployments rather than releases

because deciding what to release and when requires careful consideration and a
customer-centric mindset. However, depending on your context, there may be merit
to tracking both.
There are several tools available for code deployment, including the following:
Continuous Integration / Continuous Deployment (CI/CD) tools such as Jenkins, GitLab CI/CD, or
CircleCI: These tools allow you to automatically build, test, and deploy your code changes to your
development, staging, and production environments. They can help you ensure that your code is always up
to date and functioning as expected.
Configuration management tools such as Chef, Puppet, or Ansible: These tools allow you to manage
the configuration of your servers and infrastructure as code. They can help you deploy and manage your
code in a consistent and repeatable way across different environments.
Cloud deployment tools such as AWS CodeDeploy, Google Cloud Deployment Manager, or Azure
DevOps: These tools provide a centralized location for deploying your application to cloud-based
infrastructure. They can help you automate your deployment process and scale your application as needed.
A final reminder that selecting any tool will depend on the specific needs of your
organization and team. It’s important to evaluate several options and choose the one
that best fits your needs.
PRO TIP
According to Gene Kim (a co-author of The DevOps Handbook: How to Create World-Class Agility,
Reliability, and Scalability in Technology Organizations), the table stakes for an organization is 10
deployments per day.
Finally, let’s look at the last domain.
Domain 4 – predictability
Predictability measurements should never be used as a basis for saying, “You’re not
doing enough” or for instigating competition between teams.
But, from the standpoint of supporting PI Planning and the long-term success of an
ART, predictability is paramount. It’s never going to be an exact science—and it
shouldn’t be—but having a solid basis for what and how much work the ART can
commit to each PI is strategically valuable.
This final domain has three measures:

ART Predictability
ART Velocity
Features/Enablers/stories planned versus accepted
ART Predictability
The ART Predictability measures compare the Planned Business Value to the
Actual Business Value achieved. Here’s how it’s determined:
1. In the second team breakout on day 2 of PI Planning, Business Owners circulate and assign Business Value
to the team’s PI Objectives from low (1) to high (10).
2. As part of the PI System Demo at the end of PI, teams meet with their Business Owners to self-assess the
Business Value they achieved for each objective. They ask, “Did we deliver all the functionality requested,
to the required quality, and on time?”
3. Each team’s planned versus Actual Business Value is then rolled up to the ART level in the ART
Predictability Measure.
ART Predictability measures how well a Train can plan and meet its PI Objectives.
For a business to plan and execute effectively, ARTs should generally satisfy most
of the Committed PI Objectives and one or more of the Uncommitted PI
Objectives. This approach typically results in an average of 80-100% of the total
planned.
ART Predictability is an important measure for organizations that use SAFe®. The
predictability of an ART refers to its ability to consistently deliver working
software at the end of each PI, which is typically a 10-12 week period in SAFe®.
There are several reasons why ART Predictability is important. First, it allows the
organization to plan and execute work more effectively. When an ART is
predictable, the organization can rely on it to deliver working software at the end of
each PI, which helps ensure that the overall solution stays on track. This
predictability is particularly important in large, complex solutions where many
teams are working together, as it helps to coordinate their efforts and ensure that
everyone is working toward the same goal.
Second, ART Predictability helps build trust between the organization and its
Business Owners. When Business Owners can rely on the ART to consistently
deliver working software at the end of each PI, they are more likely to trust the
organization’s ability to manage the solution effectively. This can lead to better
relationships between the organization and its Business Owners.
Finally, ART Predictability is important for Continuous Improvement. When an

ART is predictable, the organization can analyze its performance and identify areas
for improvement. This can help the organization refine its processes and practices,
which can lead to even greater predictability and improved outcomes over time.
Overall, ART Predictability is an important measure as it helps organizations to

plan and execute solutions more effectively, build trust with Stakeholders, and
continuously improve their processes and practices. Additional information about
Predictability Measures can be found in Chapter 10.
PRO TIP
If you are an SPC in good standing, you will have access to the PI Execution Toolkit, which includes a
simple Excel Spreadsheet that allows you to track and calculate ART Predictability across the teams
on the ART and then a rolled-up measure for the ART.
ART Velocity
As a measure of productivity, velocity alone is not a valuable metric. The raw data
is limited in scope and ever-changing based on multiple factors. However, ART
Velocity does factor into forecasting and road mapping, as it provides a reasonable
average from which to derive each team’s general capacity and that of the entire
ART.
ART Velocity is the summation of all the Story Points delivered by the teams for
each PI.
There are several reasons why tracking ART Velocity is important:

Helps with planning: By tracking the ART Velocity, organizations can better plan and forecast how much
work the ART can deliver in future PIs. This allows the organization to set realistic expectations with
Business Owners and ensure that the team is not over-committing to work that they cannot realistically
deliver.
Helps with Continuous Improvement: By tracking the ART Velocity over time, organizations can
identify trends and patterns in the team’s performance. This can help the organization to identify areas
where the team is struggling and make adjustments to improve their performance in future PIs.
Helps with coordination: When multiple teams are working together on one or more large, complex
solutions, tracking the ART Velocity can help ensure that everyone is working toward the same goal. By
understanding how much work each team can deliver in a given PI, the organization can better coordinate
the efforts of the teams and ensure that they are all aligned towards the same objectives.
Helps with transparency: Tracking the ART Velocity can help improve transparency within the
organization. By making the ART Velocity visible to Business Owners, the organization can demonstrate
the team’s capacity for delivering value and build trust with Business Owners by providing evidence of
progress and successful delivery.
Reviewed regularly as a trend, an ART’s Velocity can lay the foundation for greater
predictability, which, in turn, supports more efficient and strategic productivity.
CAUTION
While it is possible to compare velocity between teams and ARTs, it is generally not recommended to
do so for a number of reasons.
Comparing team or ART Velocity can be misleading. Velocity is influenced by a

wide variety of factors, including team size, skill level, the complexity of the work
being done, and the tools and processes used by the team. Comparing the velocity
of two different teams or ARTs without taking these factors into account can be
misleading and can result in unfair comparisons.
Velocity is intended to be used as an internal measure of a team’s or ART’s

performance, rather than as a benchmark for comparison with other teams or ARTs.
By focusing on improving their own velocity, teams and ARTs can continuously
improve their performance and deliver more value to their Stakeholders. Comparing
team velocity can distract teams from this focus and lead to a fixation on
outperforming other teams rather than delivering value to Stakeholders.
Velocity is a measure of how much work a team can deliver in a given period of
time, and it is specific to each individual team or ART. It is a planning aid, not a
comparative performance measure!
Features/Enablers/Stories Planned versus Accepted

Similar to ART Velocity, the planned versus accepted metric is of little value on a
per-iteration basis. Rather, it serves as context for the ART Predictability Measure.
One company I worked with said that their predictability was about 80%. However,
they only completed four or five Features per PI when the business expected much
more. Predictably underachieving isn’t what we’re aiming for. It was a signal to
explore whether there was a problem.
Tracking the Features Planned and the Features Accepted is an important measure
as it helps organizations to plan and prioritize their work effectively, measure their
progress toward their goals, and identify areas for improvement. By focusing on
delivering the Features that are most important to Business Owners and
continuously improving their processes, organizations can ensure that they are
delivering maximum value to their Business Owners and achieving their objectives.
Summary
At this point, I think it’s important to take a step back and note that all of the
metrics we discussed—as important and helpful as all of them are—are not the
“final answer” in terms of measuring the success of an ART. The overarching
purpose of the ART—and really of everything we do as Agile organizations—is to
deliver value to our customers.
While many businesses tend to oversimplify customer value by limiting it to saved

time and money, the truth is that value means different things to different people.
Bain & Company identified 30 different elements of value that fall in line with
Maslow’s famous hierarchy of needs [4]. Saving time and money are both
functional elements of value, and they’re important, but customers may actually
yearn for emotional, life-changing, and social impact value even more.
So, consider the metrics we’ve discussed as Leading Indicators that you can use to
gauge the value the ART delivers to customers, but, to make that work, you need to
understand what value means to your customers. You need to plan and optimize the
ART to focus on delivering that value. Doing so will translate to greater customer
loyalty and increased revenue over time.
In Chapter 16, we’ll look at the dimensions of Leadership Alignment.
Further reading
1. How much could software errors be costing your company? https://raygun.com/blog/cost-of-software-
errors/
2. The True Cost of a Software Bug: Part One: https://www.celerity.com/insights/the-true-cost-of-a-software-

bug
3. The humarzing work guide to splitting user stories (https://www.humanizingwork.com/the-humanizing-

work-guide-to-splitting-user-stories/
4. Elements of Value: https://hbr.org/2016/09/the-elements-of-value
5. Project to Product by Mik Kersten: https://Projecttoproduct.org/the-book/

16
Leadership Alignment
Leadership is critical to successfully implementing SAFe®, and effective Lean-
Agile Leaders understand why an organization is adopting SAFe® and take
responsibility for leading the change. Evidence from thousands of SAFe®
implementations shows that, with engaged leadership, achieving better business
results from new ways of working can happen very quickly. It also requires leaders
to demonstrate the needed behaviors to be successful in the digital age and to be
proficient in the practices of leading successful change.
Without the active involvement of leaders, a large-scale Agile transformation is far

less likely to succeed. Leaders must invest in their change journey and proactively
work to shift old mindsets and habits before they can help others do the same. Tera
Allas, Will Fairbairn, and Elizabeth Foote reported that McKinsey & Company’s
research found “transformations where leaders model the change themselves are
more than four times more likely to succeed than transformations where they do
not.” Leadership buy-in can help increase the chances of a successful
transformation from 30% to 75%.
Organizations often begin their SAFe® journey without strong leadership support.
They fall short of the desired improvements in business outcomes that justified the
investment in SAFe®, meaning in many cases that the transformation stalls.
In this chapter, we will discuss the following topics:

Moving from a fixed mindset to a growth mindset
Leading by example
Moving from a fixed mindset to a growth

mindset
“The basic tenets of Lean challenge many of the aspects of traditional
management theory and calls for a mindset that is foreign to most executives.”
– Jacob Stoller, author of The Lean CEO: Leading the Way to World-Class
Excellence
Many leaders that we encounter have been in leadership positions for several years.
They rely on the experience they have gained over the previous decades, which has
served them well and allowed them to achieve a senior position within their
organization. However, that experience was based on a different age of technology.
Let’s consider two conversations with senior executives from two different
organizations.

I was talking to a senior airline executive who was of a certain age and was concerned that he was
tasked with leading a digital transformation. He said, “I am digitally naive while 25% of my staff are
under the age the age of 30 and are digitally native and I am expected to lead a digital
transformation.”
He felt that his experience would put him at a disadvantage when in a position of leadership.
Conversely, consider a different conversation with the most senior person in a government
organization who had lunch with the CEO of a major bank. During their lunch, they agreed that there
were three key core ingredients to change:
A transformed approach to partnerships
An Agile approach to problem-solving, giving power and capability to those closest to the issue
Most importantly, a learning culture including leadership, where those with the most influence
must do as much, or more, learning than anyone else
The last point was critical; this senior leader realized that he had to move from a fixed mindset to a
growth mindset. But this is not common – the reverse is more often the case, as in the example of the
initial reaction of the airline executive.
As Coaches, we want to encourage our leaders to attend a 2-day Leading SAFe®

course, which is often met with the following type of response:
“You have clearly not read my badge; I am a very successful person, and I wouldn’t
be where I am today if didn’t know a lot of stuff.”
Sound familiar? Some of what they know, which was right even 2 years ago, is now
wrong. Senior leaders are aware of the need to change but they have largely been
stuck in the past, relying on traditional managerial techniques and frameworks.
In addition, they do not want to invest time in learning – “I don’t have time for your
2-day course.”
One response from a very experienced consultant was, “If you are too busy, then so
am I. Let me know when you have more time, and I will return.”
Now, if you are an internal consultant employed by the company, then this response
might be career-limiting! A better response would be, “Surely, as a senior leader,
you recognize that attending a Leading SAFe® course is a moral obligation so that
you understand how you are asking your organization to change before inflicting
that change upon the organization.”
That said, a 2-day class can still be a significant ask for a team of senior leaders. As
a consequence, Scaled Agile, Inc. created, in conjunction with several seasoned
practitioners, an executive workshop that can be delivered in half a day or so. If you
are a SAFe® Practice Consultant (SPC) in good standing, then you can download
this toolkit from SAFe® Studio.
CAUTION
This is not a substitute for Leading SAFe®; it is not the case that if you can’t commit to a 2-day class,
then there is a half-day option. The executive workshop should be treated as an invitation to learn
more and should be followed by a Leading SAFe® course.
PRO TIP
There is a danger that you will deliver the executive workshop out of the box – that is, unchanged.
While there is some excellent material within the workshop, our experience is that, when delivering it
as a vanilla workshop, it won’t land 9 times out of 10 because it is not context-specific. If you want to
have an impactful workshop, spend time doing some empathy interviews with the leaders that are
going to attend the workshop to understand their challenges. Then, construct a workshop that
specifically talks about these challenges. However, remember the rules of the toolkits:
Permission to use the toolkits is granted to SAFe® certified members whose membership is in
good standing and only for use as part of their SAFe® implementation.
A member may reproduce, modify, use, and distribute handouts and templates of the material in
hard copy or PDF format as necessary. However, the full toolkit itself may not be distributed to or
used by anyone other than the member who downloaded it.
A member may add slides and content unique to a specific context but such additions shall not
change the meaning, purpose, or the original material. Removal of any trademarks, logos, or
copyright notices is also prohibited.
In essence, you can add and delete slides but do not change any existing slides.
However, even a half-day workshop still might be a bridge too far. Therefore, the
final option is to use the publicly available Introducing SAFe®, which can be
downloaded from the Scaled Agile Framework website from Resources. If you only
have 90 minutes to 2 hours, then this might be an option – again, enough to whet
the appetite of the audience to learn more.
Education alone is not enough. One of my colleagues used to say, “Would you get
on a plane if the pilot had only been on a course and maybe passed an exam?” Of
course not – I would want to know that the pilot had spent some time practicing
his/her craft under the watchful eye of a more experienced pilot. Education is
important, but now, we need our leaders to start experiencing the practices for
themselves. Let’s explore that next.
Leading by example
“Setting an example is not the main means of influencing others, it is the only
means.”
– Albert Einstein
Leading by example refers to the practice of setting a good example for others to
follow, either through your actions or behavior. It is a leadership style that
emphasizes setting a positive example for others to emulate, rather than simply
giving instructions or commands. This can be an effective way to inspire and
motivate others and can also help to build trust and credibility as a leader.
What are the behaviors that leaders should embrace to set the right example?
Insatiable learning
Authenticity
Emotional Intelligence (EI)
Courage
Growing others
If you are a Coach and perhaps contemplating delivering a Leading SAFe® class,
you will find there is only one slide in lesson 6 on leading by example, with very
little trainer guidance other than listing the six behaviors, accompanied by a very
short description. So, in this section, we want to give you more of a narrative that
you can use, list some of the benefits of each of the behaviors, and provide some
practical advice on how to engender the behaviors with the leaders.
Insatiable learning
This depicts how leaders engage in the ongoing, voluntary, and self-motivated
pursuit of knowledge and growth and how they encourage and support the same in
others.
Insatiable learning is important because it drives individuals to continuously seek

out new knowledge and experiences, leading to personal and professional growth,
improved problem-solving abilities, and the ability to adapt to changing
circumstances. Additionally, insatiable learning fosters innovation and creativity
and can lead to advancements in various fields. Ultimately, insatiable learning is
essential for success in a rapidly changing and competitive world.
PRO TIP
A very simple technique is to create a leadership book club; in fact, what I have done is buy the
books myself and hand them out individually to the leadership team. Try and select a book that will
resonate with their situation. Then, set up a regular cadence to review the book in small increments –
for example, a chapter a week. As a Coach, start creating a reading list yourself; practice what you
preach!
Authenticity
This requires leaders to model the desired professional and ethical behaviors. By
acting with honesty, integrity, and transparency, leaders are true to themselves and
their beliefs.
Authenticity is important because it allows individuals to be true to themselves and

their values, rather than pretending to be something or someone they’re not. When
people are authentic, they are more likely to be genuine and trustworthy and build
deeper and more meaningful relationships. Additionally, authenticity can lead to
greater personal satisfaction and well-being, as well as improved mental and
physical health.
In organizations, authenticity from leadership can also lead to better employee

engagement and a more positive workplace culture.
PRO TIP
Encourage your leaders to be honest with the team and not hide away from the real challenges the
organization is facing, and then be open to feedback. I often find that leaders are fearful of openly
declaring what they consider to be “bad news.” The reality is that if the leaders don’t share the
challenges, then the team is, more often than not, aware and because you, as a leader, have not
shared this with them, they draw conclusions that are normally much worse than they are! Treat your
team as adults, not children.
Emotional Intelligence
This describes how leaders identify and manage their emotions and those of others
through self-awareness, self-regulation, motivation, empathy, and social skills.
EI is important because it helps individuals understand and manage their own

emotions, as well as the emotions of others. This can lead to a variety of benefits,
both personally and professionally.
Some of the benefits of EI include the following:

Improved communication: EI allows individuals to understand and respond to the emotions of others,
which can lead to more effective communication and better relationships
Leadership: EI is considered a key component of effective leadership, as leaders with high EI are better
able to understand and respond to the needs of their team members
Better decision-making: EI can help individuals make better decisions by considering the emotional
impact of their choices on themselves and others
Resilient: EI can also help leaders be more resilient in the face of stress and adversity, as well as achieve
greater success in their personal and professional lives
In organizations, having a high level of EI among leadership and employees can

lead to a more positive work culture, better teamwork, and better performance.
PRO TIP
This is a hard one. However, something I have found effective is bringing some diversity and
inclusion into the leadership team. I have seen and have been part of a leadership team where there
are very similar traits among the leaders and a distinct lack of EI. Consider bringing someone that
brings that EI diversity to the leadership team to create some balance.
Courage
This is essential for leaders to guide their organizations through the rapidly
changing dynamics of the digital age. It requires leaders to embrace vulnerability,
take appropriate risks, and engage in difficult but necessary conversations to
challenge the status quo.
Courage is important for leaders in organizations because it allows them to make

difficult decisions, take calculated risks, and stand up for their values and beliefs. It
also enables leaders to address challenging situations and to communicate
transparently with their teams, even in the face of criticism or opposition.
Furthermore, courage is essential for leaders to drive change and innovation within
their organizations, and to create a positive and inclusive workplace culture. With
courage, leaders are better equipped to navigate uncertainty, embrace failure as a
learning opportunity, and inspire their teams to reach new heights.
PRO TIP
This is another hard one. A good tip for leaders to improve their courage in an organization is to
practice self-reflection and self-awareness. This involves them regularly evaluating their thoughts,
feelings, and behaviors, and gaining a deeper understanding of their values, strengths, and
limitations. Another tip is to actively seek out new challenges and opportunities for growth, as this
helps build confidence and resilience. Additionally, seeking out supportive relationships, such as a
mentor or Coach, and being part of a supportive community can provide valuable encouragement
and guidance as leaders navigate difficult situations. Finally, regularly engaging in self-care and
stress management activities can also help leaders maintain their courage and well-being.
Growing others
This encourages leaders to provide the personal, professional, and technical
guidance and resources that each employee needs to assume increasing levels of
responsibility and decision-making.
Growing others is important because it helps them develop the skills and abilities of
individuals, which can lead to a variety of benefits both personally and
professionally.
Growing others is important for the following reasons:

Develops future leaders: By investing in the development of others, organizations can ensure that they
have a strong pool of talented individuals to draw from when leadership positions become available
Improves team performance: When team members are allowed to develop their skills and abilities, they
are more likely to be engaged and motivated, which leads to improved team performance
Builds a positive work culture: When individuals feel that they are being invested in and developed, they
are more likely to feel valued and respected, which can lead to a more positive work culture
Growing others is also a way to develop a more diverse, inclusive, and equitable
society as it provides opportunities for underrepresented groups to learn and grow,
as well as to achieve their full potential.
PRO TIP
The best thing the leadership can do is commit to the Innovation and Planning (IP) Iteration. Not only
do we set aside things for innovation, which is a key motivator for knowledge workers, but normally,
time is also reserved for Continual Professional Development (CPD). This could be team-based (for
example, a course) or individual self-directed learning (for example, reading).
This moves the authority for decisions to where the information is, prepares teams
to make decentralized decisions by investing in their technical competence, and
provides organizational clarity with decision guardrails.
This is the behavior that we find that leaders struggle with the most; to them, it feels
like they are losing control. And yet, those leaders have recruited these employees
that are bright and intelligent people but then treat them like kindergarten children.
Decentralized decision-making is important because it allows individuals and teams

at all levels of an organization to make decisions, rather than relying solely on
decisions made by leadership. This can lead to a variety of benefits:
Faster decision-making: When decisions can be made at the lowest level of an organization, they can be
made more quickly, as individuals and teams are closer to the issues at hand and don’t have to wait for
approval from higher-ups
Increased ownership and accountability: When individuals and teams are given the authority to make
decisions, they are more likely to feel a sense of ownership over and accountability for the outcomes,
which can lead to better performance and results
Better problem-solving: Decentralized decision-making allows individuals and teams to identify and
solve problems at the local level, which can lead to more effective problem-solving and improved
performance
Decentralized decision-making is important because it allows for faster, more

effective decision-making, increased ownership and accountability, better problem-
solving, greater creativity and innovation, more engagement and motivation, and
more effective and efficient use of the people.
PRO TIP
There are two options – get your leaders to read Turn the Ship Around [1] by David Marquet or watch
a YouTube video called Greatness, which is a 10-minute summary of the book. I find that this is
extremely powerful with the leadership team when talking about decentralized decision-making:
https://www.youtube.com/watch?v=OqmdLcyES_Q.
Understanding these behaviors is all well and good, but how do we get our leaders
to practice these leadership behaviors?
PRO TIP
Our experience is that you need the leadership team to operate as an Agile Team. That way, they can
start to practice what they have been taught in a psychologically safe environment surrounded by
their peers. We normally start with an education piece (see the Moving from a fixed mindset to a
growth mindset section), followed by a series of follow-up workshops, Coaching, and support. Being
able to practice operating as an Agile Team will better help them lead an Agile organization, as well
as demonstrate the behavior we have discussed in this section.
So, let’s have a look at what it takes to lead an Agile organization.

As the speed of business increases exponentially, many leaders find themselves in
an awkward position: they need to fundamentally change how they do business, but
they are unsure of how to approach such a monumental undertaking. The pandemic
and all its effects have greatly accelerated what was already a dizzying situation.
The eight steps to implementing change were first outlined in John Kotter’s 1996
bestselling book, Leading Change [2]. They have since become the foundation of
countless successful transformations in organizations of all sizes across the globe.
They are acknowledged as foundational principles by most change management
experts.
The eight steps are as follows:

Establish a sense of urgency
Create a powerful guiding coalition
Develop the vision and strategy
Communicate the vision
Empower employees for broad-based action
Generate short-term wins
Consolidate gains and produce more wins
Anchor new approaches in the culture
These eight ideas are the responsibility of the executive and senior management.
The purpose of this section is not to dive deep into all eight steps — that’s what the
original book and its many follow-ups are for. We are going to focus on the steps
and particularly on the aspects where we feel many leaders and transformations
have the greatest opportunity to improve.
Step 2 – creating a powerful guiding coalition

“A volunteer army needs a coalition of effective people – born of its own ranks
– to guide it, coordinate it, and communicate its activities.”
– John Kotter
A critical and powerful step in Leading Change is creating a powerful guiding

coalition. Since it’s so vital, and so many organizations get it wrong, this is where
we’ll be spending the most time.
When discussing the guiding coalition, Kotter uses the analogy of an engine in a
vehicle. If we can imagine that the organization is a vehicle and transformational
change is the destination, then the guiding coalition is the engine that powers the
vehicle’s movement.
SAFe®’s imperfect guiding coalition

In the parlance of SAFe®, this coalition has three parts:
SPCs
Training Lean-Agile leaders
Lean-Agile Center of Excellence (LACE)
Unfortunately, this rubric often falls short when attempting to establish a powerful
guiding coalition in organizations.
For one thing, the LACE is rarely fully understood, and it requires a lot of
explanation and solutioning to get right. This confusion is reflected in the many
names it goes by across various organizations:
Agile CoE
Agile Working Group
Lean-Agile Transformation Team
Learning and Improvement Centre
The LACE is a small team of people dedicated to implementing the Lean-Agile

way of working, but it’s important to note that many of their responsibilities are
shared with numerous SPCs who may or may not be regular members of the LACE.
As a result, the responsibilities of various parts of SAFe®’s guiding coalition

overlap, often creating confusion, inefficiency, and lack of cohesion. These
“engines” aren’t tuned up and running smoothly, so they often fail to provide
sufficient forward momentum for the “vehicle.”
SAFe®’s guiding coalition lacks power

As Kotter outlines, we need a “powerful guiding coalition.” That means putting
together a group of people with enough power to lead change; a powerful force that
will be able to sustain the process to develop the vision, communicate it, eliminate
key obstacles, and more. Low-credibility committees often run on empty.
SAFe® suggests that a senior C-level leader should act as the LACE Product
Manager. Is this enough? Kotter says otherwise:
“Someone talks the boss into putting this staff officer in charge of a task force
that includes people from several departments and an outside consultant or
two. This group may include an up-and-coming leader in the organization, but
it does not have the top three or four individuals in the executive pecking
order. Because the group has an enthusiastic head, the task force makes
progress for a while… they figure out quickly that it has little chance of long-
term success… From the outset, the group never had the credibility necessary
to provide strong leadership. Without that credibility, you have the equivalent
of an eighteen-wheeler truck being propelled by a lawn mower engine.”
An evolved take on the guiding coalition

After years of experience working with organizations undergoing massive change,
our view on the sufficiently “powerful guiding coalition” has evolved. Like
SAFe®, it has three elements:
An Executive Action Team (EAT)
A Change Team (that is, the LACE)
Non-Executive Directors (NEDs) – a term more familiar to a UK audience – or External Advisors (EAs)
The EAT
The term EAT works well to describe this first element of the guiding coalition:
Executives are people that have positions of power and proven leadership. And because they are senior
people, we rightly expect that they will only fulfill a part-time role.
The EAT is an action team, not an inaction team. They are focused on taking decisive actions to move the
process of change forward continually.
To succeed, they need to operate as an effective team. The lack of cohesion and the inefficiencies that
often plague SAFe® based coalitions can – and must – be avoided.
The EAT’s responsibilities include the following:

Establishing the intent and outcomes of the transformation in business terms
Transforming Epic governance, including the approval and prioritization of transformation Epics and
validating their delivered benefits
Establishing organizational KPIs
Communicating all of these things
Removing systemic and organizational impediments

One real-life example of an effective EAT consists of five senior people that are cross-functional and
cover the length and breadth of the change. They meet every week for 30 minutes to approve new
change experiments (see The Change Team section), review experiments in progress, and remove
any impediments. These new experiments are socialized with the EAT before every meeting; these
meetings are facilitated by an experienced Coach.
The Change Team
The Change Team is where the rubber hits the road. They are the bridge between
the EAT and the actual transformation. These are the people dedicated to driving
the transformation – much as SAFe®’s LACE is described – but everyone
understands what the Change Team does.
Their responsibilities include the following:

Acting as an exemplary Agile Team helping run the change experiments
Coaching and supporting the EAT to fulfill its role within the guiding coalition
Facilitating the operation of the guiding coalition, including managing and driving the portfolio’s flow
Providing Coaching and training to key Stakeholders and teams
Fostering Communities of Practice (CoP)
Communicating progress
Implementing Lean-Agile focus days with guest speakers, and presenting internal case studies — Agile
briefings
Promoting continuing Lean-Agile education
Extending Lean-Agile practices to other areas of the company
In model organizations we have worked with, the Change Team consists of Coaches
and SMEs from the organization; the latter embeds a new way of working.
It is important to state that depending on the nature and size of the transformation,
multiple Change Teams may be required. In that case, running the Change Teams as
an ART should be considered as a way to align the change activities.
Non-Executive Directors (NEDs) or External Advisors (EAs)

The term NED is something that the UK market will recognize, but it may not
translate across other countries, so the alternative, EA, expresses the same thing. It
is very easy for the EAT to operate in an echo chamber, so NEDs provide external
thinking and critical feedback, acting as a conscience for the EAT.
These individuals can be drawn from the following fields:

Someone from a part of the same organization that is showing transformed benefits
Someone from a similar organization that epitomizes the transformation (preferably from the same
industry)
Someone from a different organization that is going through the transformation (possibly from a different
industry)
An experienced consultant who understands what a good transformation looks like
This combination of elements – when populated with experienced, enthusiastic

participants and supported by the larger organization – is in the best position to
effectively guide change at an organizational scale.
I would expect the NED to regularly attend the EAT meetings to provide an
independent perspective on the organization’s transformation, performance, and risk
management, and to bring outside expertise and mentorship to the EAT. By
fulfilling these responsibilities, NEDs can help to ensure that the company is
operating in the best interests of its Stakeholders and is positioned for long-term
success.
Other important steps to implement

organizational change
Now, let’s focus briefly on other important steps outlined in Leading Change and
what organizations with a powerful guiding coalition in place should be focusing
on.
Steps 3 and 4 – developing and

communicating the vision and strategy
With all change initiatives, it is vital to define the purpose – the vision for the result
of the change – and then encapsulate it in a set of Strategic Themes expressed as
Objectives and Key Results (OKRs). This work is done by the EAT with input from
the Change Team and NEDs.
Once an overarching Vision has been established and the Strategic Themes have
been designed, all future transformational activities will be evaluated against these
benchmarks to determine their feasibility, sustainability, viability, desirability, and
priority. That way, the work towards the change remains value-based and aligned
with the established end state the organization is striving for.
To be of value to the entire organization, the Vision and Strategic Themes must be
effectively communicated. Otherwise, as change begins rolling out, individuals will
not understand the “why” behind uncomfortable actions they’re being asked to take.
This is a recipe for pushback and eventual failure.
People often under-communicate, failing to provide sufficient information to

engage or create buy-in. Or they send out too much information, leaving people
unwilling or unable to absorb it. Inconsistent messaging can be a problem as well.
Generally speaking, the best option is to go visual – a picture paints a thousand

words and it is more engaging without overstaying its welcome.
Communicating the vision and strategy is a big part of empowering employees to

take action in support of change, but more is required.
Collecting ideas
Good ideas can come from anywhere, so it’s necessary to have a mechanism for
capturing these ideas – a funnel where all new ideas are welcome, and contributors
can be confident their ideas will be fairly considered. Many tools can work well to
collect these ideas, from Sharepoint sites to Google Forms. A link to the established
tool should regularly be made visible to the organization.
Evaluating ideas
Of course, some ideas will have potential, while others will not. Ideas may be
rejected because they are not aligned with the Strategic Themes or are not feasible,
viable, desirable, or sustainable for other reasons.
Incorporating Epic Hypothesis Statements

Those that pass this initial review will then progress to reviewing where we create a
one-page Epic Hypothesis Statement (EHS). This tool defines the idea and the
OKRs that could be used to validate progress if it were to be pursued. This
information can be valuable both in reviewing the idea further and in creating
experiments, should it be approved for implementation.
Pitching the idea to the EAT

The person will then pitch the EHS to the EAT. This isn’t carried out like an
episode of Shark Tank (US) or Dragon’s Den (UK); it is more for alignment,
allocating skilled people, and removing the key obstacles. If approved, it will be
prioritized in a backlog.
Step 6 – generating short-term wins

Sustainable positive change occurs slowly and steadily, not in massive fits and
starts. That’s why, when work is done to implement Epics outlined on the Portfolio
Kanban, it’s set up in the form of small experiments.
“Small” may mean a change is first implemented in one team or department, with a
limited scope or application. It also always runs for a set period – usually for no
more than 3 months. That is sufficient to evaluate its efficacy against the OKRs, but
not so long that it adversely affects long-term productivity or impacts other
departments too severely.
The progress of these experiments is regularly reported back to the EAT. The
Change Team will help run these experiments with the necessary input from the
EAT.
If the experiment fails, the idea can be re-evaluated and rewritten or rejected. If a
change experiment succeeds, then it can be prioritized to be scaled up and rolled out
across the organization and embedded into the new way of working. These
decisions are made by the EAT and their decisions on prioritization dictate when the
change will be implemented company-wide. These change experiments can be run
with a small Change Team, but when they need to be rolled out across the
organization, there is a need to scale up the Change Team.
Step 7 – consolidating gains and producing

more wins
The small experiments are where new ideas are gestated and, if successful, where
short-term wins are generated. If adopted, they instigate change across the
organization, which constantly consolidates the gains. Many organizations find that
a series of weekly 1-hour Agile briefings from external experts and those in the
organization that have successfully adopted a change can go a long way to
consolidating gains. It’s a great chance to celebrate those wins and build support for
future transformational efforts!
Step 8 – anchoring new approaches in the

culture
The last step is to anchor new approaches in the culture because culture change
comes last, not first. If you want to change the culture, you have to change habits
and behaviors, and to do that, you have to change the ways of working. The only
people that make those systemic and organizational changes are the leadership.
Once you make those organizational changes, you start to affect the habits and
behaviors, which, in turn, leads to cultural change.
CAUTION
Beware of cultural entropy; if you weed a garden, the weeds disappear, but if you stop weeding, the
weeds will grow back. This is the same as culture change – if we don’t anchor the changes, then it is
very likely that the organization will slip back into its old ways of working.
This is where the Agile Program Management Office (APMO) is key in supporting
the change but, more importantly, embedding change within the organization. One
of the changes in SAFe® 6.0 was the option to redesign the traditional PMO to a
Value Management Office (VMO). VMO primarily focuses on delivering value,
strategic alignment, and benefits realization while conversely, an APMO
concentrates on promoting and supporting the adoption of Agile methodologies and
principles to enhance collaboration, adaptability, and iterative delivery. For this
reason, we have decided the stay with the term APMO because it is more aligned
with the activities for supporting change.
PRO TIP
Don’t ignore your APMO; engage it from the start, educate it in Lean-Agile thinking, and then create a
DevOps mentality to change whereby the Change Team and the APMO work together across a
cross-functional team, running change experiments and then instigating across the organization
rather than throwing the change initiative over the fence to APMO.
Figure 16.1 is a prototypical Kanban board, which can be used as a great starting
point to visualize and manage the flow of change initiatives and directly
corresponds to the steps detailed in the preceding sections:
Figure 16.1 – A Change Kanban ( © Cprime inc)
In SAFe® 6.0, the competency for Continuous Learning Culture (CLC) has been
moved and now anchors the bottom of the framework, along with leadership. Why?
We are positing that it will be the new management paradigm for the future.
Therefore, it makes sense for us to discuss this alongside leadership alignment.
A Continuous Learning Culture (CLC)

A CLC is an organizational culture that prioritizes and encourages ongoing learning
and development for all employees. This type of culture is characterized by the
following:
A focus on lifelong learning: Employees are encouraged to continuously develop their skills and
knowledge throughout their careers, rather than only focusing on training at the beginning of their tenure.
You will notice that this is a similar behavior that we encourage in our leaders as well.
A culture of experimentation and innovation: Employees are encouraged to experiment and take risks,
and to learn from their failures as well as their successes.
Access to learning opportunities: Employees are provided with access to a wide range of learning
opportunities, such as workshops, training programs, mentoring, and online resources. Leaders often say,
“What if I Train all my employees and then they leave because they are better qualified?” I say, “What if
we don’t Train them and they stay?” When employees feel that their learning and development are valued
and supported, they are more likely to be engaged and motivated, which can lead to improved retention
rates.
A CLC is important for an organization for several reasons:

Enhancing skills and knowledge: Continuous learning helps employees to develop new skills and
knowledge, which can increase their productivity and effectiveness. This can also help them to take on
new roles and responsibilities within the organization.
Innovation and creativity: A CLC can help to promote innovation and creativity within the organization.
Employees who are encouraged to learn and experiment are more likely to come up with new ideas and
solutions to problems.
Adapting to change: In today’s fast-paced business environment, organizations need to be able to adapt
quickly to changing circumstances. A CLC can help employees to stay up to date with new technologies
and trends and adapt to changes in the marketplace.
Retaining employees: Employees who feel that they are growing and developing within an organization
are more likely to stay with that organization. A CLC can help to increase employee engagement and
retention.
Improving organizational performance: A CLC can help to improve organizational performance by

increasing employee engagement, productivity, and innovation. This can help organizations to achieve
their goals more effectively and to stay competitive in their industry.
But how do you foster and create a CLC?
Creating a CLC requires a deliberate effort to prioritize learning, provide

opportunities for learning, encourage experimentation, recognize and reward
learning, create a learning community, provide access to resources, and measure
and evaluate the impact of learning initiatives. By doing so, organizations can foster
a culture of learning that supports the development of their employees and the long-
term success of the organization.
In summary, a CLC is an organizational culture that prioritizes and encourages

ongoing learning and development for all employees. It is characterized by a focus
on lifelong learning, a culture of experimentation and innovation, access to learning
opportunities, support for self-directed learning, and recognition and rewards for
learning.
Summary
We make no apology for this being a long chapter because leadership is critical to
any change initiative, especially if you are looking to implement SAFe®.
In this chapter, we looked at the three dimensions of aligning leadership:

Helping them move from a fixed to a growth mindset and adopting a personal lifelong learning culture
where the leadership needs to do as much, if not more, learning than anyone else.
Leading by example, whereby they practice what they have been taught – for example, by getting the
leadership to operate as an Agile team. This allows them to experience what it means to be Agile and
model the right behaviors.
Leading the change by drawing on the seminal work by John Kotter and his book, Leading Change.
Finally, we concluded with the CLC, which we believe could be the new
management paradigm for the 21st century.
Further reading
1. Turn the Ship Around, by David Marquet
2. Leading Change, by John Kotter
3. The economic case for reskilling in the UK: How employers can thrive by boosting workers’ skills:
https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/the-
economic-case-for-reskilling-in-the-uk-how-employers-can-thrive-by-boosting-workers-skills
17
Embracing Agility and Nurturing

Transformation
Congratulations! You have reached the concluding chapter of the SAFe® Coaches
Handbook. Throughout this journey, we have explored the multifaceted role of a
Coach, delving into the principles, practices, and responsibilities that accompany
this vital position. We hope this handbook has provided you with the guidance and
insights necessary to navigate the complexities of leading Agile transformations
and driving organizational change.
As a Coach, you are an agent of transformation, an advocate for agility, and a

catalyst for growth. You possess a unique blend of skills, knowledge, and
experience that empowers you to guide organizations on their path toward
embracing agility at scale. But your journey doesn’t end here. In fact, it’s just the
beginning.
Agile transformations are not overnight endeavors, but rather ongoing and iterative
processes. The Agile landscape constantly evolves, and organizations must adapt to
stay ahead in today’s dynamic business environment. As a Coach, you have a
crucial role in nurturing this adaptive mindset and instilling a culture of Continuous
Improvement.
Remember that Coaching is not about imposing a rigid framework or set of rules.
It’s about understanding the organization’s unique context, aligning with its values,
and co-creating a tailored approach that fits its needs. Flexibility, empathy, and
collaboration will be your guiding principles as you support teams, Leaders, and
Stakeholders in their Agile journey.
As you move forward, keep these key takeaways in mind:

1. Embrace servant leadership: As a Coach, your primary objective is to serve the organization and its
people. Focus on enabling teams, fostering collaboration, and removing impediments to their success.
Your role is to empower others to take ownership, make decisions, and drive outcomes.
2. Continuously improve: Agile is a mindset that values learning and adaptability. Encourage a culture of
experimentation, feedback, and reflection. Facilitate retrospectives, encourage communities of practice,
and promote knowledge sharing. The pursuit of excellence should be an ongoing endeavor.
3. Tailor the approach: SAFe® provides a framework, but it should be customized to fit the organization’s
unique needs. Adapt and tailor practices, ceremonies, and artifacts to maximize their value and alignment
with organizational goals. Remember, it’s not about blindly following a prescribed path but finding what
works best for your context.
4. Foster a learning organization: Encourage a growth mindset and promote a culture of learning. Help
individuals and teams develop new skills, expand their knowledge, and explore emerging practices and
techniques. Learning should be embedded into the fabric of the organization, driving innovation and
adaptability.
5. Be an agent of change: Agile transformations can be challenging and met with resistance. As a Coach,
your role extends beyond Coaching teams; you are also an advocate for change and a trusted advisor to
Leaders. Build strong relationships, communicate effectively, and provide guidance to navigate the
complexities of change management.
6. Celebrate successes: Acknowledge and celebrate the achievements and milestones along the
transformation journey. Recognize the efforts and contributions of individuals, teams, and Leaders. This
not only boosts morale but also reinforces the positive impact of agility on the organization.
Remember, SAFe® Coaches Handbook is not a comprehensive manual but a

companion on your path to becoming an effective Coach. The world of agility is
vast, and there will always be more to learn, explore, and discover. Stay curious,
stay connected to the Agile community, and continue your professional growth.
As the world continues to evolve, agility will remain a competitive advantage for
organizations. By embracing the principles and practices outlined in this handbook
and adapting them to your unique context, you will play a pivotal role in helping
organizations thrive in a rapidly changing landscape.
Good luck.
Lindy and Darren

Appendix A
This appendix expands the 5 Content Tab from the 01 ART Readiness Workbook (V6.0) from the Scaled Agile Framework (SAFe)
Program increment (PI) Planning Toolkit.
In the following table, you will see the key activities outlined as well as tasks/activities that are typically executed to meet the overall
deliverable. Although the list is not comprehensive, you can use it as a template and refine and enhance each PI for specifics within
your organization.
The dates make the following assumptions:
PI event start date 6/6/23
Inspect and Adapt (I&A) date 6/5/23
Number of iterations in PI Five
Innovation and Planning (IP) iteration start date 5/31/23
An additional column is displayed with the formula used to calculate the recommended due dates. The parameters are as follows:
ParmPIStart – The date the PI event starts
ParmIADate – The date of the I&A event
ParmIPStart – Start date for the IP Iteration
You can download a copy of the Excel spreadsheet here: https://github.com/PacktPublishing/SAFe-Coaches-

Handbook/blob/main/Appendix_A.xlsx
No. Item Description Responsibility Recommendation Due Formula Assigned Statu

Date To
5.01.00 Scope, Review items from Part All ASAP/ ongoing

context, and 1
organizational
readiness
established
5.01.01 Agile Teams All team members are Organization Reviewed each PI 4-Apr- Parm
defined assigned to an agile Leadership 23 PIStart-63
team that is
appropriately sized, and
Product Manager
(PM) and Scrum
Masters/Team Coaches
are identified
5.01.02 Key Agile The following roles Organization Reviewed each PI 4-Apr- ParmPIStart-
roles identified have been assigned: leadership 23 63
Release Train
Engineer (RTE),
Product Management,
and System Architect,
and appropriate time is
allocated to
responsibilities
(preferably 100%
dedicated)
Date To
5.01.03 Product Vision Product Vision is Product Reviewed each PI 11-Apr- ParmPIStart-
created, reviewed, and Management 23 56
updated as appropriate
5.01.04 System Team The System Team and Organization Reviewed each PI 4-Apr- ParmPIStart-
and user UX members are Leadership 23 63
experience identified, and
(UX) team availability and needs
have been clarified
5.01.05 Product Product backlog Product Hold workshops Ongoing Ongoing

backlog workshop is held with Management, as needed.
created Product Management, facilitated by RTE Particularly if
Product Owner (PO), Agile Release
Customers, Train (ART)
Management, and backlog is
Scrum Masters/Team insufficient or
Coaches unrefined
5.01.06 Value Stream Activity engaging Facilitated by Workshops as 11-Apr- ParmPIStart-

mapping Product Management, RTE needed, review for 23 56
Organization each PI
Leadership, and System
Architect to create a
long-lived series of
steps that deliver value
from concept to
delivery
5.01.07 ART working Agreement activities Facilitated by Reviewed each PI 11-Apr- ParmPIStart-
agreement AND guidelines that RTE 23 56
will be abided by. High
level and adoptable by
all ART members
5.01.08 ART Agreed upon list of Facilitated by Reviewed each PI 11-Apr- ParmPIStart-
definition of activities that are RTE 23 56
done (DOD) necessary to complete
the PI. High-level DOD
that all teams are
expected to meet
5.02.00 Final agenda Final agenda with start RTE Three weeks
and stop times, before PI
timeboxes, speaker
callouts, and so on.
Take into account time
zone differences if the
planning meeting is
spread across multiple
locations
Date To
5.02.01 Schedule Finalize PI event RTE Three weeks 16-May- ParmPIStart-

schedule, including before PI 23 21
start/stop times
accounting for multiple
time zones if necessary
5.02.02 Identify Identify presenters and RTE Six weeks before 25-Apr- ParmPIStart-
presenters notify them of their PI 23 42
responsibilities and due
dates
5.03.00 Facilitator Facilitators understand Facilitator/ RTE One week before

preparation the context and PI
mechanics of the event
and facilitator
guidelines. For the first
PI Planning meeting, if
the RTE is not a
SAFe® Practice
Consultant (SPC), they
will need to be paired
with an SPC to use the
PI Planning Toolkit
5.03.01 Complete Review and work RTE Ongoing Ongoing Ongoing

Readiness through the Readiness
Workbook workbook.
Continuously improve
it by adding, updating,
and removing items as
necessary
5.03.02 Facility Ensure that facilities RTE ASAP 28-Mar- ParmPIStart-

reservations have been reserved and 23 70
that there is enough
space to accommodate
the teams. See 6.
Facilities tab in the
ART Readiness
Workbook
5.03.03 Supplies Ensure that supplies are RTE Six weeks before 25-Apr- ParmPIStart-
on hand at the PI event PI 23 42
for each team. Order if
necessary. See 7.
Supplies tab in the ART
Readiness Workbook
Date To
5.03.04 Create PI slide Ensure that the PI slide RTE Two weeks after 11-Apr- ParmPIStart-
deck deck is created and in a the PI event 23 56
location where
presenters can update it.
If reusing, delete any
information for the
current PI to give
presenters a blank slate
to add content to
5.03.05 PI slide deck Ensure that slide deck RTE The day before the 4-Jun- ParmPIStart-
finalized materials are complete PI event 23 2
and accurate. Copy to
local device to prevent
network access issues
5.03.06R Remote Ensure that technology RTE ASAP 28-Mar- ParmPIStart-

technology is identified and tested 23 70
identified to support remote PI
Planning, including
breakout rooms,
conference lines, ART
boards, team boards,
and so on
5.03.07R Remote Ensure that ART team RTE One week before 30-May- ParmPIStart-
technology members are familiar PI 23 7
training with the technology and
can navigate and use
technology systems for
PI Planning
5.04.00 Introductory Establishes schedule, Facilitator/ RTE Two weeks before

briefing objectives, context, and PI
requirements for the
session
5.04.01 Intro Briefer Identify who will RTE At least six weeks 25-Apr- ParmPIStart-
identified present the introduction before PI 23 42
to the PI event
5.04.02 Intro Briefer Establishes schedule, Introduction At least six weeks 25-Apr- ParmPIStart-
responsibilities objectives, context, and Briefer before PI 23 42
requirements for the
session
5.04.03 PI slide deck – Update the PI slide Briefer At least one week 30-May- ParmPIStart-
introductory deck before PI 23 7
briefing
5.05.00 Executive Defines the current Executive Two weeks before

briefing business context identified PI
Date To
5.05.01 Executive Identify who will RTE At least eight 11-Apr- ParmPIStart-
Briefer present the executive weeks before PI 23 56
identified briefing at the PI event
5.05.02 Executive Defines current Executive Briefer At least eight 11-Apr- ParmPIStart-
Briefer business context and weeks before PI 23 56
responsibilities investment themes
5.05.03 PI slide deck – Update the PI slide Executive Briefer At least one week 30-May- ParmPIStart-
executive deck before PI 23 7
briefing
5.06.00 Product Vision Briefings prepared by PMs and Business Two weeks before
briefing(s) Product Management. Owners PI
Handouts/backlogs are
prepared with
supporting detail
(Features, priorities,
market reports, use
cases, UX guidelines,
and so on)
5.06.01 PI Vision Optional – some ARTs Product Three weeks 16-May- ParmPIStart-
like to have a vision or Management before PI 23 21
goal for each PI to help
align the ART. Similar
to the Product Vision,
but timeboxed to PI
5.06.02 PI slide deck – Once Epics and Product At least two 23-May- ParmPIStart-
Product Vision Features for PI are Management weeks before PI 23 14
section determined, the PM can
update the PI
presentation slide deck
with the ART Epics and
any other additional
Product Vision
information
5.06.03 PI slide deck - Once the Features are Product At least two 23-May- ParmPIStart-
Product Vision identified, update slides Management and weeks before PI 23 14
section reflecting details for the POs
Features, including the
business hypothesis
5.07.00 ART backlog Top 10 Features. To PMs and POs Six weeks before
prepare, review the PI
Vision, understand
Strategic Themes, and
gain alignment with
product strategies
Date To
5.07.01 PI Features Features for the next PI Product 6–8 weeks before 25-Apr- ParmPIStart-
identified and are identified Management the PI event 23 42
prioritized
5.07.02 ART backlog ART backlog is Product 6–8 weeks before 11-Apr- ParmPIStart-
refinement decomposed/refined Management and the PI event 23 56
with Features, Benefit POs (rolling
Hypothesis, and refinement
Acceptance Criteria preferred)
5.07.03 Feature Work with teams to POs At least 4–6 30-May- ParmPIStart-
decomposition begin to create stories weeks before the 23 7
for each Feature. Note: PI event (rolling
stories do not have to refinement
be “ready” but should preferred)
have enough
information to allow for
rough sizing
5.07.04 Story print Print stories for the Scrum One day before PI 4-Jun- ParmPIStart-
outs Features of the PI Masters/Team 23 2
event. Print on paper or Coaches
sticky notes that
matches the story sticky
note color (ex. green)
5.07.05R Story exports Export/import stories or RTE and Scrum One week before 30-May- ParmPIStart-
ensure linkage to the Masters/Team PI 23 7
Agile tool Coaches
5.08.00 Architectural Communicate any new Chief technology Two weeks before
vision briefing architectural Epics and officer PI
system quality (non- (CTO)/Architects,
functional) Security
requirements Directors, and so
on
5.08.01 PI slide deck – Update the slide deck System Architect Two weeks before 23-May- ParmPIStart-
architectural with information PI 23 14
vision section relevant to the PI for
the teams. Items to
consider are
architectural vision
statement, solution
context, and solution
intent. Additionally,
non-functional
requirements,
compliance items,
architectural roadmap,
and so on
Date To
5.09.00 Development Changes to standard Senior Two weeks before

practices practices, new tools Development PI
briefing (Agile Project Management
management tool, test
automation, continuous
integration),
expectations for DOD,
and so on
5.09.01 PI slide deck – May be combined with System Architect Two weeks before 23-May- ParmPIStart-
development the architectural PI 23 14
practices briefing. Additional
briefing topics to consider are
DevOps, continuous
integration/continuous
delivery (CI/CD),
coding standards,
automated testing,
system outages, and so
on
5.10.00 Meeting notice Finalize agenda and RTE Placeholder

send meeting notice to immediately after
attendees with the previous PI – final
venue, access notice four weeks
requirements, and so on before PI
5.10.01 PI save the Send a note out to PI RTE Immediately after 28-Mar- ParmPIStart-
date participants to save the the PI event 23 70
date for the PI event
5.10.02 PI meeting Send the calendar invite RTE At least four 9-May- ParmPIStart-
invite to all attendees. Include weeks before the 23 28
travel information if Event
needed. Advise
attendees of start and
end times, dress code,
access requirements,
and so on
5.10.03 PI custom Send invites to RTE At least four 9-May- ParmPIStart-

meeting Executives for specific weeks before the 23 28
invites sessions they should Event
attend (excluding
briefings, plan readouts,
etc.)
Date To
5.11.00 Iterations and Based on iterations and RTE Four weeks before
PI events PI cadence, finalize the PI – should be set
schedule calendar. Teams events a year in advance
include Iteration
Planning, iteration
review, and iteration
retrospective.ART
events include PI
Planning, system demo,
I&A, Coach sync, and
PO sync
5.11.01 ART and Complete/update the RTE Update/extend 28-Mar- ParmPIStart-

Team Events ART calendar after each PI 23 70
Calendar spreadsheet. Resolve
Workbook any holiday conflicts.
Recommend to create
and update it for a year
in advance
5.11.02 Team events Send Invites for team Scrum Three weeks 16-May- ParmPIStart-
ceremonies (daily Masters/Team before the PI 23 21
standup, Iteration Coaches event for the next
Planning, iteration PI
review, retrospective,
and backlog
refinement)
5.11.03 ART events Send invites for ART RTE Three weeks 16-May- ParmPIStart-
ceremonies (system before the PI 23 21
demos, PI pre-planning, event for the next
etc.) PI
5.11.04 PO events Send invites for PO PM Three weeks 16-May- ParmPIStart-

Sync before the PI 23 21
event for the next
PI
5.11.05 Architecture Send invites for System Architect Three weeks 16-May- ParmPIStart-
events architecture sync before the PI 23 21
event for the next
PI
5.11.06 Scrum Send invites for Coach RTE Three weeks 16-May- ParmPIStart-
Master/Team Sync before the PI 23 21
Coach events event for the next
PI
5.12.00 PI event Verify, validate, and RTE Before the PI

activities prepare for the event event
Date To
5.12.01 Verify Visit the facility and RTE The day before PI 4-Jun- ParmPIStart-
facilities ensure proper setup for 23 2
tables, and so on, as
well as technology,
mics, and network
connectivity
5.12.02 Verify Ensure that the proper RTE Two weeks before 23-May- ParmPIStart-
technology technology is available PI 23 14
and participants have
access.
5.12.03 Print out PI Print out any signs that RTE and Scrum The day before PI 4-Jun- ParmPIStart-
signs and will be needed for the Masters/Team 23 2
handouts event. See the list on Coaches
Tab 7
5.12.04 Set up team Set up each of the team Scrum Masters The day before PI 5-Jun- ParmPIStart-
space board areas following 23 1
the legend
5.12.05R Set up team Ensure each of the team Scrum Masters Two weeks before 23-May- ParmPIStart-
space – remote boards is configured in PI 23 14
the tooling
5.12.06 Set up ART Create the ART board RTE The day before PI 5-Jun- ParmPIStart-
board following the legend 23 1
5.12.07R Set up ART Ensure the ART board RTE Two weeks before 23-May- ParmPIStart-
board – remote is set up and configured PI 23 14
in the tooling
5.12.08 Arrive early Arrive early to the PI RTE and Scrum The day of the PI 6-Jun- ParmPIStart
event to ensure boards Masters/Team event 23
have not fallen down Coaches
and to connect/validate
the technology
5.12.09R Populate the Populate or ensure the RTE and Scrum The day before PI 5-Jun- ParmPIStart-
Agile PI tool Agile tool has all Masters/Team 23 1
stories, Features, and so Coaches
on available
5.13.00 I&A workshop The current state of the RTE Before the PI
solution is event
demonstrated and teams
reflect on and identify
improvement backlog
items
5.13.01 I&A save the Send a note out to I&A RTE Immediately after 27-Mar- ParmIADate-
date participants to save the the PI event 23 70
date for the I&A event
Date To
5.13.02 I&A meeting Send the calendar invite RTE At least four 8-May- ParmIADate-
invite to all attendees. Include weeks before the 23 28
travel information if event
needed. Advise
attendees of start and
end times, dress code,
access requirements,
etc.
5.13.03 I&A custom Send invites to the RTE At least four 8-May- ParmIADate-
meeting Executives for specific weeks before the 23 28
invites sessions they should event
attend (excluding
system demo)
5.13.04 Create Slide Create Slide Deck RTE 6–8 weeks before 24-Apr- ParmIADate-
Deck Template with the I&A 23 42
placeholders
5.13.05 Prepare teams Meet with PO/PM to RTE, PM, PO, Two weeks before 22-May- ParmIADate-
for system identify Features to and others 23 14
demo demo
5.13.06 Dry run the Complete a dry run of RTE, PM, PO, One week before 29-May- ParmIADate-
system demo the demo to ensure it and others 23 7
fits in the timebox (one
hour) and to work out
any kinks
5.13.07 Complete Complete the ART RTE The beginning of 31-May- ParmIPStart
ART Predictability Measure the IP Iteration 23
Predictability workbook
Measure
5.13.08 Team self Work with Scrum RTE and Scrum End of last 30-May- ParmIPStart
assessment Masters/Team Coaches Masters/Team iteration 23 -1
to conduct team self Coaches
assessments –
Recommended during
last iteration retros
5.13.09 Compile team Ensure the following RTE During the IP 31-May- ParmIPStart
metrics into a metrics are included: Iteration 23
slide deck ART Predictability
Measure, team
performance
assessments, team
performance reports,
and ART performance
metrics
Date To
5.13.10 Finalize slide Ensure that all Slide RTE At least one day 3-Jun- ParmIADate-
deck deck is finalized and before the event 23 2
demo, metric and retro
information is included.
5.13.11 I&A workshop Print out/create boards, RTE One week before 29-May- ParmIADate-
boards signage, and 23 7
instructions for the
problem-solving
workshop
5.13.12 Set up room Ensure the room is set RTE The day before the 4-Jun- ParmIADate-
up and any event 23 1
handouts/boards are
created to facilitate the
meeting
5.13.13R Set up tools – Ensure that tools are RTE One week before 29-May- ParmIADate-
remote setup and configured to 23 7
support the problem-
solving workshop
5.14.00 Training Ensure that all RTE As needed and

participants have had planned for
training/SAFe®
certifications as
applicable
5.14.01 All ART Leading SAFe® Agilist Management As needed

participants (SA) and/or SAFe® for
Teams (SAFe®
Practitioner (SP))
5.14.02 Developers SAFe® Agile Software Management As needed

Engineering (ASE)
5.14.03 Scrum SAFe® Scrum Master Management As needed

Master/Team (SSM) and/or SAFe®
Coach Advanced Scrum
Master (SASM)
5.14.04 RTE SAFe® RTE and Management As needed

Implementing SAFe®
(SAFe® Practice
Consultant (SPC))
5.14.05 Product SAFe® Product Management As needed

Management Owner/Product
Manager (POPM)
5.14.06 POs SAFe® POPM Management As needed

Date To
5.14.07 Developers, SAFe® DevOps (SDP) Management As needed

System Team
5.14.08 System SAFe® for Architects Management As needed

Architect (ARCH)
5.14.09 Program Leading SAFE (SA) Management As needed

Management, and Lean Portfolio
Organization Management (LPM)
Leadership
Appendix B
This appendix contains several examples of Multi-Day PI Planning schedules. You
may need to adjust as necessary to accommodate time zones, Zoom fatigue, and so
on.
Standard 2-day agenda

Here’s the standard 2-day agenda:
Day 1 Agenda
8:00 – 9:00 am Business context
9:00 – 10:30 am Product/Solution Vision
10:30 – 11:30 am Architecture Vision and development practices
11:30 – 1:00 pm Planning context and lunch
1:00 – 4:00 pm Team breakouts
4:00 – 5:00 pm Draft plan review
5:00 – 6:00 pm Management review and problem-solving
Day 2 Agenda
8:00 – 9:00 am Planning adjustments
9:00 – 11:00 am Team breakouts
11:00 – 1:00 pm Final plan review and lunch
1:00 – 2:00 pm ART PI Risks

2:00 – 2:15 pm PI confidence vote
2:15 – ? pm Plan rework if necessary
After commitment Planning retrospective and Moving Forward
Distributed 3-day agenda

This agenda can be found in the SAFe® PI Planning Toolkit. It is commonly used
when teams are split around the world with dramatically different time zones.
Day 1
Time Zone 1 Time Zone 2 Subject
08:00 – 8:30 am 08:30 – 09:00 pm Opening
08:30 – 09:00 am 09:00 – 09:30 pm Business context
09:00 – 10:30 am 09:30 – 11:00 pm Product/Solution Vision
10:30 – 10:45 am 11:00 – 11:15 pm Break
10:45 – 11:15 am 11:15 – 11:45 pm Architecture Vision
11:15 – 11:45 am 11:45 – 12:15 am Development practices
11:45 – 12:15 pm 12:15 – 12:45 am Planning requirements
12:15 – 01:00 pm Meal break
01:00– 04:00 pm Team breakouts (1 of 2)
Hourly Coach Sync checkpoint
Day 2
05:30 – 08:30 pm Team breakouts (1 of 2)
08:00 – 09:00 am 08:30 – 09:30 pm Team synchronization
09:00 – 10:00 am 09:30 – 10:30 pm Draft plan review
10:00 – 10:15 am 10:30 – 10:45 pm Break
10:15 – 11:15 am 10:45 – 11:45 pm Management review and problem-solving
11:15 – 11:45 am 11:45 – 12:15 am Planning adjustments
11:45 – 12:30 pm 12:15 am – finish Meal
12:30 – 03:00 pm Team breakouts (2 of 2)
Day 3
06:00 – 08:30 Team breakouts (2 of 2)

pm
08:00 – 09:00 am 08:30 – 09:30 Team synchronization and finalized

pm objectives
09:00 – 11:00 am 09:30 – 11:30 Final plan review

am
11:00 – 11:15 am 11:30 – 11:45 Break

pm
11:15 – 12:15 pm 11:45 – 12:45 ART PI Risks
am
12:15 – 01:00 pm 12:45 – 01:30 Meal Break

am
01:00 – 01:15 pm 01:30 – 01:45 PI confidence vote

am
01:15 – ? pm 01:45 – ? am Plan rework if necessary
When commitment is Planning retrospective

achieved
Final Instructions
4 half-day agenda
The 4 half-day agenda is designed to help combat Zoom fatigue. Adjust start times
to accommodate ART. This schedule can also be used for distributed time zones.
Optionally, you may want to extend the second team breakout to day 3.
Day 1 Subject
08:00 – 8:30 am Opening
08:30 – 09:00 am Business context
09:00 – 10:30 am Product/Solution Vision
10:30 – 10:45 am Break
10:45 – 11:15 am Architecture Vision
11:15 – 11:45 am Development practices
11:45 – 12:15 pm Planning requirements

Day 1 Subject
Day 2 Subject
08:00– 11:00 am Team breakouts
(1 of 2)
11:00 – 12:00 pm Draft plan review
12:00 – 12:15 pm Break
12:15 – 1:15 pm Management review and problem-solving
Day 3 Subject
8:00 – 8:45 am Planning adjustments
8:45 – 11:00 am Team breakouts
(2 of 2)
Day 4 Subject
8:00 – 9:00 am Final plan review
9:00 – 9:15 am Break
9:15 – 10:15 am ART PI Risks
10:15 – 10:30 am PI confidence vote
10:30 – ? am Plan rework if necessary

Day 1 Subject
After commitment Planning retrospective/Final instructions
Here are some additional items to note:

You have the flexibility to adjust the schedule as needed to accommodate PI Planning. We strongly
encourage you to keep the schedule as close as possible and the associated timeboxes for each activity.
We have seen success with combined Architecture and Product Vision presentations showing how they
correspond and correlate with each other.
Remind and encourage teams to take regular breaks during the breakout sessions.
Glossary
SAFe® provides a very comprehensive glossary that can be found here:
https://www.scaledagileframework.com/glossary/.
However, there are a number of SAFe® terms we want to call out here:
1. Scrum Master/Team Coach (SM/TC)– The individual on each Agile team who is responsible for helping
the team implement and maintain Agile practices, optimize and improve the team’s performance, and
partner with the RTE to guide the performance improvements of the ART as a whole.
2. Product Owner (PO) – A member of the Agile team who is responsible for ensuring that the products and
services delivered by the team have maxim Business Value and that the Team Backlog reflects the most
current needs of customers and Stakeholders.
3. Release Train Engineer (RTE) – The Coach for the ART.
4. Product Management (PM) – These individuals are typically the first level that interfaces with the
customer. They own, define, and prioritize the ART backlog.
5. System Architect – The individual(s) responsible for defining and communicating the technical and
architecture needed by the ART.
6. System Team - This is a specialized Agile team that assists in building and supporting the Agile
development environment, including developing and maintaining the Continuous Delivery Pipeline. They
may also support the integration of assets, end-to-end solution testing, DevOps mindset and practices,
deployment, and release on demand.
7. Shared Services - These represents the specialty roles, people, and services required for the success of an
ART or Solution Train, but that are not dedicated full-time.
8. Agile Release Train (ART) – A long-lived and cross-functional team of Agile Teams, which, along with
other Stakeholders, develops and delivers Solutions incrementally using a series of fixed-length iterations
within a PI timebox.
9. PI Planning – Here, Program Increment is referred to as PI. PI Planning is an all-hands-on-deck, 2-day

event, designed to align all the teams to a shared Mission and Vision and to collectively identify potential
impediments to Feature delivery.
10. Lean Portfolio Management (LPM) – A competency that aligns strategy and execution by applying Lean
and Systems thinking approaches to strategy and investment funding, Agile portfolio operations, and
governance.
11. Non Functional Requirements (NFRs) – These are system qualities that guide the design of the solution
and often serve as constraints across the relevant Backlogs.
12. Definition of Done (DoD) - This is a shared understanding within an Agile Team that outlines the criteria
that must be met for a product increment, User Story, or task to be considered complete and ready for
release or deployment. It serves as a quality standard and ensures that the team delivers valuable and high-
quality work consistently.
13. Definition of Ready (DoR) - This is an agreement within an Agile Team that outlines the criteria a User
Story or task must meet before it can be taken into an Iteration and worked on. It ensures that the team has
a shared understanding and sufficient information to start the implementation of a User Story effectively.
In addition, there are a few Japanese terms that we also need to explain:
1. Kaizen means “improvement” or “change for the better.” It is based on the idea that small, incremental
improvements, made consistently over time, can lead to significant results. The philosophy of Kaizen
emphasizes the importance of involvement by all employees in the improvement process, from the shop
floor to the executive suite, and it encourages a culture of continuous learning and development. These
approaches use a combination of tools and techniques, such as Value Stream Mapping and Kaizen
Workshops, to identify and eliminate waste, improve quality, increase efficiency, and enhance overall
customer satisfaction. The goal of Kaizen is to create a sustainable, long-term culture of Continuous
Improvement that results in higher quality, lower costs, and increased customer satisfaction. By
implementing Kaizen, organizations can continuously improve their processes, products, and services, and
ultimately achieve their strategic objectives.
2. Gemba is a Japanese term that refers to the actual place where value is created or where work is
performed. In business and manufacturing, the term is often used to refer to the factory floor, where
products are made and assembled. The term is also used more broadly to refer to any location where work
is done and value is created, including offices, service centers, and retail stores. In the context of
Continuous Improvement, Gemba is considered to be the first place to look when trying to identify areas
for improvement. This is because being on the Gemba allows you to observe the actual work processes and
see any bottlenecks, inefficiencies, or areas for improvement first-hand. By going to the Gemba and
observing the work as it is performed, you can gain a deeper understanding of the process and identify
opportunities for improvement that might not be immediately apparent from looking at data or reports.
3. Muda is a Japanese term that means “waste” or any activity or process that does not add value to a product
or service. The concept of muda is often used in the context of lean manufacturing or the Toyota
Production System, where eliminating waste is a key principle to increase efficiency and reduce costs.
There are several types of muda, including overproduction, waiting, unnecessary transportation, excess
inventory, unnecessary motion, defects, and unused employee creativity. By identifying and eliminating
muda, organizations can improve their processes, increase productivity, and ultimately provide better value
to their customers.
4. Shu Ha Ri is a martial arts concept and strategy philosophy. It is often used to describe the stages of
learning and mastery in a particular art, craft, or skill. The three stages of Shu Ha Ri are as follows:
1. Shu: This is the stage of learning, where the practitioner follows the rules and techniques of
the art without deviation. The focus is on memorizing and imitating what has been taught.
2. Ha: During this stage, the practitioner begins to understand the underlying principles of the art
and begins to experiment and make modifications to the techniques that have been learned.
The focus is on breaking free from strict adherence to the rules.
3. Ri: The final stage is that of mastery, where the practitioner has internalized the principles of
the art and is able to improvise and create new techniques based on their own understanding.
The focus is on expressing the essence of the art in a unique and personal way.
Here is the full, new SAFe® 6.0 Big Picture:

Figure G.1 - SAFe® Big Picture
Index
As this ebook edition doesn’t have fixed pagination, the page numbers below are
hyperlinked for reference only, based on the printed edition of this book.
A
Acceptance Criteria (AC) 50, 124
writing, elements 50
Accepted state 145
Actual Business Value (ABV) 180
Adjourning 8
Agile Manifesto 15
Agile organization
guiding coalition, creating 262
leading 261
SAFe’s imperfect guiding coalition 262
Agile organizational change
approaches, anchoring 267, 268
gains, consolidating 267
short-term wins, generating 266
wins, producing 267
Agile organizational change, vision and strategy
Epic Hypothesis Statements, incorporating 266
ideas, collecting 266
ideas, evaluating 266
idea to EAT, pitching 266
Agile organization, guiding coalition
Change Team 264
EAs 265
EAT 263
leading change, implementing 265

NEDs 265
Objectives and Key Results (OKRs) 265
vision and strategy, developing 265
Agile Product Delivery (APD) 11, 117
Agile Program Management Office (APMO) 267
Agile Release Trains (ARTs) 11, 30, 75, 195, 199, 223
communicative 76
cross-functional 76
dedicated 76
defining 75, 76
maturity 77
Product Management 85
RTE 82, 83
System Architect 87-89
Troika 80
Agile Team iteration
day-to-day, within iteration 33
Agile Teams 19-21
Product Owner 22, 23
responsibilities 26-28
roles and responsibilities 21
Shared Services 30
SM/TC 24
System Team 30
types 29
Architectural Runway 81, 124
Architectural Vision 155
Architecture Sync 81
ART Backlog 53, 121-123
in Kanban, example 122

ART Board 143, 144
integrated ART PI Objectives 146
recreating, in ARTs space 146
tools 145
using, at sync meetings 147
using, during iterations 146
ART ceremonies and events, product management 102
ART backlog refinement 103
ART Sync 102
Inspect and Adapt (I&A) 102
Iteration System Demo 102
PI Planning 102
PO sync 102
preparing, for PI Planning 103
ART ceremonies, System Architect 104
ART sync 105
Inspect and Adapt (I&A) 105
Iteration System Demos 105
PI Planning 105
ART events
versus teams events 94
Artificial Intelligence (AI) 5
ART Planning Board 166-168
ART Predictability 249, 250
ART Sync 107, 108, 135-138
ART Velocity 250, 251
authenticity 257
automated testing tools 100
average cycle time 182
B
Backlog Refinement 65
Benefit Hypothesis 124, 180
Big Data 5
blockers 81
Budget 215, 222
buffer 114
Built-in Quality 88
tools 100
Business Context 155
executive, identifying 156
Business Epics 227
Business Model Canvas 203
Business Outcomes 232
Business Owners 153
Business Value
commercial value 164
efficiency value 164
future value 164
market value 164
regulatory value 164
C
Cadence 93-95
benefits 94
Capacity Allocation 53, 123, 125
cash cows 217
Change Team 264
responsibilities 264
Cloud 5
Coach 93
Coach Sync 108, 136

Coach Sync checkpoint 171
code deployment
tools 248
code quality 245
tools 245
commercial value 164
Communities of Practice (CoP) 264
competitive environment 193
competitive positioning 206
competitive strategies 191
complicated subsystem ARTs 212
Confirmation 50
Continual Professional Developm ent (CPD) 259
continuing education 114
Continuous Delivery Pipeline (CDP) 30, 93, 95, 96, 148
Continuous Exploration (CE) 96
integrating 98, 99
need for 98
principles 96
Release on Demand (RoD) 97
teams, roles 97
Continuous Deployment (CD) 97, 248
Continuous Exploration (CE) 96
Continuous Integration (CI) 97
Continuous Integration/Continuous Delivery (CI/CD) pipeline 76
Continuous Integration/Continuous Deployment (CI/CD) pipeline 95
Continuous Learning Culture (CLC) 13, 117, 180, 268, 269
importance 269
Conversation 50
Conway’s Law 77
Core Competencies of Business Agility 9
Agile Product Delivery (APD) 11
Continuous Learning Culture (CLC) 13
Enterprise Solution Delivery (ESD) 11
Lean-Agile Leadership (LAL) 13
Lean Portfolio Management (LPM) 12
Organizational Agility (OA) 12
Team and Technical Agility (TTA) 10, 11
Core Competency 117
core values 193
Cost of Delay (COD) 129
Cost Structure 204
courages leaders 258
Create, Read, Update, Delete (CRUD) 56
cross-functional 76
cross-functional team 19
cumulative flow diagram 182
D
Daily Stand-up (DSU) 35
day-to-day events, within iteration
Agile Team 38
Product Owner (PO) 34
Scrum Master/Team Coach (SM/TC) 36
day-to-day events, within PI 40
Agile Team 44
Product Owner 41
Scrum Master/Team Coach 42
decentralized decision-making 235, 260
benefits 260
decision-making 206
Definition of Done (DoD) 27, 48, 70, 114
Definition of Ready (DoR) 35, 71, 114
Deforming and Mourning 20
dependencies 236
deployment automation tools 100
development (Dev) 11
Development Practices 155
Development Value Streams 76, 78, 195, 207
identifying, steps 207
DevOps 97
digital age
business casualties 6, 7
dimension 117
distinctive competence 193
Distributed PI Planning 178-180
dot-vote 185
Draft Plan Reviews 171, 172
Dual Operating System 78
for Business Agility 7-9
Dynamic System Development Method (DSDM) 15
E
effective strategy 192
efficiency value 164
elevator pitch 232
emotional intelligence (EI) 257
benefits 258
Enabler Epics 227
Enablers 81, 121, 124
types 124
Enablers Stories 47, 52, 53

Refactoring Stories 52
Spike Stories 52
Technical Debt Stories 52
enterprise business drivers 193
Enterprise Solution Delivery (ESD) 11, 117
Enterprise Strategy 191, 192
portfolio, connecting with Strategic Themes 202-205
Epic Description 232
Epic Hypothesis Statement (EHS) 231, 232, 266
Epic Owner 123, 228
Epics 81, 223, 228
high-level features 233
reference link 234
escaped defects 243
tracking, tools 244
Essential SAFe® 122, 195
estimate 126
Executive Action Team (EAT) 263, 264
External Advisors (EAs) 263
F
feature flag 98
feature lead time 246
Features 121, 123, 222
Capacity Allocation 125
combining 127, 128
Enabler 124
split stories, applying 127
splitting 127, 128

feature sizing 125, 126
points 126
tips and tricks 126
feature toggle 98
financial goals 193
fireside chats 152
fishbone 184, 185
Five Why’s 185
Food and Drug Administration (FDA) 16
Funnel 229
future value 164
G
Gemba 194
guardrails 223
H
hackathon 114
horizons 216
viewing 215-217
I
impediments 81, 108
Improvement Stories 47, 52
innovation 113
Innovation and Planning (IP) Iteration 93, 113, 259
activities 113, 114
challenges 119
events 114
measure and grow 116, 117
product management, responsibilities 117
product owners, responsibilities 118
RTE, responsibilities 117

schedule 114, 115
Scrum masters/team coaches, responsibilities 118
System Architect, responsibilities 118
team members, responsibilities 118
insatiable learning 256
Inspect & Adapt (I&A) Event 151, 180, 239
PI System Demo 180
problem-solving workshop 183
Quantitative Measurement 181, 183
retrospective 183
integrated ART PI Objectives 146
Intellectual Property Office (IPO) 5
investment horizon 215
investments 223
Ishikawa Diagram 185
Iteration Backlog 48, 53
Iteration Board 166
iteration events, Agile Team 38
Iteration Planning 39
Iteration Retrospective 40
Iteration Review 40
responsibilities 39
Team Sync 39
iteration events, Product Owner (PO) 34
Iteration Review 35
key responsibilities 34
Team Sync 35
iteration events, Scrum Master/Team Coach (SM/TC) 36
Iteration Review 38
responsibilities 37
Team Sync 37
Iteration Headline 166
Iteration Review 65
Iteration System Demos 66, 109, 147
considerations 148
executing 147, 148
J
Jenkins 100
job size 128
K
Kanban 21, 66, 121, 229
Keep It Super Simple (KISS) 128
Key Activities 204
Key Performance Indicator (KPI) 236
Key Resources 204
Kudos Board 168
L
Lagging Indicators 232
Large Solution 195
leaders
growth mindset 254-256
leadership style, example 256

authenticity 257
courages leaders 258
emotional intelligence (EI) 257
growing others 259
insatiable learning 256
leading by example 201
decentralized decision-making 260
Leading Indicators 232
versus Lagging Indicators 240, 241
Leading Indicators versus Lagging Indicators
predictability 249
productivity 246
quality 243
team health 241
Leading Indicators versus Lagging Indicators, predictability
ART Predictability 249, 250
ART Velocity 250, 251
features planned versus features accepted, tracking 251
Leading Indicators versus Lagging Indicators, productivity
activity ratio 247
feature lead time 246
number of deployments 248
story cycle time 246
Leading Indicators versus Lagging Indicators, quality
escaped defects 244
Mean Time to Recovery 244
static code analysis 245
test automation percentage 244
Leading Indicators versus Lagging Indicators, team health
employee NPS 242

staff sickness 242
staff turnover 241
leading the change 201
Lean 14, 15
Lean-Agile 201
Lean-Agile Center of Excellence (LACE) 262
Lean-Agile coaches 82
Lean-Agile leaders
education 201, 202
Lean-Agile Leadership (LAL) 13, 117
Lean Business Case 234
Lean Portfolio Management (LPM) 12, 199, 223
governance 236
Lean Portfolio Management (LPM) events 236
PB 237
Portfolio Sync 236
Strategic Portfolio Review 237
lean start-up cycle 235
Lean Thinking 14
LPM course 201
LPM implementation 202
M
management review and problem-solving 172, 173
participants 173, 174
market sensing 194
market value 164
Mean Time To Recovery (MTTR) 243, 244
Measure and Grow Assessments 114, 116
metrics tools 100
Minimum Marketable Features (MMFs) 96

Minimum Viable Products (MVPs) 96, 228, 229, 233
mission 193
Mitigated risks 146
Mitigated state 145
Model-Based System Engineering (MBSE) 160
Mortgages 195
MoSCoW 57
Mourning 8
N
National Institute of Standards and Technology (NIST) 243
Net Promoter Score (NPS) 241
Non-Executive Directors (NEDs) 263
Non-Functional Requirements (NFRs) 48, 81
O
Objectives and Key Results (OKRs) 203, 265
Operational Value Streams (OVS) 78, 207, 208, 211
operations (Ops) 11
Organizational Agility (OA) 12, 117
Overdrafts 195
Owned risks 146
Owned state 145
P
Pareto Analysis 185
parking lot 168
Participatory Budgeting (PB) 222, 223, 234 237
tips 224
people management 206
persevere 229
Personal Loans 195
PI event risks, states

Accepted state 145
Mitigated state 145
Owned state 145
Resolved state 145
PI Events, Agile Team 44
Innovation and Planning (IP) Iteration 45
Iteration System demos 44
PI System demo 45
PI Events, Product Owner
Innovation and Planning (IP) Iteration 42
PI Planning Event 41
PI System demo 42
PO/ART Sync 42
PI Events, Scrum Master/Team Coach
Coach Sync/ART Sync 43
Innovation and Planning iteration 44
Inspect & Adapt (I&A) 44
PI execution
day-to-day events 40
PI feature throughput 182
PI Objectives 146, 165
PI Objective, tips and tricks 163, 164
Acceptance Criteria (AC), planning 170
ART Planning Board 166-168
Business Value, assigning 164
Planning Procedures 168, 170
planning requirements 165, 166

PI Planning 83
backlog preparation 132
Team Backlog, preparing for 59, 60
attendees, preparing 153
day 1, preparing 154
day before I&A workshop, preparing 153
distributed PI Planning 178-180
Draft Plan Reviews 171, 172
execution 154
I&A event 180
management review and problem-solving 172, 173
PI Objective, tips and tricks 163
remote PI Planning 178-180
schedule 154
PI Planning Event, day 2 preparation
adjustments, planning 174
ART PI risks 176
Close Out 178
commitment 175
Confidence Vote 176, 177
Final Plan Reviews 175
retrospective 177
team breakouts 174, 175
PI Planning Event, presentations 155
Architectural Vision and Development Practices 159-161
Business Context 155, 156
planning requirements 161, 162
Product/Solution Vision 156, 157
Welcome 155
PI Planning Event, team breakouts 171
Coach Sync checkpoints 171
PI System Demo 180
Planning Context 155
Planning Context and Lunch 161
Planning Intervals (PIs) 102, 113, 121
platform ARTs 212
Portfolio Backlog 121
Portfolio Canvas
Cost Structure and Revenue Streams 204
Key resources and Key Activities 204
Value Propositions 204
Portfolio Enablers 122
Portfolio Epics 122, 227, 228
Business Epics 227
Enabler Epics 227
Portfolio Kanban 229
analyzing 232
cost estimation, from EHS 234
Done 235
Funnel 230
high-level features of Epic 233
Implementing 234, 235
Lead Business Case 234
Minimum Viable Product (MVP) 233
Portfolio Backlog 234
reviewing 231, 232
solution alternatives 233, 234
portfolios 195, 196
Portfolio Sync 236

Portfolio Vision 203
Predictability Measure 181
Problem-Solving Board 184
problem-solving workshop, I&A Event 183
agreeing, on problems to solve 184
closing out 186
improvement Backlog Items, creating 186
logistic considerations 187
problem, restating 186
root cause analysis, performing 185
root cause, identifying 185
solutions, brainstorming 186
process time 247
Product Management 80, 85
key collaborations 86
qualities 85
responsibilities 86, 103, 104
Product Owner (PO) 21
responsibilities 23
role 22
Product Owners (POs) Sync 108, 137
Product/Solution Vision 157
Feature Review 158
purpose 156
Roadmap 157, 158
Product Vision 85, 146, 155
Product/Solution Vision 155
Q
Quantitative Measurement 180
R
Refactoring Stories 52
regulatory value 164
relative sizing 126
usage 54
Release Management 81
Release Management Sync 141
Release on Demand (RoD) 97, 248
Release Train Engineer (RTE) 17, 80-83, 93, 107, 136, 151
ART events, setting up 112
ART metrics, reviewing in Agile tools 110
behaviors, shifting 83
calendars, working with 111
iteration ceremonies, facilitating 107
obtaining, help 111
PI calendar, setting up 111
preparing, for I&A 111
preparing, for PI planning 111
reference link 83
responsibilities 84, 107
team events, scheduling 113
Release Train Engineer (RTE), iteration ceremonies
ART sync 107, 108
Coach Sync 108
Iteration System Demo 109
PO sync 108
Technical Sync 109
Troika Sync 109
Remote PI Planning 178-180
Resolved, Owned, Accepted, and Mitigated (ROAM) 145
Resolved state 145

Resources 255
retrospective
elements 69
Retrospective and Problem-Solving Workshop 180
Retrospective Board 168
Revenue Streams 204
risk 108
Risk Board 145
risk management 206
risk reduction and/or opportunity enablement (RROE) 128
Roadmap 157, 194
ROAM Board 145, 146
root cause 185
S
SAFe® Core Values 16
alignment 16
relentless improvement 16
respect for people 16
transparency 16
SAFe® Kanban Team Events 66, 67
planning 68
retrospectives 68, 69
Team Sync 68
SAFe® Lean-Agile Principles 17
SAFe® PI Planning Toolkit 168
SAFe® Practice Consultants (SPCs) 192
SAFe® Scrum Team Events 62
Iteration Review 65
Iteration System Demos 66
Team Sync 64
SAFe® Scrum Team Events, Iteration Planning
backlog preparation 62
capacity 62
commitment 64
Iteration Goals 63
story analysis 63
story estimation 63
story selection 63
tasks 63
SAFe coach
objectives 271, 272
SAFe guiding coalition 263
Scaled Agile Framework (SAFe®) 40, 67, 192, 195, 239
advantage 196
guiding coalition, lack of power 263
imperfect guiding coalition 262
Scrum 21
Scrum Master/Team Coach (SM/TC) 21, 24, 62, 82
role 24
self-managed 20
self-organized 20
Servant Leader 82
Set-Based Design (SBD) 233, 234
Shared Services 30
Shared Services Teams 76
SMART Team PI Objectives 162

solution 8
solution alternatives 233, 234
Solution Train 195
Spike Stories 52
Stakeholders 194
stories, types
Enablers Stories 52
need for 53
User Stories 52
story cycle time 246
Story Splitting 55, 56
Story Splitting, considerations
break-out spike 56
business rules variations 56
data entry methods 56
data variations 56
deferred system quality 56
major effort 56
operations 56
simplicity or complexity 56
use case scenarios 56
workflow steps 56
strategic development 206
Strategic Portfolio Review 203, 237
Strategic Themes 202-205
used, for connecting portfolio to Enterprise Strategy 202-205
strategy 191, 192
strategy agility 193, 194
stream-aligned ART 212
Strengths Weaknesses Opportunities Threats (SWOT) 156, 205

Subject Matter Experts (SMEs) 108
SWOT analysis
versus TOWS analysis 205
synchronization 93-95
benefits 94
syncs
recommendations 142, 143
scheduling 141
System Architect 80, 87, 88
System Demos 81
System Team 30, 76, 90, 91
need for 89
responsibilities 90
T
task switching 28
Team and Technical Agility (TTA) 10, 117
Agile Team 10
Built-in Quality 11
Team of Agile Teams 11
Team Backlog 47, 48, 121
capturing, in Kanban system 58
preparation, for PI Planning 59, 60
Team Board 168
team dynamics
stages 20
team events
versus ART events 94
Team Sync 64, 68
Technical Debt 53, 125

Technical Debt Stories 52
Technical Sync 109, 139-141
Technological Revolutions 3-5
Technological Revolutions, phases
Deployment Period 4
Installation Period 4
Turning Point 4
Terrific Transport Corporation (TTC) 202
Tesla
example 232
test automation 243
test-driven development (TDD) 99
time criticality 128
tools, metrics
code coverage 100
deployment metrics 101
lead time metrics 101
process time metrics 101
system up/down times metrics 101
test execution metrics 101
utilization rates metrics 101
Topologies 212
TOWS analysis
versus SWOT analysis 205
Troika 75, 80
Product Management 81
RTE 81, 82
System Architect 81
Troika Sync 109
T-Shaped 20, 114

tweet 166
U
Uncommitted PI Objectives 162
User Business Value 128
User Stories 47-53
estimating 54, 55
prioritization 57, 58
User Stories estimation
techniques and approaches 54
V
value 164
Value Propositions 204
Value Stream 75, 206
Development Value Streams (DVS) 207
funding 217
Operational Value Streams 207
real world example 217-222
Value Stream Identification (VSI) 80, 206, 207, 212, 213
DVS, identifying 210
DVS, realizing into ARTs 211-213
impacting, ART 78
OVS, identifying 208
people, identifying 209
performing 78-80
pre-work and preparation 207
solutions, identifying 208, 209
Value Stream Mapping 80, 213
vanity metrics 239
vertical slice 56
Vision 81, 155, 192-194

W
Weighted Shortest Job First (WSJF) 228, 234
applying, steps 128-131
disagreement 131
feature prioritization 128
need for 128
Working Agreements 71, 114
Work-In-Progress (WIP) 58, 122
Work in Progress (WIP) limits 229
work item 59
workload management tools 100

www.packtpub.com
Subscribe to our online digital library for full access to over 7,000 books and
videos, as well as industry leading tools to help you plan your personal
development and advance your career. For more information, please visit our
website.
Why subscribe?
Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry
professionals
Improve your learning with Skill Plans built especially for you
Get a free eBook or video every month
Fully searchable for easy access to vital information
Copy and paste, print, and bookmark content
Did you know that Packt offers eBook versions of every book published, with PDF
and ePub files available? You can upgrade to the eBook version at packtpub.com
and as a print book customer, you are entitled to a discount on the eBook copy. Get
in touch with us at [email protected] for more details.
At www.packtpub.com, you can also read a collection of free technical articles, sign
up for a range of free newsletters, and receive exclusive discounts and offers on
Packt books and eBooks.
Other Books You May Enjoy

If you enjoyed this book, you may be interested in these other books by Packt:
Scaling Scrum Across Modern Enterprises
Cecil ‘Gary’ Rupp
ISBN: 978-1-83921-647-3
Understand the limitations of traditional Scrum practices
Explore the roles and responsibilities in a scaled Scrum and Lean-Agile development environment
Tailor your Scrum approach to support portfolio and large product development needs
Apply systems thinking to evaluate the impacts of changes in the interdependent parts of a larger
development and delivery system
Scale Scrum practices at both the program and portfolio levels of management
Understand how DevOps, test automation, and CI/CD capabilities help in scaling Scrum practices
Driving DevOps with Value Stream Management
Cecil ‘Gary’ Rupp
ISBN: 978-1-80107-806-1
Integrate Agile, systems thinking, and lean development to deliver customer-centric value
Find out how to choose the most appropriate value stream for your initial and follow-on VSM projects
Establish better flows with integrated, automated, and orchestrated DevOps and CI/CD pipelines
Apply a proven eight-step VSM methodology to drive lean IT value stream improvements
Discover the key strengths of modern VSM tools and their customer use case scenarios
Understand how VSM drives DevOps pipeline improvements and value delivery transformations across
enterprises
Packt is searching for authors like you
If you’re interested in becoming an author for Packt, please visit
authors.packtpub.com and apply today. We have worked with thousands of
developers and tech professionals, just like you, to help them share their insight
with the global tech community. You can make a general application, apply for a
specific hot topic that we are recruiting an author for, or submit your own idea.
Share your thoughts

Now you’ve finished SAFe® Coaches Handbook, we’d love to hear your thoughts!
If you purchased the book from Amazon, please click here to go straight to the
Amazon review page for this book and share your feedback or leave a review on the
site that you purchased it from.
Your review is important to us and the tech community and will help us make sure
we’re delivering excellent quality content.
Download a free PDF copy of this book

Thanks for purchasing this book!
Do you like to read on the go but are unable to carry your print books everywhere?
Is your eBook purchase not compatible with the device of your choice?
Don’t worry, now with every Packt book you get a DRM-free PDF version of that
book at no cost.
Read anywhere, any place, on any device. Search, copy, and paste code from your
favorite technical books directly into your application.
The perks don’t stop there, you can get exclusive access to discounts, newsletters,
and great free content in your inbox daily
Follow these simple steps to get the benefits:

1. Scan the QR code or visit the link below
https://packt.link/free-ebook/9781839210457
2. Submit your proof of purchase
3. That’s it! We’ll send your free PDF and other benefits to your email directly

SAFe Coaches Handbook - Packt

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAFe Coaches Handbook - Packt

Uploaded by

Copyright:

Available Formats

SAFe® Coaches Handbook

Copyright © 2023 Packt Publishing

Group Product Manager: Alok Dhuri

Publishing Product Manager: Uzma Sheerin

Senior Editor: Nisha Cleetus

Content Development Editor: Rosal Colaco

Technical Editor: Jubit Pincy

Copy Editor: Safis Editing

Project Coordinator: Manisha Singh

Proofreader: Safis Editing

Indexer: Sejal Dsilva

Production Designer: Nilesh Mohite

Business Development Executive: Puneet Kaur

Developer Relations Marketing Executives: Deepak Kumar and Mayank Singh

First published: June 2019

Published by Packt Publishing Ltd.

About the authors

About the reviewers

Glenn Smith is a respected business agility consultant and Scaled Agile

Tim Jackson is an experienced SAFe® Practice Consultant Trainer (SPCT) with

Thriving in the Digital Age

Building the Team

Agile Team Iteration and PI Execution

Team Iteration Events

Building the Agile Release Train

Release Trains Day-to-Day

ART Backlog Management

Events for the Train

Building Your Portfolio

Establishing Lean Budgets

Portfolio Backlog Management

Embracing Agility and Nurturing

Other Books You May Enjoy

Organization: “We want to go Agile.”

Organization: “And we want to adopt SAFe®.”

We see a lot of ill-informed commentary on various social media platforms about

So, let’s start here.

SAFe® is not a prescription or a rule book, it is a Framework!

A standard definition of a Framework is as follows: “A framework is a supporting

Every time we have implemented SAFe® in an organization, we have implemented

Moreover, it is underpinned by some genuine thought leadership from Deming,

Are there any prerequisites?

Part 2 focuses on coordination at the ART level

Part 3 concentrates on the Portfolio level

Here is a summary of the chapters:

Part 1, Agile Teams

Part 2, Agile Release Trains

Chapter 14, Portfolio Backlog Management, in a similar fashion to the ART

Remember Agile principle number 10: “Simplicity—the art of maximizing the

Download the example code files

Download the color images

TIPS OR IMPORTANT NOTES

Share your thoughts

Download a free PDF copy of this book

Follow these simple steps to get the benefits:

3. Submit your proof of purchase

Thriving in the Digital Age

In this chapter, we will consider the following key topics:

Some of the casualties of the Digital Age

The dual operating system for Business Agility

The seven Core Competencies of Business Agility

The five Technological Revolutions

Each revolution has a regular sequence of three distinct phases:

The company Snowflake, which provides data warehouse-as-a-service, was the