Program Level

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 Abstract

The Program Level is where development teams and other resources are applied to some important, ongoing development mission. SAFe program level teams, roles, and activities are organized around the Agile Release Train (ART) metaphor, a team of Agile Teams that delivers a continuous flow of incremental releases of value. Agile Release Trains are virtual organizations formed to span functional boundaries, eliminate unnecessary handoffs and steps, and accelerate the delivery of value via implementation of SAFe Lean-Agile principles and practices.

While 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,” which more classically has a start and an end date, as well as temporarily assigned resources. It is the long-lived, flow-based, and self-organizing nature of the ART that powers the SAFe portfolio.


Value in SAFe is delivered by long-lived Agile Release Trains, each of which realizes a portion of a Value Stream (or, in some cases, the entire value stream). They deliver value incrementally in Program Increments (PIs) of 8 to 12 week in duration; each PI is a multiple-Iteration timebox during which a significant, valuable increment of the system is developed. 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.

Managing the Flow of Value

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 analyzed 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 Value Stream Level services that can span ARTs.

Key Roles

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 so that the teams are aligned to a common mission, operate under architectural and User Experience guidance, and are assisted in delivery by a Release Train Engineer (RTE), the chief Scrum Master for the train. Figure 1 illustrates this “troika” of key roles.

Figure 1. Program Management, Content Management, and Architecture troika
Figure 1. Program management, content management, and architecture troika

These three primary functions help ensure successful execution of the vision and roadmap initiatives at the program level:

  • Program Execution – The Release Train Engineer is a servant leader and the chief Scrum Master for the train. 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.
  • Content Management – Product Management is the internal voice of the Customer and works with Customers and Product Owners to understand and communicate their needs, define system features, and participate in validation. They are responsible for the program backlog.
  • Technology – The 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.

In larger value streams, these roles also participate in Pre- and Post-PI Planning for the solution.

The Spanning Palette

There are number of additional icons indicated on this level; they are located at the conjunction of the value stream and program level on the Big Picture. This is called the “spanning palette” and is illustrated in Figure 2.

Figure 2. Spanning palette
Figure 2. Spanning palette

Each of these artifacts and roles contributes to the ART and program level, as are defined in the Vision, Roadmap, Metrics, MilestonesReleasesDevOps , System Team, Release ManagementShared Services and User Experience articles. They span the levels, because many of these artifacts are also useful at the value stream level. Clicking on the right-hand “Collapse” button on the Big Picture results in hiding the value stream level, causing the palette to appear between the portfolio and program levels and indicating that it can be useful to have some or all of these elements play a role at the portfolio level, when applicable. This is an essential part of the configurability and modularity of the framework. When it comes to these items, the SAFe Enterprise can apply all that are needed, and no more, at any of the three levels.

Connection to the Value Stream and Portfolio

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 value stream, 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. Program Portfolio Management and Product and Solution Management for each train collaborate on the development of the respective roadmaps and visions.

Mixing Traditional Programs with ARTs

In enterprises transitioning to SAFe, and in cases where supplier development practices are outside the control of the enterprise, traditional (waterfall) programs may still exist. Therefore SAFe Program Portfolio Management provides a governance model that can be applied to governing ARTs along with traditional, stage-gated programs. Guidance articles for this mixed mode of operation are provided in the Guidance section. (See the Mixing Agile and Waterfall Development article.)

Learn More

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

Last update: 15 April 2016