SAFe: TEAM & PROGRAM LEVEL
Lean UX
Lean User Experience (Lean UX) design is a mindset, culture, and a process that embraces LeanAgile methods. It implements functionality in minimum viable increments and determines success by
measuring results against a benefit hypothesis. Lean UX design extends the traditional UX role beyond
merely executing design elements and anticipating how users might interact with a system. Instead, it
encourages a far more comprehensive view of why a Feature exists, the functionality required to
implement it, and the benefits it delivers. By getting immediate feedback to understand if the system
will meet the real business objectives, Lean UX provides a closed-loop system for defining and
measuring
value.
Teams apply agile methods to avoid Big Design Up-front (BDUF), focusing on creating a
hypothesis about the feature’s expected business result, and implement-test that hypothesis
incrementally UX design has been an area of specialization. Agile teams are empowered to do
collaborative UX design and implementation, and significantly improves business outcomes and time-tomarket. Deliver a consistent user experience across various system elements or channels or even
different products from the same company. The primary difference is hypothesis-driven aspects can
only be evaluated by implementing the code, instrumenting where applicable, and gaining the actual
user
feedback
in
a
staging
or
production
environment.
System Team:
The System Team is a specialized Agile Team that assists in building and supporting the agile
development environment, typically including development and maintenance of the toolchain that
supports the Continuous Delivery Pipeline. The System Team may also support the integration of assets
from agile teams, perform end-to-end Solution testing where necessary, and assists with deployment
and Release on Demand. In Safe, Agile teams are not stand-alone units. Instead, they are part of the
Agile Release Train (ART), responsible collectively for delivering larger system and solution value. During
the transition to Agile, additional infrastructure work is typically required to integrate solution assets
more frequently. Once the infrastructure matures, System Teams are sometimes eliminated from an
ART, and the development teams take on the responsibilities for maintenance and use of the systems.
It involves
1. There is one System Team per ART that coordinates solution integration and validation without
additional help
2.
There is a System Team only for Solution Train, which can fulfill these responsibilities for
each of its ARTs
3. There are System Teams for both the ARTs and Solution Train
Responsibilities
1. Building Development Infrastructure
2. Solution Integration
3. End-to-End Testing
4. System and Solution Demos
Vision:
The Vision is a description of the future state of the Solution under development. It reflects
Customer and stakeholder needs, as well as the Feature and Capabilities, proposed to meet those
needs. The vision is both aspirational and achievable, providing the broader context—an overview and
purpose—of the solution under development. It describes the markets, customer segments, and user
needs. It sets the boundaries and context for new features, Nonfunctional Requirements (NFRs), and
other work. Its focus is on the solution, a portfolio vision is reflecting how the Value Streams will
cooperate to achieve the Enterprise objectives. Agile Release Trains (ARTs) and Agile Teams may have
their
own
vision
to
communicate.
Solution Vision
1. What will this new solution do? What problems will it solve?
2. What features and benefits will it provide?
3. For whom will it provide them?
4. What Nonfunctional Requirements will it deliver?
ROADMAP:
The Roadmap is a schedule of events and Milestones that communicate planned Solution deliverables
over a planning horizon. SAFe currently defines two types of roadmaps: PI roadmap and solution
roadmap. A PI roadmap includes near-term commitments for an Agile Release Train (ART) or Solution
Train for the planned, upcoming Program Increment (PI) and offers a forecast into the deliverables and
milestones for the next two to three PIs. The solution roadmap provides a longer term often multiyear
view, showing key milestones and deliverables needed to achieve the solution Vision over time.
Planning Horizon
Daily plan: Each day the team holds a Daily Stand-up (DSU) meeting to coordinate their work, review
where they are and plan what the team will work on today to achieve the iteration goals.
Iteration plan: Each iteration begins with an iteration plan, where all team members determine how
much of the Team Backlog they can commit to delivering during an upcoming iteration. The team
summarizes the work as a set of committed Iteration Goals.
Current PI plan: Represents the plan for the current PI created during the PI planning event. PI roadmap:
The PI roadmap consists of a committed plan for the current PI and offers a forecast of the deliverables
and milestones for the next two to three PIs.
Solution roadmap: Provides a longer term multiyear view, showing key milestones and deliverables
needed to achieve the solution vision over time.
PI Roadmap - consists of a series of planned PIs with milestones called out. Market events are
represented as a fixed date milestone at the top of the roadmap, while solution releases are depicted
with small boxes.
Solution Roadmap: Forecasting for three PIs will not meet the needs of enterprises that build large,
complex systems, with critical delivery dates and customer commitments. Often these require multiple
suppliers and long lead times for developing hardware and major subsystems.
PI Road Map
Solution Road Map
Milestones: Milestones are used to track progress toward a specific goal or event.
Types:
1. PI milestones – These support the ability to objectively evaluate progress towards the technical or
business hypothesis. These occur on the PI cadence.
2. Fixed-date milestones – Not everything, however, occurs on cadence. Software and systems
engineering involves many factors that rely on external events, third-party deliverables, and external
constraints. These often call for fixed-date milestones that are distinct from the development cadence.
3. Learning milestones – In addition, learning milestones help validate business opportunities and
hypotheses.
Communities of Practice (CoP ‘s) :
Organized groups of people having common interest in a specific technical or business domain.
Collaborate regularly to share information, improve skills, and actively work on advancing knowledge of
domain.
Core team – The core team forms the heart of the community that will organize, charter, market,
nurture, and operate the community.
Active – These members work closely with the core team to help shape the definition and direction of
the CoP. This includes defining the community’s shared vision, purpose, roles, and strategies for
interaction, marketing, and communications.
Occasional – These members participate when specific topics of interest are addressed or when they
have something to contribute to the group. They are often the largest group in the community.
Peripheral – These members feel a connection to the community but engage on a limited basis. These
could be newcomers or those who have a more casual interest in community activities.
Transactional – These members are the least connected to the community and may connect only to
access CoP resources or to provide a specific service to the CoP (for example, website support)
Shared Services:
Represents the specialty roles, people, and services required for the success of an Agile Release
Train (ART) or Solution Train, but cannot be dedicated full-time. Because these resources are specialized
often single-sourced and typically quite busy, each ART and Solution Train must plan to engage them.
Responsibilities:
1. Participating in Program Increment (PI) Planning as well as Pre- and Post-PI Planning.
2. Driving requirements where necessary, adding to solution intent and taking ownership of their
portion of dependent backlog items.
3. Collaborating with Agile teams to fulfill the dependencies that occur during PI execution.
4. Participating in System Demos and Solution Demos, and Inspect and Adapt ( I&A) workshops,
help in many improvement backlog items ,reflect challenges with specialized skills and
dependencies.
Metrics
Metrics are agreed-upon measures used to evaluate how well the organization is progressing toward the
portfolio, large solution, program, and team’s business and technical objectives.
Lean Portfolio Metrics
Enterprise Balanced Scorecard
The enterprise balanced scorecard provides four perspectives to measure performance for each
portfolio although the popularity of this approach has been declining over time. These measures are:
1. Efficiency
2. Value delivery
3. Quality
4. Agility
Program & Solution train Performance Metrics:
Functionality
PI-1
PI-2
Program Velocity
Predictability measure
# of Features Planned
# of Features Accepted
# of Enable Features planned
# of Enable Features Accepted
# of Stories Planned
# of Stories Accepted
Quality
Unit Test Coverage %
Defects
Total Tests ( Manual + Auto)
% Automation of tests
# of NFR Tests
PI-3
Other Metrics Verified
1. Cumulative Flow Diagram
2. Continuous Delivery Pipeline Efficiency
3. Deployments and Releases per Time-box
4. Recovery over Time
5. Velocity ( Planned vs Actual)
6. Team PI Performance Report ( Business value generated)
Built – IN – Quality
Built-In Quality practices ensure that each Solution element, at every increment, meets
appropriate quality standards throughout development. Built-in quality enables the SAFe Continuous
Delivery Pipeline and the ability to Release on Demand.
1. Higher customer satisfaction
2. Improved velocity and delivery predictability
3. Better system performance
4. Improved ability to innovate, scale, and meet compliance requirements
Continuous Delivery Pipeline
Built-in quality begins with architecture and design, which ultimately determines how well a
system can support current and future business needs. Quality in architecture and design make future
requirements easier to implement, systems easier to test, and helps to satisfy NFRs. As requirements
evolve based on market changes, development discoveries, and other reasons, architectures and
designs must also evolve. Architecture and design also determine a system’s testability. Modular
components that communicate through well-defined interfaces contain seams that allow testers and
developers to substitute expensive or slow components with test doubles. All system capabilities are
ultimately executed by the code (or components) of a system. The speed and ease with which new
capabilities can be added depends on how quickly and reliably developers can modify it.
TDD and Unit Testing: The unit testing practice breaks the code into parts and ensures that each part
has automated tests to exercise it. These tests run automatically after each change and allow developers
to make fast changes, confident that the modification won’t break another part of the system. Tests also
serve as documentation and are executable examples of interactions with a component’s interface to
show how that component should be used. Test-Driven Development (TDD) guides the creation of unit
tests by specifying the test for a change before creating it. This forces developers to think more broadly
about the problem, including the edge cases and boundary conditions before implementation. Better
understanding results in faster development with fewer errors and less rework.
Pair Work: Pairing has two developers work the same change at the same workstation. One serves as
the driver writing the code while the other as the navigator providing real-time review and feedback.
Developers switch roles frequently.
Collective Code Ownership: reduces dependencies between teams and ensures that any one developer
or team will not block the fast flow of value delivery. As part of making a change, “any developer can
change any line of code to add functionality, fix bugs, improve designs, or refactor.” supporting coding
standards encourages consistency so that everyone can understand and maintain the quality of each
component.
Achieving System Quality: While code and design quality ensure that system artifacts can be easily
understood and changed, system quality confirms that the systems work as expected and that everyone
is aligned on what changes to make. Create Alignment to Achieve Fast Flow Alignment and shared
understanding reduce developer delays and rework, enabling fast flow. Behavior-Driven Development
(BDD) defines a collaborative practice where the Product Owner and Dev Team agree on the precise
behavior for a story or feature. Applying BDD helps developers build the right behavior the first time and
reduces rework and errors.
Continuously Integrate the End-to-End Solution: continuous integration (CI) and continuous
deployment (CD) provides developers with fast-feedback on changes. Each change is built quickly and
then integrated and tested at the multiple levels, including in the deployment environment. CI/CD
automates the process to move changes through their stages and respond when a test fails. Quality
tests for NFRs are also automated. While CI/CD strive to automate all tests, some functional
(exploratory) and NFR (usability) testing can only be performed manually.
Achieving Release: Quality Releasing allows the business to measure the effectiveness of a Feature’s
benefit hypothesis. The faster an organization releases, the faster it learns and the more value it
delivers. Modular architectures that define standard interfaces between components allow smaller,
component-level changes to be released independently. Smaller changes allow faster, more frequent,
less risky releases, but require an automated pipeline to ensure quality.
Scalable Definition of Done: The continuous development of incremental system functionality requires
a scaled definition of done to ensure the right work is done at the right time, some early and some only
for release.
DEVOPS:
1. Culture
2. Automation
3. Lean Flow
4. Measurement
5. Recovery
Find a Course: Go DevOps is a mindset, a culture, and a set of technical practices. It provides
communication, integration, automation, and close cooperation among all the people needed to plan,
develop, test, deploy, release, and maintain a Solution.
Goal of DevOps:
Increases the frequency and quality of deployments Improves innovation and risk-taking by
making it safer to experiment Realizes faster time to market Improves solution quality and shortens the
lead time for fixes Reduces the severity and frequency of release failures improves the Mean Time to
Recovery (MTTR)
Collaboration and organization – DevOps relies on the ability of Agile teams and IT Operations teams to
Page 280 of 433
collaborate effectively in an ongoing manner, ensuring that solutions are developed and delivered faster
and more reliably. This is implemented, in part, by including operations personnel and capabilities on
every ART.
Risk tolerance – DevOps requires a tolerance for failure and rapid recovery, and rewards risk-taking.
Self-service infrastructures – Infrastructure empowers development and operations to act
independently without blocking each other.
Knowledge sharing – Sharing discoveries, practices, tools, and learning across silos is encouraged.
Automate everything mindset – DevOps relies heavily on automation to provide speed, consistency, and
repeatable processes and environment creation.
Automate Everything: Automation facilitates faster learning and response to market demand and
customer feedback. Builds, testing, deployments, and packaging that are automated improve the
reliability of processes that can be made routine.
Application Lifecycle Management (ALM) – Application and Agile lifecycle management tools create a
standardized environment for communication and collaboration between development teams and
related groups. Model-Based Systems Engineering provides similar information in many contexts.
Artifact Management Repository – These tools provide a software repository for storing and versioning
binary files and their associated metadata. Build – Build automation is used to script or automate the
process of compiling computer source code into binary code.
Testing – Automated testing tools include unit and acceptance testing, performance testing, and load
testing.
Continuous integration – CI tools automate the process of compiling code into a build after developers
have checked their code into a central repository. After the CI server builds the system, it runs unit and
integration tests, reports results, and typically releases a labeled version of deployable artifacts.
Continuous deployment – Deployment tools automate application deployments through to the various
environments. They facilitate rapid feedback and continuous delivery while providing the required audit
trails, versioning, and approval tracking. Additional tools – There are numerous other important DevOps
support tools: configuration, logging, management and monitoring, provisioning, source code control,
security, code review, and collaboration.
Page 281 of 433
Lean Flow:
Visualize and limit Work in Process (WIP) – Helps teams identify bottlenecks and balance the amount of
WIP against the available development and operations capacity, as work is completed when the new
feature or functionality is running successfully in production. Reduce the batch sizes of work items – The
second way to improve flow is to decrease the batch sizes of the work. Small batches go through the
system faster and with less variability, which fosters faster learning and deployment.
This typically involves focusing more attention on and increasing investment in, infrastructure
and automation. This also reduces the transaction cost of each batch. Manage queue lengths – The third
way to achieve faster flow is by managing, and generally reducing, queue lengths. For solution
development, this means that the longer the queue of work awaiting implementation or deployment,
the longer the wait time, no matter how efficiently the team is processing the work. The shorter the
queue, the faster the deployment.
Measure the Flow of Value
Collect data on business, application, infrastructure, and client layers Store logs in ways that
enable analysis Use different telemetry for different stakeholders Broadcast measurements and are
hyper-transparent Overlay measurements with events (deploys, releases) Continuously improve
telemetry during and after problem-solving.
Recover—Enable Low-Risk Releases
Stop-the-line mentality – With a stop-the-production mentality, everyone swarms to fix any problem
until it’s resolved. When there’s a problem with the continuous delivery pipeline or a deployed system,
the same thinking must apply. Findings are integrated immediately into the process or product as
they’re discovered.
Plan for and rehearse failures – When it comes to large-scale IT applications, failure is not only an
option, it’s guaranteed at some point. A proactive approach to experiencing failures will increase the
team’s response practices and also foster built-in resilience into the systems.
Build the environment and capability to fix forward or roll back – Since mistakes will be made, and
servers will fail, teams need to develop the capability to quickly ‘fix forward’ and, where necessary, roll
back to a prior known good state. In the latter case, planning and investment must be made to revert
any data changes back to the prior state, and not lose any user transactions that occurred during the
process.
Release on Demand
Release on Demand is the process by which new functionality is deployed into production and
released immediately or incrementally to Customers based on demand
Page 282 of 433
The three dimensions that precede Release on Demand help ensure that new functionality is
continuously readied and verified in the production environment. But since tangible development value
only occurs when end users are operating the Solution in their environment, releasing that value at the
right time is critical for the enterprise to gain the real benefits of agility.
When should a release happen?
What elements of the system should be released?
Which end-users should receive the release?
4 Dimensions
1. Release – covers the skills necessary to deliver the solution to end users, all at once or
incrementally
2. Stabilize and operate – covers the skills needed to make sure the solution is working well from
both a functional and non-functional perspective
3. Measure – covers the skills necessary to quantify whether the newly released functionality
provides the intended value
4. Learn – encompasses the skills needed to decide what should be done with the information
gathered and prepare for the next loop through the continuous delivery pipeline with new
hypotheses
Release Value to Customers:
When the Solution is in production and has been verified for proper operability, the time has
come to make it available to Customers. This is a crucial business decision, as releasing value too early or
too late can have severe economic repercussions. This is the manual gate. Once developers committed
code to source control, everything can be automated, up to this point. Changes might be flowing
through the pipeline through CI and CD, and they could even be smaller than stories, but as they
approach release they need to be aggregated back up to become completed Minimal Marketable
Features (MMFs), which are the smallest items that bring value to Customers. Now, in collaboration
with stakeholders, Product Management must make the decision to release what to who and when.
Dark launches – This provides the ability to deploy to a production environment without releasing the
functionality to end users.
Feature toggles -This is a technique to facilitate dark launches by implementing toggles in the code,
which enables switching between old and new functionality.
Page 283 of 433
Canary releases – These provide a mechanism for releasing the solution to a specific Customer segment
and measuring the results, before expanding and releasing to more customers.
Decouple release elements – The release need not be a monolithic, all-or-nothing process. The solution
should be architected in a way that allows different elements to be released based on need.
Stabilize and Operate:
Cross-team collaboration – A mindset of cooperation across the Value Stream to identify and solve
problems as they arise is crucial. This involves building Agile Release Trains that can operate the
solution, as well as develop it.
Failover/disaster recovery – Failures will occur. It is important to develop a failover mechanism to allow
service to resume quickly, or even avoid service interruption. Disaster recovery must be planned,
architected into the service, and practiced.
Continuous security monitoring – Security as code and penetration testing focus on preventing known
vulnerabilities from getting to production. But it is also important to test services continuously for newly
discovered and reported vulnerabilities and to detect intrusions and attacks on services and
infrastructure.
Architect for operations – Operational needs must be considered. Build telemetry and logging
capabilities into every application and into the solution as a whole. Allow services to be downgraded or
even removed in times of high loads or in response to incidents. Build capabilities for fast recovery and
for fix-forward.
Monitor nonfunctional requirements (NFRs) – System attributes such as reliability, performance,
maintainability, scalability, and usability must be continuously monitored to avoid service disruptions.
Measure the Business Value:
Innovation Accounting: Innovation Accounting focuses on how to measure the intermediate and
predictive business outcomes of the hypothesis both during initial incremental solution development
and during evaluation of the Minimal Viable Product (MVP).
Application telemetry: Application telemetry is the primary mechanism by which usage data could be
tracked and measured against the hypothesis.
Learn and React:
Lean startup thinking – If hypotheses and MVPs are evaluated, and the decision is whether the
hypotheses have been proved or refuted, should the efforts continue in the current direction, should
work stop, or should new hypotheses be formed to evaluate different approaches to the same strategy.
Value stream mapping – A key tool to improve the flow of value across the pipeline is value stream
mapping. This tool provides the visibility needed to identify bottlenecks and problem areas to flow, as
well as design a future state and create Enablers to improve the pipeline.
Relentless improvement – The flow of work can always be improved. This mindset is part of the SAFe
House of Lean and is crucial to achieving results.
Release Governance:
Release governance is the process of planning, managing, and governing solution releases,
which helps guide the value stream toward the business goals. The release governance facilitates the
activities needed to help internal and external stakeholders receive and deploy the new solution. It also
ensures that the most critical governance quality elements are appropriately addressed before
deployment—particularly internal and external security, regulatory, and other compliance guidelines.
It includes primarily
Page 284 of 433
1. Ensuring that the organization’s release governance is understood and adhered
2. Communicating release status to external stakeholders
3. Ensuring that an appropriate deployment plan is in place coordinating with marketing and
with Product and Solution Management on internal and external communications
4. Validating that the solution meets relevant solution quality and Compliance criteria
5. Participating in Inspect and Adapt (I&A) to improve the release process, value stream productivity,
and solution quality
6. Providing final authorization for the release
7. Acting as a liaison with Lean Portfolio Management (LPM), as appropriate
8. Participating in, and overseeing the final release activities
Continuous Deployment:
Continuous Deployment (CD) is the process that takes validated Features from a staging
environment and deploys them into the production environment, where they are readied for release.
Deploy to production covers the skills necessary to deploy a solution to a production environment Verify
the solution covers the skills needed to make sure the changes operate in production as intended before
they are released to customers Monitor for problems covers the skills to monitor and report on
solutions Respond and recover encompasses the skills to quickly address any problems that happen
during deployment.
Seven skills required.
1. Dark Launches
2. Feature Toggles
3. Deployment Automation
4. Selective Deployment
5. Self Service Deployment
6. Version control
7. Blue/green deployment – a technique that permits automatic switching between two
environments, one for deployment and one that is live.
Verify the Solution:
1. Production testing
2. Test automation
3. Test data management
4. Testing nonfunctional requirements (NFRs)
Monitor for Problems:
1. Full-stack telemetry
2. Visual displays
3. Federated monitoring
Respond and Recover
1. Proactive detection
2. Cross-team collaboration
3. Session replay
4. Rollback and fix forward
5. Immutable infrastructure
6. Version control
Page 285 of 433
Continuous Integration:
Continuous Integration (CI) is the process of taking features from the Program Backlog and
developing, testing, integrating, and validating them in a staging environment where they are ready for
deployment and release.
1. Develop
Break features into stories
Behavior-Driven Development (BDD)
Test-Driven Development (TDD)
Version control
Built-in quality
Application telemetry – usage data could be tracked and measured against the
hypothesis.
Threat modeling - Architect sub-dimension of continuous exploration
2. Build
Continuous code integration
Build and test automation
Trunk-based development
Gated commit
Application security
3. Test End to End
Test and production environment congruity
Test automation
Test data management
Service virtualization
Testing nonfunctional requirements (NFRs)
Continuous integration with suppliers
4. Stage
Maintain a staging environment
Blue/Green deployment
System demo
5. Culture
Integrate often
Make integration results visible
Fixing failed integrations is a top priority
Establish common cadence
Develop and maintain proper infrastructure
Apply supportive software engineering practices
Continuous Exploration
Process that fosters innovation and builds alignment on what should be built by continually
exploring market and Customer needs, and defining a Vision, Roadmap, and set of Features for a
Solution that addresses those needs.
Hypothesize – covers the skills necessary to identify ideas, and the measurements needed to validate
them with customers
Page 286 of 433
Collaborate and research – covers the skills needed to work with customers and stakeholders to refine
the understandings of potential needs
Architect – covers the skills necessary to envision a technological approach that enables quick
implementation, delivery and support of ongoing operations
Synthesize – encompasses the skills that organize the ideas into a holistic vision, a roadmap, a
prioritized program backlog, and supports final alignment during PI Planning
Collaborate and research customer needs
PI Objectives
Program Increment (PI) Objectives are a summary of the business and technical goals that an
Agile Team or train intends to achieve in the upcoming Program Increment (PI).
During PI planning, teams create PI objectives, which provide several benefits:
1. Provide a common language for communicating with business and technology stakeholders
2. Aligns the train with a shared mission
3. Creates the near-term vision, which teams can rally around and develop during the PI
4. Enables ART to assess its performance and business value achieved via
the Program Predictability Measure.
5. Communicates and highlights each team’s contribution to business value
6. Exposes dependencies that require coordination
SMART PI Objectives
Specific – States the intended outcome concisely and explicitly as possible.
Measurable – It should be clear what a team needs to do to achieve the objective. The measures
may be descriptive, yes/no, quantitative, or provide a range.
Achievable – Achieving the objective should be within the team’s control and influence.
Realistic – Recognize factors that cannot be controlled. (Hint: Avoid making ‘happy path’
assumptions.)
Time-bound – The time period for achievement must be within the PI, and therefore all objectives
must be scoped appropriately.
Program and Solution Backlogs
The Program Backlog is the holding area for upcoming Features, which are intended to address
user needs and deliver business benefits for a single Agile Release Train (ART). It also contains the
enabler features necessary to build the Architectural Runway. Product Management has
responsibility for the Program Backlog.
Page 287 of 433
The Solution Backlog is the holding area for upcoming Capabilities and Enablers, each of which
can span multiple ARTs and is intended to advance the Solution and build its architectural runway.
Solution Management is responsible for the Solution Backlog.
Backlog refinement typically includes:
1. Reviewing and updating backlog item definition and developing acceptance criteria and benefit
hypothesis
2. Working with the teams to establish technical feasibility and scope estimates
3. Analyzing ways to split backlog items into smaller chunks of incremental value
4. Identifying the enablers required to support new features and capabilities, and establishing their
capacity allocation
Capacity Allocation for PI.
1. At each PI boundary, we agree on the percentage of resources to be devoted to new features or
capabilities versus enablers.
2. We agree that System and Solution Architects/Engineering have the authority to prioritize
enabler work.
3. We agree that Product and Solution Management have the authority to prioritize business
backlog items.
4. We agree to jointly prioritize our work based on economics. We agree to collaborate on
sequencing work in a way that maximizes customer value.
It’s based on WSJF (Weighted Shortest Job First)
Business Owners
Business Owners are a small group of stakeholders who have the primary business and technical
responsibility for governance, compliance, and return on investment (ROI) for a Solution developed
by an Agile Release Train (ART). They are key stakeholders on the ART who must evaluate fitness for
use and actively participate in certain ART events
RTE and STE
1. Manage and optimize the flow of value through the ART and Solution Train using various tools,
such as the Program and Solution Kanban‘s and other information radiators.
2. Establish and communicate the annual calendars for Iterations and Program Increments (PIs).
3. Facilitate PI Planning readiness by fostering a Continuous Exploration process which drives the
synthesis of a Vision, a Roadmap, and Backlogs, and through Pre- and Post-PI Planning meetings.
4. Facilitate the PI planning event.
5. Summarize Team PI Objectives into Program PI Objectives (the RTE) and publish them for
visibility and transparency.
6. Summarize program PI objectives into Solution PI Objectives (the STE) and publish them for
visibility and transparency.
7. Assist tracking the execution of features and capabilities.
8. Facilitate periodic synchronization meetings, including the ART sync at the Program Level and
the value stream sync for Solution Trains.
9. Assist with economic decision-making by facilitating feature and capability estimation by teams
and the roll-up to Epics, where necessary.
10. Coach leaders, teams, and Scrum Masters in Lean-Agile practices and mindsets.
11. Help manage risks and dependencies Escalate and track impediments.
12. Provide input on resourcing to address critical bottlenecks.
Page 288 of 433
13. Encourage collaboration between teams and System and Solution Architects/Engineering.
14. Work with Product and Solution Management, Product Owners, and other stakeholders to help
ensure strategy and execution alignment.
15. Improve the flow of value through value streams by improving and assessing the DevOps and
Release on Demand competency.
16. Help drive the Lean User Experience (UX) innovation cycle.
17. Work with the Agile Program Management Office (APMO) on program execution and
operational excellence (see Lean Portfolio Management).
18. Understand and operate within Lean Budgets and ensure adherence to Guardrails.
19. Facilitate System Demos and Solution Demos.
20. Drive relentless improvement via Inspect and Adapt workshops; assess the agility level of the
ART and Solution Train and help them improve.
21. Foster Communities of Practice and the use of engineering and Built-In Quality practices.
System and Solution Architect/Engineering
The Solution Architect/Engineering role represents an individual or small team that defines a
shared technical and architectural vision for the Solution under development. They participate in
determining the system, subsystems, and interfaces, validate technology assumptions and evaluate
alternatives while working closely with the Agile Release Train (ARTs) and Solution Train. These
individuals, or cross-disciplinary teams, take a ‘systems view’ on solution development. They participate
in defining the higher-level functional and Nonfunctional Requirements (NFRs). That includes analyzing
technical trade-offs, determining the primary components and subsystems, and identifying the
interfaces and collaborations between them. They understand the Solution Context and work with the
teams, Customers, and Suppliers to help ensure fitness for purpose.
ScrumXP Methodology
Program Execution
Page 289 of 433
Enablers
Support the activities needed to extend the Architectural Runway to provide future business
functionality. These include exploration, infrastructure, compliance, and architecture development.
They are captured in the various backlogs and occur at all levels of the Framework.
Types of Enablers
Exploration enablers – These support research, prototyping, and other activities needed to develop an
understanding of Customer needs, including the exploration of prospective Solutions and evaluating
alternatives.
Architectural enablers – These are created to build the Architectural Runway, which allows smoother
and faster development.
Infrastructure enablers – These are created to build, enhance, and automate the development, testing,
and deployment environments. They facilitate faster development, higher-quality testing, and a faster
Continuous Delivery Pipeline.
Compliance enablers – These facilitate managing specific compliance activities, including Verification
and Validation (V&V), documentation and signoffs, and regulatory submissions and approvals.
Enabler Epics – Are written using the ‘Epic Hypothesis Statement’ format, in the same way as business
epics. Enabler epics typically cut across Value Streams and Program Increments (PIs). To support their
implementation, they must include a ‘Lean Business Case’ and are identified and tracked through the
Portfolio Kanban system. Enabler epics may also occur at the Large Solution and Program Levels.
Enabler Capabilities and Features – Occur at the Large Solution and Program levels to capture work of
that type. Since these enablers are a type of Feature or Capability, they share the same attributes,
including a phrase, benefit hypothesis and acceptance criteria. They also must be structured to fit within
a single PI.
Enabler Stories – Must fit in Iterations like any Story. Although they may not require the user voice
format, their acceptance criteria clarify the requirements and support testing.
Page 290 of 433
Sample Scenario for Enablers
Features and Capabilities
A Feature is a service that fulfills a stakeholder need. Each feature includes a benefit hypothesis
and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train
(ART) in a Program Increment (PI). A Capability is a higher-level solution behavior that typically spans
multiple ARTs. Capabilities are sized and split into multiple features to facilitate their implementation in
a single PI.
Architectural Runway
The Architectural Runway consists of the existing code, components, and technical
infrastructure needed to implement near-term features without excessive redesign and delay. It
provides the necessary technical foundation for developing business initiatives and implementing new
Page 291 of 433
Features and/or Capabilities. The architectural runway is one of the primary tools used to implement the
Framework’s Agile Architecture strategy.
Since the development of new features and capabilities consumes the architectural runway,
continual investment must be made to extend it by implementing Enablers. Some enablers fix existing
problems with the Solution, such as improving the performance or User Experience. Others might
provide foundational capabilities that will be used to support future functionality.
Architecture Runway Rules
1. Teams that build the runway iterate like every other agile team in the program.
2. Credit goes to working solutions, not models and designs.
3. Time is of the essence. It should take no more than a few iterations to implement and prove the
new architecture.
4. Very quickly after that, the program is expanded to add some feature teams who test the new
architecture with the initial, consumable features.
The architectural runway line is drawn going up and down over time, because the team builds
up some runway, then uses some, builds some more, and then uses that, too. In short, there has to be
just about the right amount at any point.
SAFe @ Team Level
The Team Level contains the roles, activities, events, and processes which Agile Teams build and
deliver value in the context of the Agile Release Train (ART). The ART roles and functions, including
the Release Train Engineer (RTE), Product Management, System Architect/Engineering, System
Team, Shared Services support all the teams on the train. As a result, agile teams are fully capable of
defining, developing, testing, and (where applicable) deploying some element of Solution value each
iteration.
Each agile team is responsible for defining, building, and testing Stories from their Team
Backlog. Using common Iteration cadence and synchronization, the teams align to a series of fixedlength Iterations to make sure the entire system is iterating. Teams use ScrumXP or Kanban to deliver
high-quality systems, routinely producing a System Demo every two weeks. This ensures that all teams
in the ART create an integrated and tested system that stakeholders can evaluate and respond to with
fast feedback.
SAFe @ Program level
It contains the roles and activities needed to continuously deliver solutions via an Agile Release
Train (ART). The program level is where development teams, stakeholders, and other resources are
devoted to some important, ongoing system development mission.
Page 292 of 433
The ART metaphor describes the program level teams, roles, and activities that incrementally
deliver a continuous flow of value. ARTs are virtual organizations formed to span functional boundaries,
eliminate unnecessary handoffs and steps, and accelerate value delivery by implementing SAFe LeanAgile principles and practices.
Although it is called the program level, ARTs are long-lived and, therefore, have a more
persistent self-organization, structure, and mission than traditional programs which usually have
definitive start and end dates, as well as temporarily assigned resources.
The ARTs operating at the Program Level are ultimately responsible for creating and releasing
value in flow at the frequency needed by the enterprise to meet market and customer demand. The
mindsets and practices in this level contribute to the enterprise competency of DevOps and Release on
Demand that makes this flow of value possible.
Highlights
1. 5 to 12 Agile Teams
2. Program Increment (PI)
3. Continuous Delivery Pipeline
4. DevOps
Roles
1.
2.
3.
4.
Product Management
System Architect/Engineer
Release Train Engineer (RTE)
Business Owners
Events
1. PI Planning
2. System Demo – Feature level. Integrated demo.
3. Inspect & Adapt – Demo @ team level.
Artifacts
1. Features
2. Program Epics
3. Program Backlog
4. Program Kanban
5. PI Objectives
6. Architectural Runway
Connection to the Portfolio, Value Stream, and Large Solution
The program vision and roadmap provide a view of the features to be developed,
reflecting customer and stakeholder needs and the approaches that are proposed to address those
needs. However, they are not developed in isolation. The work of the ART is informed by the Strategic
Themes, the Portfolio Canvas, Lean Budgets, and Guardrails for their corresponding Value Stream as
articulated by Lean Portfolio Management (LPM).
ARTs also build the component features of Portfolio Epics. For Solution Trains, the solution
vision and roadmap are developed with the help of Product and Solution Management and must be
Page 293 of 433
synchronized with all ARTs that form the Solution Train. LPM and Product and Solution Management
also collaborate on the development of the respective roadmaps and visions.
DevOps and Release on Demand
The DevOps and Release on Demand competency describes how implementing DevOps and a
continuous delivery pipeline provides the enterprise with the capability to release value, in whole or in
part, at any time necessary to meet market and customer demand.
SAFe : Large Solution
Page 294 of 433
Business Solutions and Lean Systems Engineering
1. Requirements analysis
2. Business capability definition
3. Functional analysis and allocation
4. Design synthesis Verification and validation (V&V)
5. Design alternatives and trade studies
6. Modeling and simulation
Large systems are most often decomposed by their structure (components) or behavior
(capabilities) with groups of developers assigned to build their portions of the system. Organizationally,
large solutions are built by component and capability ARTs. Like Agile teams, ARTs are cross-functional,
with all the skills necessary to deliver their solution. A Solution Train aligns all ARTs and ART teams on a
regular cadence for planning, demonstrating, improving, and learning. SAFe defines a regular
cadence within the Program Increment (PI) to integrate and demo the entire system, then adjust based
on new knowledge and plan the next increment.
1. Align teams on the ‘what’ and the ‘how’ of building future (to-be) functionality
2. Provide a record of existing requirements and design for validation and compliance concerns
(as-is)
Roadmap describes the need for multiple planning horizons. The Solution Roadmap provides a
multi-year product vision while the PI Roadmap estimates nearer-term capabilities and milestones.
Connected backlogs and roadmaps replace the traditional large, detailed schedule of program
management. These schedules were historically defined early and often by people who were not doing
the work. Consequently, these plans were not based on reality and received little commitment from
teams. With multiple planning horizons, only the near-term work is detailed, leaving placeholders for
downstream work. Multiple planning levels enable better-decentralized decisions, allowing detailed
planning to be done by the people who do the work—ARTs, and teams.
Intentional architecture and emergent design make architecture decisions a collaboration between
architects and teams throughout the entire development lifecycle. Individual components can be
released separately, as long as the interfaces remain stable.
‘Continuish integration’ concedes that integration cycles across disciplines will vary due to
differences in lead times. A local software build takes significantly less time than fabricating the next
revision of a circuit board or upgrading a packaged application. Applying cadence and synchronization
helps manage inherent variability in solution development. Cadence provides a rhythmic pattern—the
dependable heartbeat of the development process—and establishes time boxes that focus knowledge
Page 295 of 433
workers and make wait time predictable. Synchronizing the varying cadences across disciplines enables
Lean flow with frequent integration
A QMS ensures compliance with several types of non-functional requirements (NFRs), including
regulatory, statutory, industry standards, business constraints, and enterprise architectural goals.
Collectively, these NFRs are validated through compliance activities, which appear in a variety of
automated and manual processes. They provide continuous evidence of compliance and the associated
quality results.
QMS Practice
1. Build the solutions and compliance incrementally
2. Organize for value and compliance
3. Build quality and compliance in
4. Continuously verify and validate
5. Release validated solution on demand
Solution
Each Value Stream produces one or more Solutions, which are products, services, or systems
delivered to the Customer, whether internal or external to the Enterprise. a solution is either a final
product or a set of systems that enable an operational value stream within the organization. Solution
development is the subject of each Agile Release Train (ART) and value stream.
The Large Solution level supports solutions that require multiple ARTs, and typically Suppliers, to
build them. Large solutions are delivered by multiple ARTs operating together as a Solution Train.
ARTs function simultaneously to build the solution in fully integrated increments, measurable via
a Solution Demo that occurs at least during every Program Increment (PI). Solution Intent captures
evolving hypotheses on what to build and how to build it.
The Customer interacts with the development teams to clarify intent, validate assumptions, and
review progress. Solution Management and Architects help drive development, make scope and priority
decisions, and manage the flow of features and capabilities and Nonfunctional Requirements (NFRs).
Each SAFe Portfolio contains multiple value streams. Many are largely independent, while
others may have many cross-cutting concerns and dependencies.
Page 296 of 433
Overall Solution Development in SAFe
Sometimes these crosscutting concerns provide enhanced capabilities that allow strategy
differentiation. Other times, they are just dependencies that must be addressed as part of the solution
offering. When this is the case, Coordination across value streams is required.
Customer
1. An internal customer requesting their IT department build an application for them
2. An external customer who’s the buyer of a custom-built offering
Engagement Level.
1. General solution – a solution designed to be used by a significant number of customers
2. Custom-built solution – a solution built and designed for an individual customer
PRE-POST PI Planning
Pre- and post-PI planning events allow Agile Release Trains and Suppliers in large Value Streams
to build a unified plan for the next PI. The pre- and post-PI planning events serve as a wrapper for the PI
planning at the Program Level, where the actual detailed planning takes place and is incorporated into
the Innovation and Planning (IP) Iteration calendar.
1. Provide open and productive communication through face-to-face alignment
2. Synchronize ARTs with Solution Train vision via the ART and solution PI objectives
Page 297 of 433
3. Identify dependencies and foster cross-ART coordination
4. Provide the opportunity for just the right amount of solution-level architecture and user experience
guidance
5. Match solution demand to ART capacities
Inputs for PI Planning:
Inputs to pre- and post-PI planning include the solution roadmap, vision, Solution Intent, and the
top Capabilities from the Solution Backlog
Output of PI Planning:
1. A set of aggregated specific, measurable, achievable, realistic, time-bound (SMART) PI
objectives for the solution.
2. A solution planning board, which highlights the capabilities, anticipated delivery dates, and
any other relevant milestones for the solution.
3. A confidence vote (commitment) to the solution PI objectives.
The pre- and post-PI planning events bring together stakeholders from all parts of the Solution Train.
They require advance content preparation, coordination, and communication. The actual agendas and
timelines listed below are a suggested way to run these events, but various value streams may adapt
these to their capabilities and locations.
1. The executive briefing – Defines current business, solution, and customer context
2. Solution vision briefing(s) – Briefings prepared by Solution Management, including the top
capabilities in the solution backlog
3. Milestones definitions – Clearly explain upcoming events and Metrics.
Planning Context in Pre-PI Planning:
1. PI summary reports
2. Business context and solution vision
3. Solution backlog
4. Next PI features
Results in Post-PI Planning
1. PI planning report
2. Plan review, risk analysis, and confidence vote
2.1 Resolved – the issue is no longer a concern
2.2 Owned – someone takes ownership since the problem cannot be immediately
resolved
2.3 Accepted – some risks are facts or issues that must be understood and accepted
2.4 Mitigated – the impact of the risk can be reduced by implementing a contingency
plan
3. Plan rework as necessary
4. Planning retrospective and moving forward
Right Outcomes
1. A set of ‘SMART’ solution PI objectives for the Solution Train, with the business value set by
Solution Management, Solution Architect/Engineering, and customers. This may include stretch
objectives, which are goals built into the plan but not committed to by the solution. Stretch
Page 298 of 433
objectives provide the flexible capacity and scope management options needed to increase
reliability and quality of PI execution.
2. A solution planning board, which highlights the objectives, anticipated delivery dates, and any
other relevant milestones, aggregated from the program boards.
3. A commitment based on the confidence vote for meeting the solution PI objectives.
Solution Train Board – PI1
IP calendar for Solution Train and ARTs
Page 299 of 433
WSJF (Weighted Shortest Job First)
Weighted Shortest Job First (WSJF) is a prioritization model used to sequence jobs (eg.,
Features, Capabilities, and Epics) to produce maximum economic benefit. WSJF is estimated as the Cost
of Delay (CoD) divided by job size. WSJF is used to prioritize backlogs by calculating the relative CoD
and job size (a proxy for the duration).
Using WSJF at Program Increment boundaries continuously updates backlog priorities based on
user and business value, time factors, risk, opportunity enablement, and effort. WSJF also conveniently
and automatically ignores sunk costs, a fundamental principle of Lean economics.
Factors to Consider for WSJF
1. Taking an economic view
2. Ignoring sunk costs
3. Making financial choices continuously
4. Using decision rules to decentralize decision-making and control
5. If you only quantify one thing, quantify the Cost of Delay
Elements for Calculating CoD
1. User-business value – Do our users prefer this over that? What is the revenue impact on our
business? Is there a potential penalty or other adverse consequences if we delay?
2. Time criticality – How does the user/business value decay over time? Is there a fixed deadline?
Will they wait for us or move to another solution? Are there Milestones on the critical path
impacted by this?
3. Risk reduction-opportunity enablement value – What else does this do for our business? Does
it reduce the risk of this or a future delivery? Is there value in the information we will receive?
Will this feature open up new business opportunities?
Page 300 of 433
Sample Spreadsheet for calculating WSJF
Scale for each parameter by Fibonacci Series of 1, 2, 3, 5, 8, 13, 20.
Note. Do one Column at a time start by kicking with the smallest number in 1.
There must be atleast one “1 “ in each column.
Highest priority is highest WSJF.
Product and Solution Management
Product Management has content authority for the Program Backlog. They are responsible for
identifying Customer needs, prioritizing Features, guiding the work through the Program Kanban and
developing the program Vision and Roadmap.
Solution Management has content authority for the Solution Backlog. They work with customers
to understand their needs, prioritize Capabilities, create the Solution vision and roadmap, define
requirements, and guide work through the Solution Kanban.
Details:
Team – Product Owners make fast, local content decisions on behalf of the Agile Team.
Program – Product Management is accountable for content decisions for the Agile Release Trains (ARTs)
Large Solution – Solution Management has content authority for Solution Trains
Responsibilities of Product Management
1. Understand customer needs and validate solutions
2. Understand and support portfolio work
3. Develop and communicate the program vision and roadmap
4. Manage and prioritize the flow of work
5. Participate in PI planning
6. Define releases and program increments
7. Work with System Architect/Engineering to understand Enabler work
8. Participate in demos and Inspect and Adapt (I&A)
9. Build an effective Product Management/Product Owner team
Product Management’s Participation in Large Value Streams
1. Collaborate with Solution Management
2. Participate in Pre- and Post-PI Planning
3. Participate in the Solution Demo
4. Collaborate with Release Management
Page 301 of 433
Responsibilities of Solution Management
Solution Management plays a similar role to Product Management, but at the large solution
level and has content authority over capabilities instead of features. Responsibilities include working
with portfolio stakeholders, customers, ARTs and Solution Trains to understand needs and build and
prioritize the solution backlog. They have a similar vision, roadmap, solution Kanban, and solution demo
activities as well.
Solution Management, Solution Train Engineer, and Solution Architect/Engineering—are part of
a trio that shares much of the responsibility for the success of a Solution Train. Solution Management is
responsible for the solution intent, which captures and documents fixed and variable solution level
behaviors. They also work with Release Management where applicable.
Solution Management has a crucial role in pre- and post-PI planning, as well as large solution
level I&A workshops. They also work with Suppliers, making sure the requirements for supplierdelivered capabilities are understood and assisting with the conceptual integration of these concerns.
System and Solution Architect/Engineering
The Solution Architect/Engineering role represents an individual or small team that defines a
shared technical and architectural vision for the Solution under development. They participate in
determining the system, subsystems, and interfaces, validate technology assumptions and evaluate
alternatives while working closely with the Agile Release Train (ARTs) and Solution Train.
These individuals, or cross-disciplinary teams, take a ‘systems view’ on solution development.
They participate in defining the higher-level functional and NFRs. That includes analyzing technical
trade-offs, determining the primary components and subsystems, and identifying the interfaces and
collaborations between them.
They understand the Solution Context and work with the teams, Customers, and Suppliers to
help ensure fitness for purpose. Collaborating with Solution and Product Management,
Architect/Engineering plays a critical role in aligning teams to a shared technical direction toward the
accomplishment of the Vision and Roadmap.
1. Certain larger-scale architectural decisions should be centralized. These include the definition of
primary system intent, subsystems, and interfaces; allocation of functions to subsystems;
selection of platforms; elaboration of solution-level NFRs; and elimination of redundancy.
2. However, most design decisions are the responsibility of Agile teams, who must balance
applying emergent design in conjunction with intentional architecture.
Solution Intent
Solution Intent is the repository for storing, managing, and communicating the knowledge of
current and intended Solution behavior. Where required, this includes both fixed and variable
specifications and designs; reference to applicable standards, system models, and functional and
nonfunctional tests; and traceability. Building large-scale software and cyber-physical systems are one of
the most complex and challenging endeavors in the industry today. This requires alignment on two
central questions:
1. What exactly is this thing we are building?
2. How are we going to build it?
Purpose
1. Provides a single source of truth regarding the intended and actual behavior of the solution
2. Records and communicates requirements, design, and system architecture decisions
3. Facilitates further exploration and analysis activities
Page 302 of 433
4. Aligns the Customer, Dev Team, and Suppliers to a common mission and purpose
5. Supports Compliance and contractual obligations
Current and future states – Developers of complex systems must constantly know two things: what
exactly the current system does now, and what changes are intended for a future state Specifications,
designs, and tests – Knowledge of both the current and future states can be captured in any form
suitable—as long as it includes the three primary elements: specifications (documented definition of
system behavior), design, and tests.
The solution intent is not a static, one-time statement: it must support the entire development
process and continue to evolve.
Solution Intent hierarchy
Page 303 of 433
Create Minimal but Sufficient Documentation
1. Favoring models over documents
2. Keeping solution intent collaborative
3. Keeping options open
4. Documenting items in only one place
5. Keeping it simple
Compliance
Compliance refers to a strategy and a set of activities and artifacts that allow teams to apply
Lean-Agile development methods to build systems that have the highest possible quality, while
simultaneously assuring they meet any regulatory, industry, or other relevant standards.
A Lean-Agile quality management system improves quality and makes compliance more predictable
continuously verify and Validate (V & V)
Page 304 of 433
Release Validated Solutions on Demand
1. Validation testing of the final release candidate (examples: medical trial, flight test)
2. Review of the objective evidence required before production approval and release
3. Customer, regulatory, UAT, signoffs, document submissions
Model-Based Systems Engineering
MBSE is the application of modeling requirements, design, analysis, and verification activities as a costeffective way to explore and document system characteristics. By testing and validating system
characteristics early, models facilitate timely learning of properties and behaviors, enabling fast
feedback on requirements and design decisions.
Create Testable and Executable Models
1. Mechanical models test for physical and environmental issues
2. Electrical models test for logic
3. Software models test for anomalies
4. Executable system models test for system behavior
Set-Based Design
Set-Based Design (SBD) is a practice that keeps requirements and design options flexible for as
long as possible during the development process. No matter how well a system is initially defined and
designed, real customer needs and technological choices are both uncertain and evolving. Therefore,
understanding how a system needs to be implemented must adapt over time.
Factors involved.
Flexibility – Preserving a broad set of design options for as long as possible
Cost – Minimizing the cost of multiple options through modeling, simulation, and prototyping
Speed – Facilitating learning through early and frequent validation of design alternatives.
Page 305 of 433
Economic Framework
The Economic Framework is a set of decision guidelines that align everyone with the financial
objectives of the Solution and informs the economic decision-making process.
Primary Elements
1. Operating within Lean Budgets and Guardrails
2. Understanding solution economic trade-offs
3. Leveraging Suppliers
4. Sequencing jobs for the maximum benefit (using WSJF)
It requires.
1. An understanding of the rules for decision-making
2. The current local context
3. Relevant decision-making authority
The funding is allocated to long-lived Value Streams that produce the Solutions vital to the
organization. Once this transition is complete, the cost for each Program Increment (PI) is largely fixed,
and scope is varied as necessary. Each value stream budget can then be adjusted over time at PI
boundaries, based on the relative value that each provides to the portfolio.
Guardrails inform the oversight and governance that guide the creation and management of
Lean Budgets. They provide the budgeting parameters with degrees of freedom that Solution Train
leaders use to deliver innovative, competitive solutions.
Examples of guardrails include:
1. Defined investment horizons
2. Capacity allocation
3. Approvals and metered funding
4. Ongoing business owner engagement.
Economic tradeoff
1. Development expense – the cost of labor and materials required to implement a capability
2. Lead time – the time needed to implement the capability
3. Product cost – the manufacturing cost (of goods sold) and/or deployment and operational costs
4. Value – the economic worth of the capability to the business and the customer
5. Risk – the uncertainty of the solution’s technical or business success
Two primary reasons for engaging suppliers in solution development
1. Insufficient workforce capacity.
2. Availability of specialty components resources, or skills sets.
Page 306 of 433
SAFe - PORTFOLIO MANAGEMENT
Page 307 of 433
Portfolio Level
The Portfolio Level contains the principles, practices, and roles needed to initiate and govern a
set of development Value Streams. This is where strategy and investment funding are defined for value
streams and their Solutions. This level also provides Agile portfolio operations and Lean governance for
the people and resources needed to deliver solutions.
The portfolio level aligns enterprise strategy to portfolio execution by organizing the Lean-Agile
Enterprise around the flow of value through one or more value streams. Delivering the basic budgeting
and necessary governance mechanisms, including Lean Budget Guardrails, it help assures that the Value
Streams and its trains are focused on building the right things with the appropriate level of investments
to these solutions in order for the portfolio to meet its strategic objective.
Each SAFe portfolio has a two-way connection to the enterprise. The first way establishes the
Strategic Themes for the portfolio that guide it through ever-changing business objectives. The second
way provides a constant flow of feedback from the portfolio back to the enterprise stakeholders. This
includes: The current state of the portfolio’s solutions Value stream key performance indicators (KPIs)
Qualitative assessments of the current solution’s fitness for purpose Assessments of strengths,
weaknesses, opportunities, and threats present across the portfolio.
It includes
1. Lean Budgets – Lean budgeting allows fast and empowered decision-making, with appropriate
financial control and accountability provided through Guardrails.
2. Value Streams – Every value stream has to fund the people and resources necessary to build
Solutions that deliver the value to the business or customer. Each is a long-lived series of steps
(system definition, development, and deployment) that build and deploy systems that provide a
continuous flow of value.
3. Portfolio Kanban – The portfolio Kanban system makes the work visible and creates Work-inProcess (WIP) limits to help assure that demand is matched to the actual value stream and Agile
Release Train (ART) capacities.
4. Portfolio Canvas – The Portfolio Canvas defines and describes the purpose of a SAFe portfolio.
Roles
1. Lean Portfolio Management (LPM) – This function represents the individuals with the highest level
of decision-making and financial accountability for a SAFe portfolio. This group is responsible for
three primary areas: strategy and investment funding, Agile portfolio operations, and Lean
governance.
2. Epic Owners – They take responsibility for coordinating portfolio Epics through the portfolio Kanban
system.
3. Enterprise Architect – This person works across value streams and programs to help provide the
strategic technical direction that can optimize portfolio outcomes. The Enterprise Architect often
may act as an Epic Owner for enabler epics.
Artifacts Involved
1. Business Epics – Capture and reflect the new business capabilities that can only be provided
through cooperation among value streams.
2. Enabler epics – Reflect the architectural and other technology initiatives that are necessary to
enable new Features and Capabilities.
Page 308 of 433
3. Strategic themes – Provide specific, itemized business objectives that connect the portfolio to
the evolving enterprise business strategy.
4. Portfolio Backlog – Is the highest-level backlog in SAFe. It holds approved business and enabler
epics that are required to create a portfolio solution set. This provides the competitive
differentiation and/or operational efficiencies necessary to address the strategic themes and
facilitate business success.
Lean Portfolio Management
Aligns strategy and execution by applying Lean and systems thinking approaches to strategy and
investment funding, Agile portfolio operations, and governance.
A SAFe portfolio is a single instance of the Framework that manages a set of Value Streams for a
specific business domain (e.g., consumer banking, commercial insurance, department of veteran affairs).
Each value stream delivers a set of software and system Solutions that help the enterprise meet its
business strategy, either by providing value directly to the customer or in support of internal business
processes.
Why Lean Portfolio
1. Annual planning and rigid budgeting cycles
2. Measures of progress that focus on document-driven deliverables and task completion, versus
objective measures of value
3. Perpetual overload of demand versus capacity, which decreases throughput and belies effective
strategy
4. Phase-gate approval processes that don’t mitigate risk and discourage incremental delivery
5. Project-based funding (moving people to the work) and cost accounting, which causes friction
and unnecessary overhead, finger pointing, bureaucracy, and delays
6. Overly detailed business cases based on highly speculative and lagging ROI projections
7. Centralizing and developing requirements with people who will not be doing the actual
implementation
8. Iron-triangle strangulation (fixed scope, cost, and date projects), which limits agility and does
not optimize the total economic value
9. Traditional Supplier management and coordination, which favors win-lose contracts, and
focuses on the lowest short-term cost, rather than the highest lifecycle value.
Essential Collaborations
1. Strategy and investment funding : Only by allocating the ‘right investments’ to building the
‘right things’ can an enterprise accomplish its ultimate business objectives. Achieving these
goals requires the focused and continued attention of LPM
2. Agile portfolio operations : The primary responsibilities of this collaboration include
coordinating value streams, supporting program execution & driving operational excellence,
Page 309 of 433
through Communities of Practice (CoPs), a Lean-Agile Center of Excellence (LACE), and other
activities.
3. Lean governance :
Portfolio Sync: Similar to the ART Sync, some enterprises hold a ‘Portfolio Sync’ meeting, which typically
occurs bi-weekly, or more or less frequently as needed. Below activities are covered.
1. Adjusting value stream funding
2. Reviewing portfolio Kanban and lightweight business cases, and approving and prioritizing epics.
3. Maintaining the portfolio vision and canvas
4. Removing impediments across value streams
5. Considering the results of MVPs and determining whether to pivot or preserve
6. Reviewing the progress of continuous improvement efforts to drive operational excellence
7. Evaluating spend by investment horizon
Value Stream KPI ‘s
A Lean budgeting process can substantially simplify financial governance, empower
decentralized decision-making, and increase the flow of value through the enterprise. It’s a bold move
to go from funding projects to allocating budgets to value streams.
1. Some value streams produce revenue, or end-user value directly, in which case revenue may be an
appropriate measure. Other metrics such as market share or solution usage may provide additional
insight.
2. Other value streams, or elements of a value stream, are creating emergent new offerings. In this
case, the potential return on investment (ROI) is a lagging economic measure. Instead, using
nonfinancial, innovation accounting KPIs to get fast feedback may be a better choice.
3. Some development value streams are merely cost centers, which serve internal operational value
streams and are not independently monetized. In this case, measures such as customer satisfaction,
net promoter score, team/ART self-assessment, and feature cycle time may be more relevant.
4. In the most significant scale, a value stream may establish an even broader set of measures, such as
those represented by the sample Lean-Agile portfolio Metrics.
Lean Budget Guardrails
It describe budgetary, governance and spending policies and practices for the lean budgets
allocated to a specific portfolio. LPM fiduciaries maintain appropriate levels of oversight through the
allocation of value stream budgets and approval of Epics, while empowering trains to make decisions
quickly and enable flexible value delivery. This way, enterprises can have the best of both worlds: a
Page 310 of 433
development process that is far more responsive to market needs, along with professional and
accountable management of spending.
1. Guiding investments by horizon
2. Optimizing value and solution integrity with capacity allocation
3. Approving significant initiatives
4. Continuous Business Owner engagement
Page 311 of 433
Lean Budgets
Lean Budgets is a set of funding and governance practices that increase development
throughput by decreasing funding overhead and friction while maintaining financial and fitness-for-use
governance. Every SAFe portfolio operates within an approved budget, which is a fundamental principle
of financial governance for the development and deployment of products, services, and IT
business Solutions within a SAFe portfolio.
Key steps are
1. Funding value streams, not projects
2. Guiding investments by horizon
Horizon 3 (Evaluating): Horizon 3 investments are those dedicated to investigating new potential
solutions.
Horizon 2 (Emerging): Horizon 2 reflects the investments in solutions which have emerged from horizon
three. Since these are promising new solutions, the business is willing to make ongoing investments in
excess of the current return.
Page 312 of 433
Horizon 1: Horizon one reflects the desired state where solutions deliver more value than the cost of the
current investment. These solutions require ongoing investment to maintain and extend functionality.
Horizon 0 (Retiring): All solutions eventually meet end-of-life. Horizon 0 reflects the investment needed
to decommission a deployed solution.
Applying participatory budgeting:
Participatory Budgeting does not require funding each value stream to the full requested
amount. Indeed, one of the goals of this model is to provide leaders with the forum needed to share
data that can help the portfolio optimize its budget choices.
Portfolio Canvas:
The canvas that identifies specific domain of concern for a SAFe portfolio. It helps streamline
planning, development, and execution across the portfolio, aligning everyone’s objectives and
facilitates team communication and the exchange of new ideas. he Business Model Canvas (BMC), and
its derivatives, such as the Lean Canvas, are used by large companies and startups around the world.
The SAFe Portfolio Canvas is an adaptation of the BMC that highlights the ‘development value
streams’ and other aspects specific to a SAFe portfolio. This canvas can be easily updated as the business
changes, and new learning occurs. The nine original blocks of the BMC appear in a bold font with an
icon. New blocks, which appear in a standard font, enable alignment of the portfolio canvas to specific
SAFe constructs.
Main sectors
1. Value Propositions
The value propositions describe the customers and the value delivered by the solutions of each
value stream, as well as the customer segments and relationships, budget and KPIs revenue.
Value Streams: This section describes the development value streams that are used to build the
systems and capabilities that enable the operational value streams, or provide end customer value.
Page 313 of 433
Solutions: Each value stream produces one or more solutions, which are the products, services, or
systems delivered to the Customer, whether internal or external to the Enterprise Customer
Segments: Customer segments describe the internal or external customers for each value stream.
Channels: This section describes the chain of businesses that are used to reach each customer
segment. If serving external customers, this may include marketing and sales mechanisms used to
reach customers (e.g., web, direct sales, brick and mortar store, distribution network). If serving
internal customers, it captures the interfaces with internal stakeholders and end-users (e.g., internal
websites or custom IT applications).
Customer Relationships: This section describes the connections and communications with each
customer segment. These relationships influence the design of solutions and the allocation of
resources within the portfolio.
Budget: Each value stream is assigned a Lean Budget, which includes operating, overhead and
capital expenses.
even
KPIs / Revenue: Key Performance Indicators (KPIs) define the measures that will be used to
evaluate the results of the value stream investment. Lean-Agile portfolio Metrics provide an
broader set of performance measures, which may also be useful.
2. Resources and Activities
The resources and activities describe the key partners, activities and other resources
needed to achieve the value propositions.
Key Partners: Describes the business partners needed to deliver value to a customer segment.
These intermediaries help leverage economies of scale and centralize certain services outside
the portfolio, such as external Suppliers.
Key Activities: Describes the high-level activities used to create value for customer segments.
Many of these will be standard SAFe events, such as PI Planning, Inspect and Adapt, etc. Others,
such as trade shows, customer advisory meetings, etc., are unique to the specific business
context.
Key Resources: Describes the resources needed to develop, market and maintain the value
propositions (e.g., What are the most important physical, financial, intellectual, or human assets
necessary to deliver value to your customer segments?). This includes the resources within your
portfolio, such as Shared Services.
3. Cost Structure and Revenue Streams
The cost structure and revenue streams describe how the portfolio’s costs are
structured and define how revenue or value is achieved.
Cost Structure: Identifies the most significant costs inherent in the portfolio’s business model,
including the structural aspects, such as license costs, development labs, and any operational
costs of external services. Building cyber-physical systems also have other costs (e.g., hardware
and firmware) which must be considered here.
Page 314 of 433
Revenue Streams: If the development value streams monetize directly, list the types and
sources of revenue from customers. Note the major sources of revenue and how the customer
is charged (fixed price, usage-based, etc.). For internal customers, describe the impact on the
stakeholders or the value the solutions create.
As part of filling out the current state portfolio canvas, it can be useful to reason further about each
value proposition. One way to do this is to create separate value stream canvases, which are then rolled
up to the portfolio.
Page 315 of 433
Envisioning the Future State:
Evaluate Alternatives for Future State.
The LPM team uses the current state portfolio canvas as a starting point to explore the different
ways in which the portfolio could evolve in alignment with the strategic themes. Start by selecting a
specific block in the portfolio canvas, identifying a potential change or opportunity, and then explore
how it impacts the other parts of the canvas.
Page 316 of 433
Every SAFe portfolio operates within an approved budget. The strategic themes and portfolio
canvas are critical inputs to allocating a portion of the total portfolio budget to a specific value stream.
Each value stream must work within an approved budget. Any change to a value stream budget requires
appropriate approvals. Further, Lean budgets are governed by a set of Guardrails, which describe the
budgetary controls and spending policies for the portfolio.
The creation of the current and future state Portfolio Canvas is not a once-and-done exercise. As
new information is learned about the evolving set of portfolio solutions, portfolio stakeholders
periodically review and update the canvas. Other triggers include the introduction of new solutions,
mergers and acquisitions, the market rhythms of the portfolio defined in the portfolio Roadmap, and
other strategic changes that may affect the portfolio’s value streams or solutions.
https://strategyzer.com/canvas/value-proposition-canvas -For Reference. Most important to read
Enterprise Architect:
The Enterprise Architect promotes adaptive design, and engineering practices and drives architectural
initiatives for the portfolio. Enterprise Architects also facilitate the reuse of ideas, components, services,
and proven patterns across various solutions in a portfolio.
Five elements of enterprise architecture strategy
EPIC Owners.
Epic Owners are responsible for coordinating portfolio Epics through the Portfolio Kanban system. They
define the epic, its Minimum Viable Product (MVP), and Lean business case, and when approved,
facilitate implementation.
The collaborative nature of the Epic Owner role
Page 317 of 433
Strategic Themes
Strategic Themes are differentiating business objectives that connect a portfolio to the strategy
of the Enterprise. They influence portfolio strategy and provide business context for portfolio decisionmaking. Strategic themes are formulated via a collaborative process in which the Enterprise executives
and fiduciaries work with Lean Portfolio Management and other portfolio stakeholders to analyze a set
of inputs before arriving at conclusions.
Strategic themes provide insight into the portfolio backlog Epics that are necessary to achieve
the vision. Further, they serve as inputs to decision-making criteria in the Portfolio Kanban system.
Strategic themes profoundly influence value stream budgets, which provide the investment and
allocation of people needed to accomplish the strategic intent.
They have an influence on the vision and backlogs for development at every portfolio level. They
help determine the attributes of Weighted Shortest Job First (WSJF) prioritization for items in the
program and solution backlogs. Solution and program epics that flow from the portfolio, or arise locally,
are also influenced by the current themes. Due to their importance, strategic themes will often be
presented (and repeated!) by the Business Owners during Program Increment (PI) Planning. Moreover,
strategic themes provide vital conceptual alignment across the trains in a large solution, and across the
teams on an Agile Release Train.
Enterprise
The portfolio is not the entire business. So, it’s crucial for the enterprise and portfolio
stakeholders to ensure that each portfolio solution set evolves to meet the broader business needs. This
is a critical capability of the Lean Enterprise.
Page 318 of 433
Two Primary Mechanisms:
1. The portfolio budget is total funding provided to a portfolio for development, operating &
capital expenditures. It’s allocated to the individual Value Streams by Lean Portfolio Management
(LPM).
2. Working together, enterprise executives and portfolio stakeholders establish a set of Strategic
Themes. These are specific, differentiated business goals that communicate aspects of strategic intent
from the enterprise to the portfolio.
The enterprise strategy drives each portfolio budget. The enterprise strategy drives each
portfolio budget. In the tech sector, many philosophies and current trends influence strategy
formulation.
Major Inputs
1. Total enterprise budget
2. Enterprise business drivers
3. Financial goals
4. Mission, vision, and core values
5. Portfolio context
6. Competitive environment
From SAFe Environment
1. Portfolio Budget
2. Strategic Themes
Portfolio Context Informs Enterprise Strategy:
1. Key performance indicators (KPIs) – The portfolio is responsible for providing feedback on the
allocated investment spend. This can include quantitative and financial measures, such as return
on investment (ROI), market share, customer net promoter score, and Innovation Accounting.
2. Qualitative data – This often includes a SWOT analysis and, most importantly, the accumulated
solution, market, and business knowledge of the portfolio stakeholders.
3. Lean Budget Guardrails – Each portfolio also contains a set of Guardrails, which describe
budgetary and spending policies and practices for a specific portfolio. These can be driven by—
and are drivers of—elements of the business strategy.
Page 319 of 433
SAFe – ADVANCED TOPICS
Page 320 of 433
Agile Contracts
Builders of large-scale systems must continually align with customers and other stakeholders on
what’s being built. And they often must do so in the midst of continuous changes driven by
development discoveries, evolving customer needs, changing technologies, and competitor innovations.
Different Contract Types
SAFe Managed-Investment Contracts
Step 1 : Pre-commitment
During pre-commitment, the customer has specific responsibilities, including understanding the
basic constructs and obligations of this form of Agile contract, and defining and communicating the
larger program mission statement to the potential supplier(s). The supplier does their initial homework
as well. This often includes the first analysis of potential feasibility and alignment of the buyer’s solution
needs with the supplier’s core competence. It also demands some understanding of the potential
resources that will be required over the initial contract periods and a rough cost estimate.
1. Establishing the initial Vision and Roadmap
2. Identifying the Minimum Viable Product (MVP) and additional Program Increment (PI)
potential Features
3. Defining the initial fixed and variable Solution Intent
4. Prioritizing the initial Program Backlog for PI Planning
5. Establishing execution responsibilities
6. Establishing the Economic Framework, including economic trade-off parameters, the PI
funding commitment (number of PIs committed), initial funding levels, and other contractual
term
Depending on context, the customer may have discussions with multiple potential
suppliers. If significant technical feasibility is involved, this can often be done under some form
of feasibility contract, whereby each potential supplier is compensated for the efforts to get to
commitment. this may be simply business as usual for the supplier, with these pre-commitment
investments occurring as a normal part of presale activities.
Page 321 of 433
Step 2 : Contract Execution
1. PI preparation – Both supplier and customer will invest some time and effort in preparing content
and logistics for the first PI planning session. (Note: In some cases, it might be suitable that the first
PI planning is part of the pre-commitment phase, though this route clearly requires significant
investment by both parties.)
2. PI planning – The first PI planning event influences the entire program. There, customer and
supplier stakeholders plan the first PI in iteration-level detail.
3. PI execution – Depending on context, customers participate at various levels in iteration execution.
At a minimum, however, direct customer engagement is usually required for each System Demo. For
large solutions, however, the multiplicity of system demos may be replaced by a more fully
integrated Solution Demo, which can occur more frequently than at PI boundaries.
4. PI evaluation – Thereafter, each PI marks a critical Milestone for both the customer and the
supplier. At each milestone, the solution demo is held, and the solution is evaluated. Agreed-to
metrics are compiled and analyzed, and decisions are made for the next PI. Solution progress and
program improvements are assessed during the Inspect and Adapt (I&A) event. At this point, the
customer may decide to increase, decrease, or maintain funding levels, or even begin to wind down
the initiative based on whether sufficient value has or has not been achieved. Thereafter, the next PI
planning commences, with the scope based on the outcome of that decision.
Page 322 of 433
SAFe managed-investment contract execution phase
Step 3: Managing Risk with the Lean Startup Approach
This Lean Startup model decreases time-to-market and helps prevent the system from becoming
bloated with unnecessary features that may never be used. It also enforces the ‘hypothesize-buildmeasure-learn’ cycle.
The implication is that Agile contract language is modified to reflect a combination of fixed and
variable components. The MVP identified at the pre-commitment stage can establish a high-level
definition of fixed scope to be delivered over a proposed number of PIs. Beyond the delivery of the
MVP, the contract can also specify the number of option periods consisting of one or more PIs. The goal
is to optimize the delivery of prioritized features within each PI.
This process continues until the solution has delivered the value the customer requires. At this
point, the customer stops exercising additional option periods and starts winding down funding
commitments in accordance with the agreement. This provides the best of both worlds to customers:
Better predictability of estimates associated with a far smaller MVP than the full list of all requirements
Total control over the spend required for additional incremental features based on economic outcomes
such an approach provides the greatest economic benefit to both parties, which will help create stable,
long-term relationships.
Page 323 of 433
The Lean Startup Cycle for managing large product development investments
Applied Innovation Accounting in SAFe
Developing innovative world-class solutions is an inherently risky and uncertain process. But this
level of uncertainty causes some enterprises to avoid taking the right risks, and when they do, it
increases the likelihood they will spend too much time and money building the wrong thing, based
on flawed data or invalid assumptions. NPV (Net Present Value) and IRR (Internal Rate of Return),
though more forward-looking, is based on estimating the unknowable future cash returns and
speculative assumptions of investment costs and discount rates. a different kind of economic
framework—one that quickly validates product assumptions and increases learning through Lean
Startup Cycle.
Innovation Accounting
It has 3 key milestones listed below.
1. Minimum Viable Product (MVP) – establish a baseline to test assumptions and gather objective
data.
2. Tune the Engine – quickly adjust and move towards the goal, based on the data gathered.
Page 324 of 433
3. Pivot or persevere – Decide to deliver additional value, or move on to something more valuable,
based on the validated learning. (Lean thinking defines value as providing benefit to the
customer anything else is waste.)
To validate learning and reduce waste, a fast feedback loop is essential, also referred to as
‘build-measure-learn. Applying the learning obtained from real customer feedback results in
increased predictability, decreased waste, and improved shareholder value.
Validate 2 questions below.
1) Are we making progress towards our outcome hypothesis?
2) How do we know?
Leading indicators are designed to harvest the results of development and deployment of a
Minimal Viable Product (MVP). These indicators may include non-standard financial metrics such as
active users, hours on a website, revenue per user, net promoter score, and more.
Measuring Metrics.
The implementation of large, future-looking initiatives is an opportunity for organizations to
reduce waste and improve economic outcomes. Here, large initiatives are represented as Epics and are
captured using an epic hypothesis statement. This tool defines the initiative, its expected benefit
outcomes, and the leading indicators used to validate progress toward its hypothesis.
Leading indicators can provide immediate feedback on usage patterns. By analyzing the objective
data, we can test our hypothesis and decide to continue releasing additional features, tune the engine,
or pivot to something else. Thus, the Epic’s MVP and the leading indicators enable us to make faster
economic decisions based on facts and findings.
Validated learning becomes the primary objective of testing the hypothesis. SAFe uses the Lean
Startup Cycle to iteratively evaluate the MVP of Epics and to pivot (change direction, not strategy), or
persevere (keep moving forward) decision against the outcomes hypothesis.
This is done incrementally by developing and evaluating features from the Epic. The empirical
metric we use to prioritize the features is Weighted Shortest Job First (WSJF). Using WSJF, we can
rapidly evaluate the economic value of the feature and the overall progress of the Epic towards its
Business Outcome. This allows us to quickly and iteratively make a pivot-or-persevere decision based on
objective data.
CapEx and OpEx (Capital and Operational Expences)
Capital Expenses (CapEx) and Operating Expenses (OpEx) describe Lean-Agile financial
accounting practices in a Value Stream budget. CapEx may include capitalized labor associated with the
development of intangible assets—such as software, intellectual property, and patents. Enterprises fund
Page 325 of 433
a SAFe portfolio to support the development of the technical Solutions that allow the company to meet
its business and financial objectives. These Lean Budgets may include both CapEx and OpEx elements.
Within the portfolio, allocating funds to individual value streams is the responsibility of Lean
Portfolio Management (LPM), which allocates the necessary funding for each value stream in a portfolio.
It includes
1. Salaries
2. The burden for operating personnel, sales, and marketing
3. General and administrative costs
4. Training
5. Supplies and maintenance
6. Rent
7. Other expenses related to operating a business or an asset of the business
Costs are recorded and expensed in the period in which they occur. Capex reflects the monies
required to purchase, upgrade, or fix tangible physical assets, such as computing equipment, machinery,
or other property. Portfolio stakeholders must understand both CapEx and OpEx so that they are
included in the Economic Framework for each value stream. Otherwise, money may not be spent in the
right category, and/or the financial results of the portfolio may not be accurate.
Capitalization versus Expense Criteria
Capitalization Strategies in SAFe
Waterfall
Page 326 of 433
The majority of the work of most ARTs is typically focused on building and extending software assets
that are past the point of feasibility analysis. They generally do this by developing new features for the
solution. Since Features increase the functionality of existing software, the User Stories associated with
those features constitute much of the work of the ART personnel.
Therefore, this labor may be subject to potential capitalization. The ARTs also help establish the
business and technical feasibility of the various portfolio initiatives (Epics) that work their way through
the Portfolio Kanban. This feasibility work is somewhat analogous to the early stages of waterfall
development and is typically expensed up until the ‘go’ recommendation when new feature
development would begin.
This means that both types of work are typically present in any PI—and, by extension, any
relevant accounting period. Much of this is new feature work that increases the functionality of the
existing software. Other work includes innovation and exploration efforts. These may be initiated from
the portfolio Kanban—as part of the research and feasibility for potential new portfolio-level epics—or
they may arise locally.
Many types of work occur within a given PI timebox
Page 327 of 433
Creating new features for the solution is part of implementing new projects and enhancing
existing products. By their very definition, features provide enhanced functionality. Features can be
easily identified and tracked for potential CapEx treatment.
Applying Stories to CapEx and OpEx Treatment
The most granular means for capturing labor effort is to have team members record their hours
against each story. Although there’s some overhead, many teams do this anyway because of traditional
time-tracking requirements for job costing, billing, estimating, and other needs. However, this should
not be the default mode for CapEx, as it incurs overhead and thus reduces value delivery velocity. The
rest of the calculation is straightforward: the CapEx potential percentage is simply the percentage of
hours recorded for CapEx features, divided by the total of all hours invested in any period.
Page 328 of 433
Ten Essential SAFe Elements
These 10 essential elements also help an organization achieve three Lean Enterprise
competencies: Lean-Agile Leadership, Team and Technical Agility, and DevOps and Release on Demand.
Moreover, Essential SAFe provides the foundation for achieving the Business Solutions and Lean
Systems Engineering and Lean Portfolio Management competencies.
#1 – Lean-Agile Principles: SAFe practices are grounded in fundamental Lean-Agile principles. That’s why
you can be confident that they apply well in your case. And if the practices don’t directly apply, the
underlying principles can guide you to make sure that they are moving on a continuous path to the
‘shortest sustainable lead time, with best quality and value to people and society.’
#2 – Real Agile Teams and Trains: Real Agile Teams and Agile Release Trains (ARTs) are fully crossfunctional. They have everything, and everyone, necessary to produce a working, tested increment of
the solution. They are self-organizing and self-managing, which enables value to flow more quickly, with
a minimum of overhead. Product Management, System Arch/Eng, and Release Train Engineer provide
content and technical authority, and an effective development process. Product Owners and Scrum
Masters help the Dev teams meet their PI Objectives. The Agile teams should engage the customer
throughout the development process.
#3 – Cadence and Synchronization : Cadence provides a rhythmic pattern, the dependable heartbeat for
the development process. It makes routine those things that can be routine. Synchronization allows
multiple perspectives to be understood and resolved at the same time. For example, synchronization is
used to pull the various assets of a system together to assess solution-level viability.
#4 – PI Planning: No event is more powerful in SAFe than PI Increment (PI) planning. It’s the
cornerstone of the PI, which provides the rhythm for the ART. When 100 or so people work together
Page 329 of 433
toward a common mission, Vision, and purpose, it’s amazing how much alignment and energy it creates.
Gaining that alignment in just two days can save months of delays.
#5 – DevOps and Releasability: DevOps provides the Culture, Automation, Lean-flow, Measurement,
and Recovery capabilities to enable an enterprise to bridge the gap between development and
operations. Releasability focuses on the enterprise’s ability to deliver value to its Customers more often
and according to the demands of the market. Together they allow an organization to achieve better
economic results by having more frequent releases and faster validation of hypotheses.
#6 – System Demo : The primary measure of the ART’s progress is the objective evidence provided by a
working solution in the System Demo. Every two weeks, the full system— the integrated work of all
teams on the train for that iteration—is demoed to the train’s stakeholders. Stakeholders provide the
feedback the train needs to stay on course and take corrective action.
#7 – Inspect and Adapt : Inspect and Adapt is a significant event held every PI. A regular time to reflect,
collect data and solve problems, the inspect and adapt assembles teams and stakeholders to assess the
solution, and define and take action on the improvements needed to increase the velocity, quality, and
reliability of the next PI.
#8 – IP Iteration : The Innovation and Planning Iteration occurs every PI and serves multiple purposes. It
acts as an estimating buffer for meeting PI objectives, and provides dedicated time for innovation,
continuing education, and PI planning and Inspect and Adapt events. It’s like extra fuel in the tank:
Without it, the train may start straining under the ‘tyranny of the urgent’ iteration.
#9 – Architectural Runway: Architectural Runway consists of the existing code, components and
technical infrastructure necessary to support the implementation of high priority, near-term features,
without excessive delay and redesign. Without enough investment in the architectural runway, the train
will slow down, needing to redesign for each new Feature.
#10 – Lean-Agile Leadership : For SAFe to be effective, the enterprise’s leaders and managers must take
responsibility for Lean-Agile adoption and success. Executives and managers must become Lean-Agile
leaders who are trained—and then become trainers in—these leaner ways of thinking and operating.
Without leadership taking responsibility for the implementation, the transformation will likely fail to
achieve the full benefits.
Managers Role in SAFe
1. Lead the Change
2. Manage up and across the enterprise
3. Coaching newly formed Agile teams
4. Build teams and define the mission and vision
5. Personnel and Team Development
A Lean Perspective on SAFe Portfolio WIP Limits
Epic Analysis flow: The only explicit, count-based limit in the portfolio kanban in SAFe is limiting the
number of epics permitted to be in analysis and pre-approval at any given time. SAFe recommends the
WIP constraint here is determined based on the desired epic throughput (pull rate from portfolio
backlog into implementing) and the availability of the architectural and development capacity to
perform analysis. In the past this was framed as “limited by the number of epic owners”, but this didn’t
properly represent the bottleneck.
Page 330 of 433
Portfolio backlog: While there is no explicit limit set to the portfolio backlog size, in practice it has an
implicit limit based on desired aging and investment flow characteristics. If items in the portfolio are
consistently being passed in the final cost of delay sequencing, they are candidates to be pulled out and
eliminated or passed back through the analysis flow for reconsideration and re-scoping. Remember, the
portfolio backlog is not a linear queue, instead, it is continuously reprioritized as newly approved epics
arrive.
Implementation: There is an explicit, flow-based capacity limit between the portfolio backlog active
implementation by the various trains. The limit is managed as an explicit pull system where the trains
may pull in the work at the cadenced PI boundaries if they have capacity to support it.
Forecasting and capacity recognition is done in “big round number” story points, generally
derived from reference class forecasting or relative estimation approaches performed against a
preliminary feature decomposition. Reference. Capacity may be reserved by allocating budget against
the epics, representing an explicit, cross-cutting investment decision by the executives forming the
program portfolio management team.
Portfolio Distribution: SAFe significantly simplifies the decision making around the above concerns
through the recommended budgeting approach, which explicitly allocates budget, delegated financial
authority, and scope determination to the release trains as the default approach.
This leads to a significantly reduced portion of the overall spend being managed as explicit items
in the portfolio flow. Instead, the majority of the work can flow “horizontally” at the train level without
incurring the administrative and governance overhead associated with the larger items flowing through
the portfolio backlog.
The Portfolio Kanban System flow is intended to be for portfolio epics (items that cross trains)
and/or program epics that are of sufficient size that they need explicit financial governance. Reference.
SAFe additionally provides an optional value-stream level to manage coordination of those cross-cutting
items that demand additional attention, due to the various dependencies that remain after making the
organizational structure trade-off decisions without adding the additional financial governance
overhead.
Agile Testing
Test-First’ Approach applies to all types of agile work. That includes Capabilities, features,
stories, NFRs, as well as code. It can even be applied to the hardware components of a system. The same
way tests are written during coding, acceptance tests for capabilities, features, and stories are written
during their elaboration. The just-in-time practice of elaborating the proposed system behavior also
mitigates the need for overly detailed requirement specifications and sign-offs. Even better, unlike
conventionally-written requirements, these tests are automated wherever possible. But even when they
are not, they still provide a definitive statement of what the system does, rather than a statement of
early thoughts about what it was supposed to do.
In agile testing, everyone on the team is a tester. Using Behavior-Driven Development (BDD),
Product Managers and Product Owners collaborate with their teams to create tests for features and
stories. Developers create tests for code changes using Test-Driven Development (TDD).
Benefits of Test First
Page 331 of 433
1. Multiple perspectives provide a broad view of the required system behavior and the best
approach to testing it.
2. Collaboration creates alignment across the team and a shared understanding of how to
implement the behavior.
3. It forces developers to think broadly about a change before diving into the implementation.
The SAFe Portoflio Kanban System
LPM Agenda.
Page 332 of 433
LPM Calendar
Value Stream Map
EPIC Progress Report
Workshops during the portfolio process
Page 333 of 433
Portfolio scrum team is able to analyze an Epic and provide a rough estimate. If they need more
detailed information, they talk to the responsible Product Managers or Product Owners and–if
necessary–ask them to estimate future epics or parts or variants (MVPs) in their teams’ refinement
sessions. If that isn’t enough, they could also define an analysis enabler feature to be prioritized for the
next PI of the associated ART. This makes it possible to get valid estimations of CoD and job size to
define the WSJF for the epics after a short time and with minimal effort.
The result of the analysis is to build knowledge about the business and design decisions which
can be collected in SAFe’s Solution Intent. During the preparation phase before the next PI planning, the
canvases provide a valuable foundation to refine the epics even further and split them into features.
To split the epics, we can use well-known Agile requirements engineering techniques, such as
story mapping and story splitting. Because new epics arise, and the values (especially the time criticality
value) are changing over time, we have to repeat this estimation workshop every few weeks. If the
prioritization of an epic has changed dramatically, it will be discussed in the next LPM meeting.
BDD
Behavior Driven Development (BDD) is a Test-First, Agile Testing practice that provides Built-In Quality
by defining (and potentially automating) tests before, or as part of, specifying system behavior. BDD is a
collaborative process that creates a shared understanding of requirements between the business and
the Development Team. Its goal is to help guide development, decrease rework, and increase flow.
Without focusing on internal implementation, BDD tests are business-facing scenarios that attempt to
describe the behavior of a Story, Feature, or Capability from a user’s perspective.
BDD’s goal is to express requirements in unambiguous terms, not simply to create tests. The
result may be viewed as an expression of requirements or as a test, but the result is the same.
Acceptance tests serve to record the decisions made in the conversation between the team and the
Product Owner so that the team understands the specific intended behavior.
There are three alternative labels to this detailing process:
1. Behavior Driven Design (BDD)
2. Acceptance Test–Driven Development (ATDD),
3. Specification by Example (SBE)
Design for Testability: A Vital Aspect of the System Architect Role in SAFe
Page 334 of 433
Agile testing covers two specific business perspectives: on the one hand, it offers the ability to
critique the product, thereby minimizing the impact of defects’ being delivered to the user. On the
other, it supports iterative development by providing quick feedback within a continuous integration
process.
DFT helps reduce the impact of large system scope, and affords agile teams the luxury of working with
something that is more manageable. That is why the role of a System Architect is so important in agile at
scale, but it also reflects a different motivation: instead of defining a Big Design Up-front (BDUF), agile
architect helps to establish and sustain an effective product development flow by assuring the assets
that are developed are of high quality and needn’t be revisited. This reduces the cost of delay in
development because in a system that is designed for testability, all jobs require less time.
System Architect Role and DFT
Domain Modeling
Domain Modeling is a way to describe and model real world entities and the relationships
between them, which collectively describe the problem domain space. Derived from an understanding
of system-level requirements, identifying domain entities and their relationships provides an effective
basis for understanding and helps practitioners design systems for maintainability, testability, and
incremental development. Because there is often a gap between understanding the problem domain
and the interpretation of requirements, domain modeling is a primary modeling area in Agile
development at scale. Driven in part from object-oriented design approaches, domain modeling
envisions the solution as a set of domain objects that collaborate to fulfill system-level scenarios.
In SAFe, domain modeling connects to backlog items at the Team, Program, Large Solution and
Portfolio levels and provides a common language for the entire organization. Especially important is its
connection with the Nonfunctional Requirements (NFRs) that may affect certain areas where
“alternative design approaches” are sometimes used to satisfy the corresponding NFRs.
Domain modeling also provides the Agile organization with opportunities for use of Agilefriendly design patterns and approaches that enhance velocity over the long term. As the system design
changes, refactoring and updating the domain model is vital to maintaining a continuing understanding
of the system, and goes hand in hand with code refactoring to help control the inherent complexity of
software systems.
Page 335 of 433
Common Language Used Throughout Agile Organization
Enterprise Backlog Structure and Management
What differentiates Agile at scale is the use of a hierarchical backlog structure. This mechanism
organizes the Enterprise around value delivery at all levels. Depending on the configuration selected,
SAFe uses up to 4 backlogs (full SAFe configuration):
1. Portfolio Epics are split into Capabilities
2. Capabilities are split into Features
3. Features split into Stories
Summary of Backlog Items
At the Team Level, we want to continue to execute Plan-Do-Check-Adjust (PDCA) loops within
our iterations, while also applying a regular cadence of backlog refinements to make sure stories are in a
ready state for upcoming iterations. This requires allowing ample time to review upcoming features to
determine what stories and enablers may be essential to accomplish them in the next PI.
Page 336 of 433
Executing the current PI :
Team Iteration Planning, DSUs, Iteration Demo, Iteration Retro
Parallel execution and preparation at the Program level
Preparing for the next PI :
Team Participate in refinement sessions (Feature-Story, Story-Story)
Repeat for each Iteration in the PI
Parallel execution and preparation activities at the Large Solution level
Page 337 of 433
Implementation Strategies for Business Epics
Business epics are large initiatives in SAFe that drive business value and typically cross the
organizational boundaries (release trains), time boundaries (PIs), or both. It is a key capability of the
agile enterprise to properly analyze and sequence business epics for implementation. While it’s easy to
think of epics as big, binary, monolithic, committed blobs of work, the reality is they should be
implemented incrementally to achieve the benefits of agility. Epics are defined as a single whole, but
each epic undergoes incremental implementation.
Program Epic – an initiative that is constrained to a single program.
Portfolio Epic – involves more than one program.
In SAFe, epics go through the Kanban system where the necessary research and analysis
activities are conducted, and a go/no-go decision is eventually made. During analysis, a lean business
case is being developed for each epic, which among other aspects contains a description of the
implementation strategy for the epic. This strategy is a bridge from the centralized decision regarding
the epic into its decentralized implementation by programs.
Spike first. Before starting the implementation, the program runs spikes in the previous PI to learn more
about the epic prior to the next PI planning. The spikes may target different aspects of the epic: whether
or not we should implement it at all, how to implement it, what technology to use, what’s best for the
end user in terms of the functionality, etc. These research activities typically occur at the Analysis stage
in the Business Epic Kanban, are reflected in the lean business case and impact a go/no-go decision for
the epic.
Go/No-Go Business Decisions
Portfolio Epic
Business and Architecture Epics
Page 338 of 433
Organizing by Feature or Component
Features and components embody two key abstractions used to build software and systems: 1.
Features are those behaviors of the system that directly fulfill some user need
2. Components are distinguishable system parts that provide and encapsulate common functions
needed to implement features
Agile’s continuous delivery emphasizes features (and constituent stories) that solve user needs and
differentiate solutions. However, resilient large-scale systems are built out of components that provide
for separation of concerns, foster re-use, and improve testability.
System level, Continuous Integration (CI) infrastructure: Feature teams must be able to integrate the
entire system at any desirable point.
Test automation: Broad, automated regression test suites must be built and available as well.
The System Team is engaged in actively improving and supporting the CI systems and processes used by
the feature and component teams
Communities of Practice can be organized to share component-related knowledge across feature teams
Process and Tools for Portfolio Planning.
One of the key inputs to the Pre-planning session is the prioritized Portfolio Backlog. At this
point, Epics will have some Features associated with them; Epic to Feature breakdown happens at the
Analysis state in Portfolio Kanban. Those features will play the key role in the Pre-planning. The capacity
of the trains must also be known.
The process of filling out the matrix is simple:
1. Pick the next Epic in priority order from Portfolio Backlog and put it in the next available slot in
the top row
2. Place the child Features underneath the Epic in the rows where they belong
3. Calculate and enter total Feature scope for the Epic in normalized story points
4. Update the “Load” for each train and check whether it remains within the allocated capacity
limits for Portfolio Epics.
5. Repeat…
Page 339 of 433
Refactoring
Refactoring is the activity of improving the internal structure or operation of a code or
component without changing its external behavior.
1. Keep adding new functionality to an existing code base toward an eventually unmaintainable
“throw-away” state
2. Continuously modify the system to provide a foundation for efficiently delivering not just the
current business value but future business value as well.
Demonstrating Refactoring.
1. Reduced processing time on a few web pages, compared to the previous benchmark
2. Dependency of processing time on the size of the batch, which can be configured from the file
3. A code snippet for asynchronous processing
4. The debug log file that captures all the operations
5. The number of queries to dictionaries per batch (from the log file)
Right-Sizing Features for SAFe Program Increments
Features are visible ‘units’ of business intent that the customer recognizes, and it’s at this level
of detail that the customer is able to prioritize their needs. Features may span multiple user roles,
stories and use cases. Multiple teams may work on the same feature, swarming together to deliver them
quickly.
Splitting Stories vs. Slicing Features
There is another important difference between splitting stories and slicing features. When we
split a story, it usually results in a set of similarly sized new stories that completely replace the original
story. when slicing features, we usually just find the most important slices and leave the rest to be
addressed later.
Good Feature Slicing:
1. KISS Design Principle. Keep it simple, stupid
2. Defer Optional Behavior
3. Separate Business Variations
4. Separate Different Channels
5. Address Different User Groups Individually
6. Consider Incrementally Sourcing Data
Page 340 of 433
7.
8.
9.
10.
Isolate Special Variations.
Break Out Common Enablers
Find a Story Group
Break Out a Spike.
Bad Feature Slicing
1. Deferring Nonfunctional Requirements
2. Creating Feature Debt
3. Slicing Too Early
4. Over-slicing
5. Slicing by operation or workflow step.
6. Slicing by Component
7. Forgetting Feature-level Testing
SAFe Requirement Model
Six SAFe Practices for S-Sized Teams
1. Strategic Themes
2. Program Epics
3. Program Kanban
4. Features
5. PI Planning
6. Innovation and Planning Iteration
Where to Use Safe.
1. A strategic software product with a long lifespan
2. Dependencies with multiple non-software development teams
3. The necessity to invest in long-term capabilities like DevOps
Page 341 of 433
4. Expectation to scale from S to M size
Test Driven Development
The Role of PI Objectives
The ability to
1. Validate understanding of the intent
2. Focus alignment on outcomes rather than process
3. Summarize data into meaningful and steerable information