Acceptance criteria are used to determine whether the implementation is correct and delivers the business benefits. Acceptance criteria mitigate implementation risk and enable early validation of the benefit hypothesis by creating alignment between product management, stakeholders, and developers. Acceptance criteria can also be used as the source of stories. Product Management is responsible for accepting the features. They use acceptance criteria to determine whether the functionality is properly implemented and nonfunctional requirements met.

Agile Manifesto

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated invdividuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The Agile Release Train (ART) is a long-lived team of Agile teams, which, along with other stakeholders, incrementally develops, delivers, and where applicable operates, one or more solutions in a value stream.

Agile Release Trains align teams to a shared business and technology mission. Each is a virtual organization (typically 50 - 125 people) that plans, commits, develops, and deploys together. ARTs are organized around the Enterprise's significant Development Value Streams and exist solely to realize the promise of that value by building Solutions that deliver benefit to the end-user.

ARTs are cross-functional and have all the capabilities—software, hardware, firmware, and other—needed to define, implement, test, deploy, release, and where applicable, operate solutions. An ART delivers a continuous flow of value.

The Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay.

Architectural Runway supports the continuous flow of value through the Continuous Delivery Pipeline, providing the necessary technical foundation for developing business initiatives and implementing new 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, a continual investment must be made to extend it by implementing Enablers. Some enablers address shortcomings with the current Solution, such as improving its performance or User Experience. Others provide foundational capabilities that will be used to support future functionality.

The Portfolio Backlog is the highest-level backlog in SAFe. It provides a holding area for upcoming business and enabler Epics intended to create and evolve a comprehensive set of Solutions.

Portfolio epics are made visible, developed, and managed through the Portfolio Kanban, where they proceed through various process states until they are approved or rejected by Lean Portfolio Management (LPM). Approved portfolio epics move to the portfolio backlog where they await implementation by one or more Agile Release Trains (ARTs) or Solution Trains.

Portfolio Epics are approved by Lean Portfolio Management

Backlogs, from top to bottom: Team (story) > Program (feature) > Solution (capability) > Portfolio (portfolio)

Also see Cards

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.

Backlogs, from top to bottom: Team (story) > Program (feature) > Solution (capability) > Portfolio (portfolio)

Also see Cards

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.

Backlogs, from top to bottom: Team (story) > Program (feature) > Solution (capability) > Portfolio (portfolio)

Also see Cards

The Team Backlog contains User Stories and Enabler Stories that originate from the Program Backlog, as well as stories that arise locally from the team's local context. It may include other work items as well, representing all the things a team needs to do to advance their portion of the system.

The Product Owner (PO) is responsible for the team backlog. Since it includes both user Stories and enablers, it's essential to allocate capacity in a way that balances investments across conflicting needs. This capacity allocation takes into account both the needs of the team and the Agile Release Train (ART).

Backlogs, from top to bottom: Team (story) > Program (feature) > Solution (capability) > Portfolio (portfolio)

Also see Cards

Lean Budget Guardrails describe the policies and practices for budgeting, spending, and governance for a specific portfolio.

SAFe provides strategies for Lean budgeting that eliminates the overhead of traditional project-based funding and cost accounting. In this model, LPM maintains appropriate levels of oversight through the allocation of value stream budgets and by applying Lean budget guardrails. This way, enterprises can have the best of both worlds: a development process that is far more responsive to market needs, along with professional and accountable management of spending.

Lean Budgets is a Lean-Agile approach to financial governance which increases throughput and productivity by reducing the overhead and costs associated with project cost accounting.

When implementing Agile at scale, many organizations quickly realize that the drive for business agility through Lean-Agile development conflicts with traditional budgeting and project cost accounting methods. As a result, moving to Lean-Agile development—and realizing the potential business benefits—is compromised, or worse, blocked entirely. To address this problem, SAFe introduces Lean Budgets as a Lean-Agile approach to financial governance.

Participatory Budgeting (PB) is the process that Lean Portfolio Management (LPM) uses to allocate the total portfolio budget to its value streams.

The Enterprise provides a portion of its total budget to each portfolio. In turn, Lean Portfolio Management (LPM) allocates the portfolio Budget to individual Value Streams. The value streams fund the people and resources needed to achieve the current Portfolio Vision and Roadmap. Empowered Agile Release Trains (ART) advance Solutions and implement Epics approved by LPM.

LPM establishes Lean Budget Guardrails to provide the right mix of investments to address both near-term opportunities and long-term strategy. These guardrails also ensure that large investments are approved and the appropriate investment level in technology, infrastructure, and maintenance. These guardrails, coupled with KPIs, promote decentralized decision-making and execution while providing the necessary oversight.

Built-In Quality practices ensure that each Solution element, at every increment, meets appropriate quality standards throughout development.

The Enterprise's ability to deliver new functionality with the shortest sustainable lead time, and adapt to rapidly changing business environments, depends on Solution quality. So, it should be no surprise that built-in quality is one of the SAFe Core Values as well as a principle of the Agile Manifesto, 'Continuous attention to technical excellence and good design enhances agility'. Built-in quality is also a core principle of the Lean-Agile Mindset, helping to avoid the cost of delays (CoDs) associated with recalls, rework, and fixing defects. SAFe's built-in quality philosophy applies systems thinking to optimize the whole system, ensuring a fast flow across the entire Development Value Stream, and makes quality everyone's job.

All teams including software, hardware, operations, product marketing, legal, security, compliance, etc. share the goals and principles of built-in quality. However, the practices will vary by discipline because their work products vary.

Definition of Done

The Definition of Done helps a team build quality in because it defines a common understanding of quality.

Definition of Done is an important way of ensuring increment of value can be considered complete. 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. An example is shown in Table 1, but each team, train, and enterprise should build their own definition. While these may be different for each ART or team, they usually share a core set of items.

Business Agility is the ability to compete and thrive in the digital age by quickly responding to market changes and emerging opportunities with innovative, digitally-enabled business solutions. Business Agility requires that everyone involved in delivering solutions—business and technology leaders, development, IT operations, legal, marketing, finance, support, compliance, security, and others—use Lean and Agile practices to continually deliver innovative, high-quality products and services faster than the competition..

The Business and Technology icon in SAFe describes how functional domains in all parts of the enterprise enable business agility by continuously exploring new ways to apply Lean-Agile principles and practices to their unique contexts.

A successful Agile and SAFe adoption affects not just development, but every part of the organization—but marketing, operations, support, finance, legal, security, compliance, and business and technology leadership. To realize Business Agility, all business and technology domains benefit by adopting a Lean-Agile mindset and discovering how their skills and practices apply to this new way of working (see Organizational Agility for more detail).

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.

Business Owners can be identified by asking the following questions:

• Who is ultimately responsible for business outcomes?
• Who can steer this ART to develop the right Solution?
• Who can speak to the technical competence of the solution now and into the near future?
• Who should participate in planning, help eliminate impediments, and speak on behalf of development, the business, and the customer?
• Who can approve and defend a set of Program Increment (PI) plans, knowing full well that they will never satisfy everyone?
• Who can help coordinate the efforts with other departments and organizations within the Enterprise?

The answers to these questions will identify the Business Owners, who will play a key role in helping the ART deliver value. Among other duties, they have specific responsibilities during PI Planning, where they participate in mission setting, planning, draft plan reviews, conducting management reviews, and problem-solving. They also assign business value to Team PI Objectives and approve the PI plan. But they don't just disappear after planning. Active and continuous involvement throughout each PI by Business Owners is a determining factor in the success of each train.

Assigning business value during PI planning provides an essential face-to-face dialogue between the team and their most important stakeholders, the Business Owners.

When assigning business value, on a scale of 1 to 10, Business Owners will typically assign the user-facing Features the highest values. But they also should seek the advice of technical experts who know that architectural and other concerns will increase the team's velocity in producing future business value. So placing suitable business value on Enablers helps drive velocity and shows support for the team's legitimate technical challenges.

Assigning business value during PI planning provides an essential face-to-face dialogue between the team and their most important stakeholders, the Business Owners. This is an opportunity to develop personal relationships between Agile teams and Business Owners, identify common concerns which require mutual commitment, and to better understand the business objectives and their value. An example of a team's PI objectives with assigned business value

When assigning business value, on a scale of 1 to 10, Business Owners will typically assign the user-facing Features the highest values. But they also should seek the advice of technical experts who know that architectural and other concerns will increase the team's velocity in producing future business value. So placing suitable business value on Enablers helps drive velocity and shows support for the team's legitimate technical challenges.

Because the road after PI planning takes its inevitable twists and turns, assigning business value to objectives guides the teams in making trade-offs and minor scope adjustments. In short, it allows them to deliver the maximum possible business benefit. These numbers also later inform the Program Predictability Measure, a key indicator of program performance and reliability.

Assigning Business Value influences how teams plan the implementation.

Capabilities exhibit the same characteristics and practices as features. Capabilities may originate in the local context of the solution or occur as a result of splitting portfolio epics that may cut across more than one Value Stream. Another potential source of capabilities is the Solution Context, where some aspect of the environment may require new solution functionality.

Card Levels and their Acceptors:

• Story — Team
• Feature — Product Management
• Capability — Solution Manager
• Epic, Program — Lean Portfolio Management
• Epic, Solution — Lean Portfolio Management
• Epic — Lean Portfolio Management

Also see the Program Backlog

Communities of Practice (CoPs) are organized groups of people who have a common interest in a specific technical or business domain. They collaborate regularly to share information, improve their skills, and actively work on advancing the general knowledge of the domain.

Healthy CoPs have a culture built on professional networking, personal relationships, shared knowledge, and common skills. Combined with voluntary participation, CoPs provide knowledge workers with opportunities to experience autonomy, mastery, and purpose beyond their daily tasks on an Agile Release Train (ART).

CoPs enable practitioners to exchange knowledge and skills with people across the entire organization. This open membership offers access to a wide range of expertise to help with technical challenges, fuel continuous improvement and allows more meaningful contributions to the larger goals of the Enterprise. The result is that organizations benefit from rapid problem-solving, improved quality, cooperation across multiple domains, and increased retention of top talent.

ccording to Wenger CoPs must have three distinct traits to be considered a community of practice.

• Domain—An area of shared interest
• Practice—A shared body of knowledge, experiences, and techniques
• Community—A self-selected group of individuals who care enough about the topic to participate in regular interactions

The Continuous Delivery Pipeline (CDP) represents the workflows, activities, and automation needed to shepherd a new piece of functionality from ideation to an on-demand release of value to the end user.

The pipeline consists of four aspects: Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment (CD), and Release on Demand, each of which is described in its own article.

The first three elements of the pipeline (CE, CI, and CD) work together to support the delivery of small batches of new functionality, which are then released to fulfill market demand or meet market needs.

Throughout every PI and every iteration in the PI, continuously:

• Explore user value
• Integrate and demo value
• Continuously deploy to production
• Potentially release value whenever the business needs it

Product Owners use Feature Toggles to support a Continuous Delivery Pipeline that fully automates deployment with no manual compliance steps.

Continuous Deployment (CD) is the process that takes validated Features in a staging environment and deploys them into the production environment, where they are readied for release.

CD is the third aspect in the four-part Continuous Delivery Pipeline of Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment, and Release on Demand.

Continuous Exploration (CE) is the process that drives innovation and fosters 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.

CE is the first aspect in the four-part Continuous Delivery Pipeline of Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment, and Release on Demand.

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.

The Continuous Delivery Pipeline is comprised of Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment, and Release on Demand.

Value Stream Coordination defines how to manage dependencies and exploit the opportunities that exist only in the interconnections between value streams.

Although many value streams operate independently, cooperation among a set of Solutions can provide some portfolio level capabilities and benefits that competitors can't match To this end, Lean-Agile Leaders understand the challenge and opportunity their value streams provide. They make them as independent as possible, while simultaneously interconnecting and coordinating them with the enterprise's larger purpose.

Customers are the ultimate beneficiaries of the value of the business solutions created and maintained by the portfolio value streams. Customer centricity is a mindset and a way of doing business that focuses on creating positive experiences for the customer through the full set of products and services that the enterprise offers.

Customer-centric businesses generate greater profits, increased employee engagement, and more satisfied customers. Customer-centric governments and nonprofits create the resiliency, sustainability, and alignment needed to fulfill their mission. All customer-centric enterprises deliver whole-product solutions that are designed with a deep understanding of customer needs.

A dependency should be raised as a program risk when it must be accepted.

Design Thinking is a customer-centric development process that creates desirable products that are profitable and sustainable over their lifecycle.

It goes beyond the traditional focus on the features and functions of a proposed product. Instead, it emphasizes understanding the problem to be solved, the context in which the solution will be used, and the evolution of that solution.

Whole-product Thinking is useful during PI Planning to help ensure that the PI will deliver a Solution that is differentaited from competitive offerings.

Development value streams (DVS) are the sequence of activities needed to convert a business hypothesis into a digitally-enabled Solution. Examples include designing a medical device or geophysical satellite, or developing and deploying a software application, SaaS system, or an e-commerce web site.

As described in Principle #10, Organizing around value, the value stream concept is a critical underpinning of Lean thinking and fundamental to SAFe. There are two types of value streams described in SAFe. Operational value streams (OVS) are the sequence of activities needed to deliver a product or service to a customer. Examples include manufacturing a product, fulfilling an order, admitting and treating a medical patient, providing a loan, or delivering a professional service. This article describes development value streams (DVS), the sequence of activities teams use to develop and support the products used by operational value streams.

Systems and software developers, product managers, engineers, scientists, and IT practitioners all work in development value streams. That is where they define, build, and deploy the Solutions their Customers consume. These customers may be internal—people who are part of an Operational Value Stream. Or they may be external customers who directly consume the products and services the enterprise sells and supports.

The primary focus of the Development Value Stream is to deliver end-user value

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.

DevOps is part of the Agile Product Delivery competency of the Lean Enterprise.

DevOps is a combination of two words: development and operations. Without DevOps, there is often significant tension between those who build Solutions and those who support and maintain those solutions. SAFe enterprises implement DevOps to break down organizational silos and develop a Continuous Delivery Pipeline (CDP)—a high-performance innovation engine capable of delivering market-leading solutions at the speed of business.

Enablers can be used for any activities that support upcoming business requirements and generally fall into one of four categories:

• 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.

Enablers exist throughout the Framework and are written and prioritized to follow the same rules as their corresponding epics, capabilities, features, and stories.

• 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 Features and Capabilities—Defined by Agile Release Trains (ARTs) and Solution Trains . Since these enablers are a type of Feature or Capability, they share the same attributes, including a short phrase, benefit hypothesis and acceptance criteria. They also must be sized 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.

Product Management is expected to collaborate in planning the amount of upcoming Enabler work by establishing Capacity Allocation

The Enterprise Architect establishes a technology strategy and roadmap that enables a portfolio to support current and future business capabilities.

They drive design, engineering, reuse, application of patterns, and create Enabler Epics for the architectures that comprise the solutions in a portfolio. Relying on continuous feedback, these architects foster adaptive design, and engineering practices, and drive programs and teams to rally around a shared technical vision.

An Epic is a container for a significant Solution development initiative that captures the more substantial investments that occur within a portfolio. Due to their considerable scope and impact, epics require the definition of a Minimum Viable Product (MVP) and approval by Lean Portfolio Management (LPM) before implementation.

Portfolio epics are typically cross-cutting, typically spanning multiple value streams and Program Increments (PIs). SAFe recommends applying the Lean Startup build-measure-learn cycle for epics to accelerate the learning and development process, and to reduce risk.

Epics capture Agile Release Train initiatives that cannot be completed in a single Program Increment

Epics can be at the Program or Solution level.

The Epic Owner is responsible for working with Product and Solution Management and System Architect/Engineering to split the epic into Features or Capabilities during backlog refinement

A Program Epic is used to Align Strategic Themes to Portfolio Investments.

The purpose of a Program Epic MIGHT BE to align strategic themes to portfolio investments.

Epic Owners are responsible for coordinating portfolio Epics through the Portfolio Kanban system. They collaboratively define the epic, its Minimum Viable Product (MVP), and Lean business case, and when approved, facilitate implementation.

Epic Owner works directly with the Agile Release Train (ART) and Solution Train stakeholders to define the Features and Capabilities that realize the value of approved Epics. They may also have some responsibility for supporting the initiative as it moves downstream through the Continuous Delivery Pipeline to Release on Demand.

Agile teams use story points and 'estimating poker' to value their work. A story point is a singular number that represents a combination of qualities:

• Volume—How much is there?
• Complexity—How hard is it?
• Knowledge—What's known?
• Uncertainty—What's unknown?

Story points are relative, without a connection to any specific unit of measure. The size (effort) of each story is estimated relative to the smallest story, which is assigned a size of 'one.' A modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100) is applied that reflects the inherent uncertainty in estimating, especially large numbers (e.g., 20, 40, 100)

The Product Owner and Scrum Master participate, and support, but do NOT estimate. Neither should interfere or dictate process.

A common reason for being unable to estimate a story is a lack of Acceptance Criteria.

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 Program Increment.

All teams expected to be involved in the work should also be included in the estimation. I.e., multiple teams may be involved in Feature estimation.

Project Management can leverage Market Rhythms by adjusting the delivery of Features to better meet market needs.

• The Goal - Value
• Pillar 1 - Respect for People and Culture
• Pillar 2 - Flow
• Pillar 3 - Innovation
• Pillar 4 - Relentless Improvement
• Foundation - Leadership

The House of Lean helps Agile Teams gain a clear understanding of their Customers.

Achieving business agility and the benefits of Lean-Agile development at scale is not a trivial effort, so SAFe is not a trivial framework. Before realizing SAFe's rewards, organizations must embrace a Lean-Agile Mindset as well as understand and apply Lean-Agile principles. They must identify Value Streams and Agile Release Trains (ARTs), implement a Lean-Agile portfolio, build quality in, and establish the mechanisms for continuous value delivery and DevOps. And, of course, the culture must evolve as well.

The Innovation and Planning (IP) Iteration occurs every Program Increment (PI) and serves multiple purposes. It acts as an estimating buffer for meeting PI Objectives and provides dedicated time for innovation, continuing education, PI Planning, and Inspect and Adapt (I&A) events.

SAFe has an intense focus on continuous customer value delivery, and people are busy working on the Features they committed to during PI planning. Every Iteration counts and the teams are mostly heads down, delivering near-term value. One iteration after another, the Solution marches closer to market. The attention to solution delivery is intense and unrelenting.

Of course, a focus on one thing—delivery—can lead to a lack of focus on another—innovation. Given the constant urgency for delivery, there's a risk that the tyranny of the urgent [1] will override any opportunity to innovate. To address this, SAFe provides dedicated innovation and planning iterations which are a key aspect of the Lean Enterprise's broader innovation culture.

The continuous flow of innovation is built on the foundation of SAFe principle #9 which promotes decentralized decision-making. Some innovation starts as strategic portfolio concerns that are realized through Epics and Lean Budgets applied to value streams. In the course of building the solution to realize Epics, teams, suppliers, customers and business leaders all identify opportunities for improving the solution. The potential innovations that result can be considered an 'innovation riptide' that flows back into the structures that SAFe provides for building solutions. Smaller, less expensive innovations flow into the Program Kanban as Features while larger, more expensive innovations result in the creation of an Epic and Lean Business Case and flow into the Portfolio Kanban.

The presence of an innovation riptide is indicated by teams and Agile Release Trains turning innovations into portfolio-level strategic initiatives.

The Inspect and Adapt (I&A) is a significant event, held at the end of each Program Increment (PI), where the current state of the Solution is demonstrated and evaluated by the train. Teams then reflect and identify improvement backlog items via a structured, problem-solving workshop.

The Agile Manifesto emphasizes the importance of continuous improvement through the following principle: 'At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.'

In addition, SAFe includes 'relentless improvement' as one of the four pillars of the SAFe House of Lean as well as a dimension of the Continuous Learning Culture core competency. While opportunities to improve can and should occur continuously throughout the Program Increment (PI) (e.g., Iteration Retrospectives), applying some structure, cadence, and synchronization helps ensure that there is also time set aside to identify improvements across multiple teams and Agile Release Trains.

• I — Independent (among other stories)
• N — Negotiable (a flexible statement of intent, not a contract)
• V — Valuable (providing a valuable vertical slice to the customer)
• E — Estimable (small and negotiable)
• S — Small (fits within an iteration)
• T — Testable (understood enough to know how to test it)

Iteration Goals are a high-level summary of the business and technical goals that the Agile Team agrees to accomplish in an Iteration. They are vital to coordinating an Agile Release Train (ART) as a self-organizing, self-managing team of teams. One purpose of Iteration Goals is to help align the team members and the Product Owner to the mission.

Iteration goals provide the following benefits:

• Align team members to a common purpose
• Align teams to common Program Increment (PI) Objectives and manage dependencies
• Provide transparency and management information

Whether the teams apply Scrum or Kanban, iteration goals provide Agile teams, Agile Release Train (ART) stakeholders and management with a shared language for maintaining alignment, managing dependencies, and making necessary adjustments during the execution of the Program Increment (PI).

Preliminary Iteration Goals should be created by the Product Owner prior to Iteration Planning.

The Iteration Retrospective is a regular event where Agile Team members discuss the results of the Iteration, review their practices, and identify ways to improve.

At the end of each iteration, Agile teams that apply ScrumXP (and many teams who use Kanban) gather for an iteration retrospective. Timeboxed to an hour or less, each retrospective seeks to uncover what's working well, what isn't, and what the team can do better next time.

Each retrospective yields both quantitative and qualitative insights. The quantitative review gathers and evaluates any metrics the team is using to measure its performance. The qualitative part discusses the team practices and the specific challenges that occurred during the last iteration or two. When issues have been identified, root cause analysis is performed, potential corrective actions are discussed, and improvement Stories are entered into the Team Backlog.

• Keep the event timeboxed to an hour or less. Remember, it is repeated every iteration. The goal is to make small, continuous improvement steps.
• Pick only one or two things that can be done better next time and add them as improvement stories to the team backlog, targeted for the next iteration. The other opportunities for improvement can always be addressed in future iterations if they continue to surface in retrospectives.
• Make sure everyone speaks.
• The Scrum Master should spend time preparing the retrospective, as it's a primary vehicle for improvement.
• Focus on items the team can address, not on how others can improve.
• To show progress, make sure improvement stories from the previous iteration are discussed either at the Iteration Review or the beginning of the quantitative review.
• The retrospective is a private event for the team and should be limited to Agile team members only.

The Iteration Retrospective event supports Relentless Improvement < Inspect and Adapt is wrong because it is not an 'event.'

During the Iteration review, each Agile Team measures and then demonstrates its progress by showing working stories to the Product Owner and other stakeholders to get their feedback. Teams demonstrate the significant new behavior and knowledge gained from the iteration's Stories, Spikes, Refactors, and Nonfunctional Requirements (NFRs). The preparation for the iteration review begins during Iteration Planning, where teams start thinking about how they will demo the stories to which they have committed. 'Beginning with the end in mind' facilitates iteration planning and alignment, fostering a more thorough understanding of the functionality needed, ahead of iteration execution.

Attendees at the iteration review include:

• The Agile team, which includes the Product Owner and the Scrum Master
• Stakeholders who want to see the team's progress, which may also include other teams.

Not the same thing as a System Demo

Iterations are the basic building block of Agile development. Each iteration is a standard, fixed-length timebox, where Agile Teams deliver incremental value in the form of working, tested software and systems. The recommended duration of the timebox is two weeks. However, one to four weeks is acceptable, depending on the business context.

Iterations provide a regular, predictable cadence for teams to produce an increment of value, as well as to refine those previously developed. These short time periods help the team, Product Owners, Product Managers, and other stakeholders regularly test and evaluate the technical and business hypotheses in a working system. Each iteration anchors an integration point, a 'pull event' that assembles various system aspects—functionality, quality, alignment, and fitness for use—across all the teams' contributions.

The Portfolio Kanban system is a method to visualize and manage the flow of portfolio Epics, from ideation through analysis, implementation, and completion.

• helps match demand to capacity based on Work in Process (WIP) limits
• helps identify opportunities for relentless improvement by visualizing bottlenecks in each process state
• facilitates flow with policies governing the entry and exit of work items in each state

The portfolio Kanban is particularly important in that it helps align strategy and execution by identifying, communicating, and governing the selection of the largest and most strategic initiatives (Epics) for a SAFe portfolio. The portfolio Kanban is operated under the auspices of Lean Portfolio Management who use the strategic portfolio review and portfolio sync events to manage and monitor the flow of work.

Team Kanban is a method that helps teams facilitate the flow of value by visualizing workflow, establishing Work In Process (WIP) limits, measuring throughput, and continuously improving their process.

SAFe teams have a choice of Agile methods. Most use Scrum, a lightweight, and popular framework for managing work. Teams that develop new code also apply Extreme Programming (XP) practices to bring focus to Agile software engineering (see the Technical Agility section of Team and Technical Agility) and code quality (see the Code Quality section of Built-In Quality). Some teams, however—particularly System Teams, operations, maintenance and support teams—choose to apply Kanban as their primary method. In these contexts, the rapid-fire nature of the work, the fast-changing priorities, and the lower value of planning activities for the next Iteration all lead them to this choice.

Kanban systems are used at the Portfolio, Large Solution, and Essential levels of SAFe, although for different reasons. This article will describe a Kanban system well suited to Agile Teams. However, these teams are on the train, and some additional rules must apply.

Value Stream Key Performance Indicators (KPIs) are the quantifiable measures used to evaluate how a value stream is performing against its forecasted business outcomes.

Development Value Stream KPIs close the feedback loop that travels from:

• Strategic Themes through the lean budgeting process funding the value streams
• Through the Portfolio Kanban that establishes key portfolio initiatives
• Forward to measuring the business outcomes the investments were intended to create

The Lean Portfolio Management competency aligns strategy and execution by applying Lean and systems thinking approaches to strategy and investment funding, Agile portfolio operations, and governance.

It is one of the seven core competencies of the Lean Enterprise, each of which is essential to achieving Business Agility. Each core competency is supported by a specific assessment, which enables the enterprise to assess their proficiency. These core competency assessments, along with recommended improvement opportunities, are available from the Measure and Grow article.

Lean Portfolio Management describes how a SAFe portfolio is a collection of Value Streams for a specific business domain in an Enterprise. Each value stream delivers one or more Solutions that help the enterprise meet its business strategy. These value streams develop products or solutions for external customers or create solutions for internal operational value streams.

One SAFe portfolio can typically govern the entire solution set for a small-to-medium-size organization. Large enterprises often require multiple portfolios, usually for each line of business, business unit, or division.

Lean User Experience (Lean UX) design is a mindset, culture, and a process that embraces Lean-Agile 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.

The Lean-Agile Leadership competency describes how Lean-Agile Leaders drive and sustain organizational change and operational excellence by empowering individuals and teams to reach their highest potential.

They do this through leading by example; learning and modeling SAFe's Lean-Agile mindset, values, principles, and practices; and leading the change to a new way of working.

It is one of the seven core competencies of the Lean Enterprise, each of which is essential to achieving Business Agility. Each core competency is supported by a specific assessment, which enables the enterprise to assess their proficiency. These core competency assessments, along with recommended improvement opportunities, are available from the Measure and Grow article.

The Lean-Agile Mindset is the combination of beliefs, assumptions, attitudes, and actions of SAFe leaders and practitioners who embrace the concepts of the Agile Manifesto and Lean thinking. It's the personal, intellectual, and leadership foundation for adopting and applying SAFe principles and practices.

SAFe is firmly grounded in four bodies of knowledge: Lean, Agile, systems thinking, and DevOps. In fact, the genesis of SAFe was to develop guidance for enterprises on how to apply the principles and practices of Lean and Agile in the world's largest organizations. For leaders, it requires a broader and deeper Lean-Agile mindset to drive the organizational change required to adopt Lean and Agile at scale across the entire enterprise.

The Lean-Agile mindset forms the cornerstone of a new management approach and an enhanced company culture that enables Business Agility. It provides leadership with the tools needed to drive a successful SAFe transformation, helping individuals and the entire enterprise achieve their goals.

A customer journey map illustrates the experience as a user engages with a company's Operational Value Stream, products, and services. As shown in Figure 5, journey maps are powerful design thinking tools for operational value streams. They allow teams to identify ways in which the specific deliverables of one or more Development Value Streams can be improved to create a better end-to-end experience.

Story maps enable teams to understand how the stories in the team backlog support user objectives.

Understanding market rhythms and market events provide critical insights into building roadmaps:

• A market rhythm is a set of events that occur periodically on a predictable cadence. For example, retailers routinely prepare for the holiday shopping season by upgrading their systems to get a competitive edge and support significantly higher transaction volumes.
• A market event is a one-time future event, which has a high probability of materially affecting one or more solutions. Market events can be external, such as the launch of government regulations, or they can be internally created, such as a company's annual user conference.

Project Management can leverage Market Rhythms by adjusting the delivery of Features to better meet market needs.

Measure and Grow is the way portfolios evaluate their progress towards business agility and determine their next improvement steps.

The Lean-Agile transformation and the journey to Business Agility is a major undertaking for every enterprise. Many executives have commented that this transformation was one of the most difficult—but the single most rewarding—change that they have personally experienced in their entire careers.

The business benefits of business agility are clear: faster time to market for more innovative solutions; higher quality and productivity; higher levels of employee engagement; opportunity for a new and enhanced culture, and ultimately, the ability to thrive in the digital age. But for those new to the endeavor, the question naturally arises as to where and how to begin. That is the purpose of the SAFe Implementation Roadmap, a proven pattern that has been shown to work in enterprises around the world. And yet, even when moving down the roadmap, the question for the enterprise becomes: How do we know how we are doing? Are we growing in the right areas? What do we do about the deficiencies we know we have? Where should we target our next effort?

To reinforce and accelerate the SAFe transformation, leaders need to 'measure and grow' the implementation at various points along the journey. This will help maintain the energy and enthusiasm they are devoting to the short cycles of Iterations and Program Increments (PIs) while setting their sights on the larger goals of true business agility.

The three measurement domains are defined as follows:

• Outcomes: Do our solutions meet the needs of our customers and the business?
  • KPIs
• Flow: How efficient is the organization at delivering value to the customer?
  • Flow Distribution
  • Flow Velocity
  • Flow Time
  • Flow Load
  • Flow Efficiency
  • Flow Predictability
  • Iteration Goals
  • PI Objectives
• Competency: How proficient is the organization in the practices that enable business agility?
  • Team and Technical Agility
  • Agile Product Delivery
  • Enterprise Solution Delivery
  • Lean Portfolio Management
  • Organizational Agility
  • Continuous Learning Culture
  • Lean-Agile Leadership

Milestones are used to track progress toward a specific goal or event. There are three types of SAFe milestones: Program Increment (PI), fixed-date, and learning milestones.

Milestones mark specific progress points on the development timeline, and they can be invaluable in measuring and monitoring the product evolution and risk. In the past, many progress milestones were based on phase-gate activities. In SAFe, however, progress milestones are better indicated by the fixed cadence of Iterations and Program Increments (PIs).

Planning in SAFe often takes into account three different types of milestones:

• PI milestones—These support the ability to objectively evaluate progress towards the technical or business hypothesis. These occur on the PI cadence.
• Fixed-date milestones—Not everything, however, occurs on cadence. System building also relies on external events, third-party deliverables, and external constraints. These are often fixed-date milestones that are distinct from the development cadence.
• Learning milestones—In addition, learning milestones help validate business opportunities and hypotheses.

Nonfunctional Requirements (NFRs) define system attributes such as security, reliability, performance, maintainability, scalability, and usability. They serve as constraints or restrictions on the design of the system across the different backlogs

Also known as system qualities, nonfunctional requirements are just as critical as functional Epics, Capabilities, Features, and Stories. They ensure the usability and effectiveness of the entire system. Failing to meet any one of them can result in systems that fail to satisfy internal business, user, or market needs, or that do not fulfill mandatory requirements imposed by regulatory or standards agencies. In some cases, non-compliance can cause significant legal issues (privacy, security, safety, to name a few).

NFRs are persistent qualities and constraints that, unlike functional requirements, are typically revisited as part of the Definition of Done (DoD) for each Iteration, Program Increment (PI), or release. NFRs influence all backlogs: Team, Program, Solution, and Portfolio.

Proper definition and implementation of NFRs is critical. Over-specify them, and the solution may be too costly to be viable; under-specify or underachieve them, and the system will be inadequate for its intended use. An adaptive and incremental approach to exploring, defining, and implementing NFRs is a vital skill for Agile teams

NFRs are not themselves backlog items. They are constraints on development that limit some degree of design freedom for those building the system. These constraints are often defined in the acceptance criteria for multiple backlog items. For example, SAML-based Single Sign-on (SSO) is a requirement for all products in the suite. SSO is a functional requirement, while SAML is a constraint. And any backlog item building sign-on functionality would reference the SAML constraint in its acceptance criteria.

Operational value streams (OVS) are the sequence of activities needed to deliver a product or service to a customer.

• All the steps necessary to convert the trigger to the delivery of value
• The people who perform these steps
• The systems they use to do their work
• The flow of information and materials that are necessary to satisfy that request

The primary focus of the Operational Value Stream is Delivering End-user Value.

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 are the things they intend to accomplish in the upcoming Program Increment (PI).

Product Management approves PI Objectives.

These provide several benefits:

• Provide a common language for communicating with business and technology stakeholders
• Creates the near-term focus and vision
• Enables the ART to assess its performance and the business value achieved via the Program Predictability Measure
• Communicates and highlights each team's contribution to business value
• Exposes dependencies that require coordination

Other facts:

• More than one team may be involved in estimating
• Product Management owns Features
• System Architect/Engineering owns Enablers

A benefit of Program Increment (PI) Objectives is to promote Business Agility by giving teams options on how they might deliver Features.

Program Increment (PI) Planning is a cadence-based, face-to-face event that serves as the heartbeat of the Agile Release Train (ART), aligning all the teams on the ART to a shared mission and Vision. PI planning is essential to SAFe: If you are not doing it, you are not doing SAFe.

PI planning delivers many business benefits, including:

• Establishing face-to-face communication across all team members and stakeholders
• Building the social network the ART depends upon
• Aligning development to business goals with the business context, vision, and Team and Program PI objectives
• Identifying dependencies and fostering cross-team and cross-ART collaboration
• Providing the opportunity for 'just the right amount' of architecture and Lean User Experience (UX) guidance
• Matching demand to capacity and eliminating excess Work in Process (WIP)
• Fast decision-making

Inputs to PI planning (provided by Product Management) include:

• Business context
• Roadmap and vision
• Top 10 Features of the Program Backlog < ties back to vision

Outputs:

• Committed PI objectives—A set of SMART objectives that are created by each team with the business value assigned by the Business Owners.
• Program board—Highlighting the new feature delivery dates, feature dependencies among teams and relevant Milestones.

The Product Owner primarily coordinates with:

• Agile Team
• Other Product Owners
• Product Management

The Product Owner should move stories to the team that reduces dependencies.

The Udemy test says a business must depend on the team's commitment to the plan in order to do any meaningful planning. This is probably true because you can't plan if you can't count on work getting done on time.

Communicating the vison to the ART during PI Planning supports the Core Value of Alignment

Effective road mapping efforts require an understanding of the appropriate time horizon. If the horizon is too short, the enterprise may jeopardize alignment and the ability to communicate new future Features and Capabilities. Too long, and the enterprise is basing assumptions and commitments on an uncertain future. Multiple planning horizons provide a balance. The outer levels of the planning horizon are longer-term and describe behavior that is less defined and less committed, while the inner levels are nearer-term, defining better understood and more committed solution behavior.

• Daily plan: Each day the team holds a Daily Stand-up (DSU) event to synchronize team members, review progress, identify bottlenecks, and discuss 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 a small number of future PIs. It provides a forecast of the deliverables and milestones for the next two to three PIs. For the outlying PIs, these may be indicated as Features, Epics, and Milestones.
• Solution roadmap: The solution roadmap provides a longer-term—often multiyear—view, showing the key milestones and deliverables needed to achieve the solution vision over time. While most solutions require a 1-3 year view, some larger solutions may extend this timeframe to many years.
• Portfolio roadmap: Like the solution roadmap, the portfolio roadmap provides a longer-term multiyear view. The difference in the portfolio roadmap is that it illustrates the plan to achieve the portfolio vision across the value streams in the portfolio.

In a manner similar to the SoS, a PO sync is often held for Product Owners and Product Management and other interested Stakeholders. This event typically occurs weekly, or more frequently, as needed. The PO sync is also timeboxed (30 — 60 minutes) and is followed by a meet after to solve any problems.

The PO sync may be facilitated by the RTE or a Product Manager. The purpose is to get visibility into how well the ART is progressing toward meeting its PI objectives, to discuss problems or opportunities with Feature development, and to assess any scope adjustments. The event may also be used to prepare for the next PI (see below) and may include Program Backlog refinement and Weighted Shortest Job First (WSJF) prioritization ahead of the next PI planning event.

(Note: Sometimes the SoS and PO sync are combined into one event, referred to as an ART sync.)

The SAFe portfolio canvas (Figure 2) is based on the Business Model Canvas (see this topic in the Enterprise article) developed by Alexander Osterwalder. The portfolio canvas defines the Development Value Streams that are included in a SAFe portfolio, the value propositions and the Solutions they deliver, the customers they serve, the budgets allocated to each value stream, and other key activities and events required to achieve the portfolio vision.

Portfolio SAFe aligns strategy with execution and organizes solution development around the flow of value through one or more value streams.

The portfolio configuration, which includes Essential SAFe, is the smallest configuration that can be used to achieve Business Agility and consists of the following:

• Three additional core competencies:
• The Lean Portfolio Management competency aligns strategy and execution by applying Lean and systems thinking approaches to strategy and investment funding, Agile portfolio operations, and governance
• The Continuous Learning Culture competency describes a set of values and practices that encourage individuals—and the enterprise as a whole—to continually increase knowledge, competence, performance, and innovation
• The Organizational Agility competency describes how Lean-thinking people and Agile teams optimize their business processes, evolve strategy with clear and decisive new commitments, and quickly adapt the organization as needed to capitalize on new opportunities
• The portfolio level roles, events, and artifacts
• The full spanning palette

For addressing systemic problems, a structured, root-cause problem-solving workshop is held by the ART. Root cause analysis provides a set of problem-solving tools used to identify the actual causes of a problem, rather than just addressing the symptoms. The session is typically facilitated by the RTE, in a timebox of two hours or less.

Problem-solving Workshops make improvements actionable through backlog items for the next Program Increment

Product Management is responsible for defining and supporting the building of desirable, feasible, viable, and sustainable products that meet customer needs over the product-market lifecycle.

To do this, they collaborate with a wide range of people to identify and define customer needs, understand the Solution Context, and develop the Program Vision, Roadmap, and Features required to meet these needs. Then, they support the Agile Release Trains (ARTs) in delivering value through the Program Kanban and Continuous Delivery Pipeline.

The primary responsibilities of product management fall into four main areas:

• Meet business goals—Products and solutions must meet the economic business goals established by the portfolio
• Get it built—Product Managers collaborate with Agile Release Trains (ARTs) and Solution Trains to build the required functionality
• Get it off the shelf—Internally, Product Managers collaborate with IT to ensure solutions are deployed to internal customers and users; externally, Product Managers collaborate with an even larger set of business stakeholders to deliver products to the market
• Leverage support—Product Managers ensure their offerings are supported and enhanced to create a continuous flow of value.

Product Management is responsible for defining the Program Backlog.

Product Management provides the ART Context and Vision during PI Planning.

Project Management can leverage Market Rhythms by adjusting the delivery of Features to better meet market needs.

The Product Owner (PO) is a member of the Agile Team responsible for defining Stories and prioritizing the Team Backlog to streamline the execution of program priorities while maintaining the conceptual and technical integrity of the Features or components for the team.

The PO has a significant role in maximizing the value produced by the team and ensuring Stories meet the user's needs and comply with the Definition of Done. For most enterprises moving to Agile, this is a new and critical role, typically translating into a full-time job, requiring one PO to support each Agile team (or, at most, two teams).

This role has significant relationships and responsibilities outside the local team, including working with Product Management, Customers, Business Owners, and other stakeholders.

Responsibilities:

• Defining Stories
• Prioritzing Team Backlog
• PI Planning Prep and Participation
• Iteration Planning
• Just-in-time story elaboration
• BDD
• Accepting Stories
• Understand Enabler Work
• Participate in Demo
• Participate in Retrospective

A Program Increment (PI) is a timebox during which an Agile Release Train (ART) delivers incremental value in the form of working, tested software and systems. PIs are typically 8—12 weeks long. The most common pattern for a PI is four development Iterations, followed by one Innovation and Planning (IP) Iteration.

A PI is to an Agile Release Train (ART) (or Solution Train), as an Iteration is to the Agile Team. It's a fixed timebox for planning, building, and validating a full system increment, demonstrating value, and getting fast feedback. Each PI applies cadence and synchronization to:

• Plan the ART's next increment of work
• Limit work in process (WIP)
• Summarize newsworthy value for feedback
• Assure consistent, ART wide retrospectives

Assigning Business Value to a Team's PI Objectives Influences how teams plan the implementation.

Due to its scope, the PI provides an appropriate timebox for Portfolio Level considerations and 'roadmapping.'

Release on Demand is the process that deploys new functionality into production and releases it immediately or incrementally to customers based on demand.

Release on Demand is the final aspect in the four-part Continuous Delivery Pipeline of Continuous Exploration (CE), Continuous Integration (CI), Continuous Deployment, and Release on Demand.

Four practices associated Release on Demand:

• Release describes the practices necessary to deliver the solution to end users, all at once or incrementally
• Stabilize and operate describes the practices needed to make sure the solution is working well from a functional and non-functional perspective
• Measure describes the practices necessary to quantify whether the newly-released functionality provides the intended value
• Learn describes the practices needed to decide what should be done with the information gathered and prepare for the next loop through the continuous delivery pipeline

Four practices contribute to the ability to release:

• 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.
• 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.
• Decoupled release elements—This technique identifies specific release elements, each of which can be released independently. Even simple solutions will have multiple release elements, each operating with different release strategies.

During planning, teams have identified program risks and impediments that could impact their ability to meet their objectives. These are resolved in a broader management context in front of the whole train. One by one, the risks are discussed and addressed with honesty and transparency, and then categorized into one of the following categories:

• Resolved: The teams agree that the risk is no longer a concern.
• Owned: Someone on the train takes ownership of the risk since it cannot be resolved during PI planning.
• Accepted: Some risks are just facts or potential problems that must be understood and accepted.
• Mitigated: Teams identify a plan to reduce the impact of the risk.

A dependency should be raised as a program risk when it must be accepted.

The Roadmap is a schedule of events and Milestones that communicate planned Solution deliverables over a planning horizon.

Roadmaps are the glue that link strategy to tactics. They provide all stakeholders with a view of the current, near-term, and longer-term deliverables that realize some portion of the Portfolio Vision and Strategic Themes. SAFe defines three types of roadmaps: A near-term PI roadmap, a longer-term solution roadmap, and a portfolio 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 the key milestones and deliverables needed to achieve the solution Vision over time. The portfolio roadmap shows an aggregated multi-year view of how the portfolio vision will be achieved across all the portfolio's Value Streams.

In addition to these three roadmaps, other planning elements include daily plans, Iteration plans, and PI plans.

Useful in forecasting future feature releases.

Also known as the Solution Roadmap

The Release Train Engineer (RTE) is a servant leader and coach for the Agile Release Train (ART). The RTE's major responsibilities are to facilitate the ART events and processes and assist the teams in delivering value. RTEs communicate with stakeholders, escalate impediments, help manage risk, and drive relentless improvement.

Although Agile Release Trains (ARTs) are composed of self-organizing and self-managing teams, trains don't drive or steer themselves on autopilot. That responsibility falls to the RTE, who operate most effectively as servant leaders. They have a solid grasp of how to scale Lean and Agile practices and understand the unique opportunities and challenges associated with facilitating and continuously aligning a large development program.

1. Take an economic view
2. Apply System Thinking
3. Assume variability; reserve options
4. build incrementally with fast, integrated learning cycles
5. Base milestones on objective evaluation of working systems
6. Visualize and limit WIP, reduce batch sizes, and manage queue length
7. Apply cadence, synchronize with cross-domain planning
8. Unlock the intrinsic motivation of knolledge workers
9. Decentralize decision-making
10. Organize around value

As outlined in the Implementation Roadmap series, changing the development practices and behavior of an enterprise is a significant challenge. To achieve meaningful and lasting change, author John P. Kotter notes that a 'sufficiently powerful guiding coalition' of stakeholders is needed. Such a coalition requires:

• Leaders who can set the vision, show the way, and remove impediments
• Practitioners, managers, and change agents who can implement specific process changes
• Sufficient organizational credibility to be taken seriously
• The expertise needed to make fast, intelligent decisions

Scrum Masters are servant leaders and coaches for an Agile Team. They help educate the team in Scrum, Extreme Programming (XP), Kanban, and SAFe, ensuring that the agreed Agile process is being followed. They also help remove impediments and foster an environment for high-performing team dynamics, continuous flow, and relentless improvement.

The Scrum Master role is taken by a team member whose primary responsibility is assisting the self-organizing, self-managing team to achieve its goals. Scrum Masters do this by teaching and coaching team practices, implementing and supporting SAFe principles and practices, identifying and eliminating impediments, and facilitating flow. They also work with the extended Scrum Master community, including Release Train Engineers and Solution Train Engineers, to increase the effectiveness of SAFe across the enterprise.

An effective Scrum Master is a team-based servant leader who:

• Exhibits Lean-Agile leadership
• Supports the team rules
• Facilitates the team's progress toward team goals
• Leads team efforts in relentless improvement
• Facilitates events
• Supports the Product Owner
• Facilitates the removal of impediments
• Promotes SAFe quality practices
• Builds a high-performing team
• Responsibilities on the train
• Coordinates with other teams
• Supports SAFe adoption
• Enables organizational effectiveness
• Facilitates preparation and readiness for ART events
• Supports estimating

The Scrum Master should facilitate the team preparation for the program increment (PI) system demo.

ScrumXP is a lightweight process to deliver value for cross-functional, self-organized teams within SAFe. It combines the power of Scrum project management practices with Extreme Programming (XP) practices.

ScrumXP details the two essential characteristics of Team and Technical Agility, with Scrum providing guidance for team agility and XP for technical practices. Most Agile Teams use Scrum as their primary, team-based process framework. A lightweight yet disciplined and productive process, Scrum allows cross-functional, self-organized teams to operate within the SAFe construct. It prescribes two specialty roles: Scrum Master and Product Owner. The Scrum Master is a servant leader who helps the team adhere to the rules of Scrum and works inside and outside of the team to remove impediments. The Product Owner is responsible for defining what gets built. When extended by Lean quality practices and Extreme Programming (XP) engineering techniques, the ScrumXP team provides the basic Agile building block for SAFe.

But, of course, ScrumXP teams do not work in isolation. Each is part of the larger Agile Release Train (ART), where they cooperate with other teams in building one or more Solutions.

Shared Services represents the specialty roles, people, and services required for the success of an Agile Release Train (ART) or Solution Train, but that cannot be dedicated full-time.

Because these individuals have specialized skills—often single-sourced and typically quite busy—each Agile Release Train (ART) and Solution Train must plan to engage the shared services personnel it needs, when it needs them.

Each development value stream develops one or more Solutions, which are products, services, or systems delivered to the customer, whether internal or external to the Enterprise.

All the words, pages, roles, activities, and artifacts in SAFe exist for only one purpose: to help Agile teams continuously deliver solutions that provide value to their customer. In turn, that enables customers to achieve their goals, which is the pinnacle of applying Design Thinking tools with a Customer-centric mindset.

However, even when teams and trains apply SAFe guidance and operate effectively within their disciplines, the value isn't guaranteed. After all, customers do not buy Capabilities or Features. Rather, they buy whole product solutions that deliver desired outcomes. For that reason, a solution is one of the central concepts in SAFe and requires taking a systems view regarding value delivery.

Solution Context identifies critical aspects of the operational environment for a Solution. It provides an essential understanding of requirements, usage, installation, operation, and support of the solution itself. Solution context heavily influences opportunities and constraints for releasing on demand.

Understanding Solution context is crucial to value delivery. It impacts development priorities, Solution Intent, Capabilities, Features, and Nonfunctional Requirements (NFRs). It provides opportunities, limits, and constraints for the Continuous Delivery Pipeline and other solution-level Release on Demand activities.

The solution context is often driven by factors outside the control of the organization that develops the solution. The level of coupling between the solution and its context generally represents an architectural and business challenge, that of finding the right balance between flexibility and tightly coupled interaction with the environment—interactions that often cross internal, Supplier, and Customer organizational boundaries. Product and Solution Management seek to influence the solution context in ways that benefit both the customer and the enterprise.

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 decision-making.

Strategic themes offer a way to align the business strategy of an Enterprise or Government agency with a SAFe portfolio. Working together, enterprise executives and portfolio stakeholders analyze various inputs to establish a set of strategic themes (Figure 1). These are specific, differentiated business goals that communicate aspects of strategic intent from the enterprise to the portfolio.

System Architect/Engineering is responsible for defining and communicating a shared technical and architectural vision for an Agile Release Train (ART) to help ensure the system or Solution under development is fit for its intended purpose.

System Architects describe the Solution Context and Solution Intent, analyze technical trade-offs, determine the primary components and subsystems, identify the interfaces and collaborations between them, define Nonfunctional Requirements (NFRs), guide Enablers through the Program and Solution Kanban systems, and work with Product Management, Solution Management, customers, and Suppliers to help ensure fitness for purpose.

They play a critical role in aligning teams on the Agile Release Train (ART) and Solution Train to a shared technical direction and partner with those teams in elaborating the Solution, validating technology assumptions, evaluating implementation alternatives, and creating the Continuous Delivery Pipeline. In ARTs that are not part of a Solution Train, System Architects also perform many of the activities of Solution Architect/Engineers (Solution AE).

• What they do
• Responsibilities
• How they participate in Large Value Streams

The System Demo is a significant event that provides an integrated view of new Features for the most recent Iteration delivered by all the teams in the Agile Release Train (ART). Each demo gives ART stakeholders an objective measure of progress during a Program Increment (PI).

A system demo is a critical event. It's the method for assessing the Solution's current state and gathering immediate, Agile Release Train-level feedback from the people doing the work, as well as critical feedback from Business Owners, sponsors, stakeholders, and customers. The demo is the one real measure of value, velocity, and progress of the fully integrated work across all the teams.

Planning for and presenting a useful system demo requires some work and preparation by the teams. But it's the only way to get the fast feedback needed to build the right solution.

Team Demos should NOT take the place of System Demos (also known as Iteration Reviews.) System Demos are ART-level Demos.

The Udemy test says System Architects review Enabler Stories during the System Demo. The System Demo is an Art-level demo, so it makes more sense for Capabilities to be reviewed.

In SAFe, an Agile team is a cross-functional group of 5-11 individuals who define, build, test, and deliver an increment of value in a short time box. Because communication quality diminishes as team size increases, Agile enterprises tend to prefer collections of smaller teams. For example, it's generally better to have two teams of five people than one team of ten. Solution delivery requires broad and diverse skills.

Agile teams span functions and are composed of 5-11 members from across the organization who are dedicated to their team full-time. This eliminates the hand-off and delays that pushing value through silos causes. Each Agile team has all the skills necessary to develop increments of value in a short timebox (Figure 1). They can:

• Define—Independently elaborate and design features and stories to accomplish their mission
• Build—Contain all skills necessary to create the artifacts to meet their mission
• Test—Ensure an artifact's quality and performance
• Deploy—Where applicable, deploy increments of value

Agile Team capacity allocations often include User Stories.

SAFe uses Scrum to create a safe environment for conflict to handle the 'fear of conflict' team dysfunction

The foundational issue that most often leads to deam dysfunction is Absense of Trust.

The basis for most team conflicts are assumptions that have not been discussed.

Business teams collaborate with them to provide a range of support that includes:

• Guardrails and other business parameters
• Infrastructure
• Contracts and suppliers
• End-user training
• Legal guidance
• Marketing
• Security and compliance expertise
• Fitness for use
• Solution knowledge

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.

Over time, System Teams are sometimes eliminated from an ART as the Agile teams take on these responsibilities. In larger solutions, it's more likely that specialty expertise remains with one or more System Teams, where centralizing certain people, skills, and technical assets deliver the best economic value.

Responsibilities:

• Building Development Infrastructure
• Solution Integration
• End-to-end Testing
• System and Solution Demos
• Release

Technical teams define, build, test, and-where applicable-deploy, some element of Solution value.

Stories are short descriptions of a small piece of desired functionality, written in the user's language. Agile Teams implement small, vertical slices of system functionality and are sized so they can be completed in a single Iteration.

Stories are the primary artifact used to define system behavior in Agile. They are short, simple descriptions of functionality usually told from the user's perspective and written in their language. Each one is intended to enable the implementation of a small, vertical slice of system behavior that supports incremental development.

Stories provide just enough information for both business and technical people to understand the intent. Details are deferred until the story is ready to be implemented. Through acceptance criteria and acceptance tests, stories get more specific, helping to ensure system quality.

User stories deliver functionality directly to the end user. Enabler stories bring visibility to the work items needed to support exploration, architecture, infrastructure, and compliance.

Structure of a Story:

• As a...
• I want...
• So that...

The SAFe Core Values are:

• Built-in Quality
• Transparency
• Program Execution
• Alignment

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.

The vision applies to any SAFe configuration, which explains why it's on the Spanning Palette. While its focus is typically on the solution, a portfolio vision is also clearly relevant, reflecting how Development Value Streams will cooperate to achieve the Enterprise objectives. Agile Release Trains (ARTs) and Agile Teams may also have their own vision to communicate their part in developing the solution.

Inputs:

• Customer Feedback
• Strategic Themes
• Portfolio Canvas
• Solution Context
• Solution Backlog
• Solution Intent
• Architect/Engineers
• Agile Teams
• Product Owners

Communicating the Vision supports Alignment

Before creating a Vision, Product Management needs to understand the Business Problem the Solution will solve.

The Portfolio Vision is a description of the future state of a portfolio's Value Streams and Solutions and describes how they will cooperate to achieve the portfolio's objectives and the broader aim of the Enterprise.

The portfolio vision sets a longer-term context for near-term decisions in a way that is both practical and inspirational, clearly articulating why the future state is something worth achieving. Understanding the longer-term view helps Agile Teams, Agile Release Trains, and Solution Trains make more informed choices about the development of functionality in both the short and long run.

Lean Portfolio Management (LPM) has the primary responsibility for ensuring the strategic direction of the portfolio maps to the strategic themes and enterprise strategy. This requires a clear understanding and communication of the portfolio vision. In the book Switch [1], authors Dan and Chip Heath liken this future vision to a 'destination postcard,' as Figure 1 illustrates.

Customers never purchase a 'generic' solution like a dishwasher or hotel room. Rather, they buy a specific product from a specific vendor. It's the design of this solution that determines the degree of perceived and actual value; i.e., how effectively this solution meets the customer's total needs.

Whole Product Thinking helps ensure that the products and solutions being created for customers fulfill their needs:

• The generic product is often considered the 'minimal offering' of a product. For a dishwasher, that would be the ability to wash dishes and nothing more. For a hotel, it might be a clean room and little else.
• The expected product represents the customer's minimal purchase conditions as informed by alternative or competing products. For example, a dishwasher without different cycles or a timed delay start may not meet current market expectations.
• The augmented product goes beyond what is expected and enables competitors to differentiate their offerings. A dishwasher that provides a mobile phone app to signal when the washing cycle has completed may qualify.
• The potential product represents everything that might be done to attract and keep customers. Informed by research, it fuels longer-term strategic planning and creates opportunities for sustainable product advantages.

Used during the PI Planning to ensure the PI will deliver a Solution that is differentiated from competitive offerings.

Weighted Shortest Job First (WSJF) is a prioritization model used to sequence jobs (eg., Features, Capabilities, and Epics) to produce maximum economic benefit. In SAFe, WSJF is estimated as the Cost of Delay (CoD) divided by job size.

In a flow-based system, updating priorities continuously provides the best economic outcomes. In such a flow context, it is job sequencing, rather than theoretical, individual job return on investment, that produces the best result.

To that end, SAFe applies WSJF to prioritize backlogs by calculating the relative Cost of Delay (CoD) and job size (a proxy for the duration). Backlog priorities are continuously updated based on relative user and business value, time factors, risk reduction and opportunity enablement, and relative job size. WSJF also conveniently and automatically ignores sunk costs, a fundamental principle of Lean economics.

CD = BV + TC + RR/OE

WSJF = CoD / JS