A system must be managed. It will not manage itself. Left to themselves, components become selfish, competitive, independent profit centers, and thus destroy the system. . . . The secret is cooperation between components toward the aim of the organization.

—W. Edwards Deming

Program Level

The Program Level 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 Solution development mission. SAFe program-level teams, roles, and activities are organized around the Agile Release Train (ART) metaphor, which delivers a continuous flow of incremental releases of value. ARTs are virtual organizations formed to span functional boundaries, eliminate unnecessary handoffs and steps, and accelerate value delivery by implementing SAFe Lean-Agile principles and practices.

Although it is called the program level, ARTs are generally very long-lived and, therefore, have a more persistent self-organization, structure, and mission than a traditional “program.” Typically, a program has a start and an end date, as well as temporarily assigned resources. The long-lived, flow-based, self-organizing nature of the ART is what powers SAFe.


The heart of SAFe is the Program Level (see Figure 1.), where Agile teams, key stakeholders, and other resources are dedicated to an important, ongoing solution mission, using a construct called the Agile Release Train (ART). The ART is a self-managing and organizing team-of-Agile-teams that plans, commits, and executes together.

Agile teams are dedicated to one, and only one Agile Release Train (ART). Each is responsible for defining, building, and testing stories from their backlog in a series of time-boxed iterations.

Each ART is composed of 5 to 12 Agile Teams (50 – 125+ people) and includes the roles and infrastructure necessary to deliver fully tested, working, system-level software. Many release trains are virtual, spanning organizational and geographic boundaries; others follow a line of business or product line management reporting structure.

Figure 1. Program Level


Below are the highlights of the program level:

  • The ART aligns management, teams, and stakeholders to a common mission through a single vision, roadmap, and program backlog
  • ARTs deliver the features (user functionality) and the enablers (technical infrastructure) needed to provide value on a sustainable basis
  • Team iterations are synchronized and use the same duration and start and end dates. Each ART delivers valuable and tested system-level increments every two weeks
  • Program Increment (PIs) provide a fixed timebox for planning, execution, and inspecting and adapting. Solutions can be released on demand, during or at the end of a PI, based solely on the needs of the business
  • Frequent or continuous integration of the work from all teams is the ultimate measure of progress.
  • ARTs use face-to-face PI planning to assure collaboration, alignment, and rapid adaptation
  • ARTs build and maintain a Continuous Delivery Pipeline, which is used to continuously develop and release small increments of value
  • ARTs provide common and consistent approaches to user experience using Lean UX principles and practices
  • DevOps – 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


Agile Release Trains are self-managing and self-organizing teams of Agile Teams that plan, commit, and execute together. However, a train does not create or steer itself. It needs guidance and direction. The program level roles help teams align to a common mission, coordinate the ARTs and provides the necessary governance:

  • System Architect/Engineer – is an individual or small cross-discipline team that truly applies systems thinking. They define the overall architecture for the system, help define nonfunctional requirements, determine the major elements and subsystems, and help define the interfaces and collaborations among them
  • Product Management – is the internal voice of the Customerand works with Product Owners and customers to understand and communicate the their needs, define system features, and participate in validation. They are responsible for the program backlog
  • Release Train Engineer (RTE) – is a servant leader and the chief Scrum Master for the ART. The RTE facilitates optimizing the flow of value through the program using various mechanisms, such as the Program Kanban, Inspect & Adapt workshop, PI Planning, and more
  • Business Owners – are a small group of stakeholders who have the primary business and technical responsibility for fitness for use, governance, and Return on Investment for a Solution developed by an (ART). They are key stakeholders on the ART and actively participate in certain ART events


The program level uses three major activities to help coordinate the ART:

  • PI Planning – a cadence-based, face-to-face planning event that serves as the heartbeat of the Agile Release Train (ART), aligning all the teams on the ART to a common mission.
  • System Demo – 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 provides ART stakeholders with an objective measure of progress during a program increment.
  • Inspect & Adapt (I&A) – is a significant event where the current state of the Solution is demonstrated and evaluated. Teams then reflect and identify improvement backlog items via a structured problem-solving workshop.


The following program level artifacts help coordinate the ART:

  • Features – is a system service that fulfills a stakeholder need. Each feature includes a benefits hypothesis and acceptance criteria, and is sized or split as necessary to be delivered by a single Agile Release Train (ART) in a single Program Increment (PI).
  • Program Epics – these epics are specifically for one ART.
  • Program Backlog – is the holding area for upcoming features and enablers, each of which can span multiple ARTs, and are intended to advance the solution and build its architectural runway.
  • Program Kanban – manages the flow of features and enablers through the ART.
  • PI Objectives – are a summarized description of the specific business and technical goals that an ART intends to achieve in the upcoming Program Increment (PI).
  • Architectural Runway – consists of the existing code, components and technical infrastructure necessary to support implementation of prioritized, near-term features, without excessive redesign and delay.

Managing the Flow of Value though the ART

A primary responsibility of the program level is the discovery, definition, and development of Features and Enablers that are required by the business to realize the Vision and Roadmap. To manage this flow of work, and to make sure it is visible to all stakeholders, SAFe provides a Program Kanban system. This system is used to ensure that features are reasoned and analysed prior to reaching the PI boundary, then are prioritized appropriately, and that acceptance criteria have been established to guide a high-fidelity implementation.

Features are maintained and prioritized in the Program Backlog. Upon implementation, they are sized to fit in a program increment such that each PI delivers new functionality with conceptual integrity. Features, in turn, lie between Stories, which are handled by a single team within an iteration, and Capabilities, which are Large Solution Level services that can span ARTs.

Connection to the Portfolio and/or Value Stream

Programs have a bidirectional connection to the value stream and/or portfolio. The program vision and roadmap provide a view of the solutions and capabilities to be developed, reflecting customer and stakeholder needs and the approaches that are proposed to address those needs.

However, in a multi-ART Solution, the development of the program vision and roadmap are not created in isolation. They are done in concert with one another and must be synchronized with the solution, typically at PI boundaries. Lean Portfolio Management and Product and Solution Management for each train collaborate on the development of the respective roadmaps and visions.

Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

Last update: 2 April, 2017