Agile Release Train

Principle of Alignment: There is more value created with overall alignment than local excellence.

—Don Reinertsen

Agile Release Train Abstract

The Agile Release Train (ART) is the primary value delivery construct in SAFe. Each ART is a long-lived, self-organizing team of Agile Teams, a virtual organization (5 – 12 teams) that plans, commits, and executes together. ARTs are organized around the enterprise’s significant Value Streams and live solely to realize the promise of that value by building solutions that deliver benefit to the end user.

The ART aligns teams to a common mission via a single Vision, Roadmap, and Program Backlog. Program Increments (PIs) provide a development timebox (default 10 weeks) that uses cadence and synchronization to facilitate planning, limit WIP, provide for aggregation of newsworthy value, and assure consistent retrospectives. PI timeboxes also provide a quantum unit of thinking for Portfolio Level consideration and roadmapping. Each train has the dedicated people and resources necessary to continuously define, build, and test valuable and evaluable capabilities in every Iteration. Trains provide architectural, engineering, and User Experience guidance to help teams build systems that support current and upcoming user and business needs.


SAFe Program Level teams, roles, and activities are organized around an Agile Release Train, a team of Agile Teams that delivers a continuous flow of incremental releases of value in a Value Stream.

Development of the Solution occurs on a standard cadence, but train teams can release at any time, as described in Develop on Cadence, Release Any Time. With respect to development cadence, the Big Picture illustrates a PI Planning session followed by four development Iterations and concludes with one Innovation and Planning (IP) iteration. SAFe calls this timebox a Program Increment.

This PI cadence, as illustrated on the Big Picture, is suggestive but arbitrary, and there is no fixed rule for how many iterations are in a PI, nor for how much time should be reserved for IP iterations. Many Enterprises choose to release software on the PI boundary, but releasing can also be independent of this cadence; it is left to the judgment of each train and/or value stream. Moreover, for larger systems, releasing is not an all-or-nothing event, and different parts of the solution (subsystems, services, etc.) can be released at different times, as described in Release.

Empowering individual teams to focus on rapid value delivery unlocks the raw energy, intrinsic motivation, and innovation that can be constrained by command-and-control models. However, that alone is not enough, as the teams will naturally tend toward local optimization. Teams will do what they can to deliver requirements to their Customer constituency, but it is hard for them to take a global view. But since the highest benefit comes from global optimization, the ART helps teams align to a common direction and achieve far more force to address global targets of opportunity.

Key Concepts

The “Agile Release Train” metaphor is used to communicate several key concepts:

  • The train departs the station and arrives at the next destination on a reliable schedule, which provides for fixed cadence, standard ART velocity, and predictable planning (and in many cases, cadence-based releases).
  • All “cargo,” including prototypes, models, software, hardware, documentation, etc., goes on the train.
  • Most people needed on the train are dedicated full-time, no matter what their functional reporting structure might be. If you want to participate, you need to be on the train.

The ART aligns the teams and helps manage risk and variability by providing cadence and synchronization. It is based on a set of common operating principles:

  • Agile Teams power the train and are cross-functional, self-organizing entities that can define, build, and test a feature or component.
  • Teams embrace and follow the principles of the Agile Manifesto and the Values and Principles of SAFe. Teams use SAFe ScrumXP, Kanban and Built-in quality practices.
  • Teams apply frequent, face-to-face, rolling wave planning.
  • PI and Iteration dates are fixed. Quality is fixed. Scope is variable.
  • Teams determine the scope via decentralized planning.
  • Teams apply common iteration lengths and standardized estimating to support ART-level estimating, planning, and integration.
  • Continuous integration is implemented across all teams on the train.
  • Every iteration, the System Demo shows integrated, ART-level, working solutions to key stakeholders.
  • Innovation and planning iterations provide a guard band for estimating and dedicated time for PI planning, innovation (e.g., hackathons, etc.), continuing education, and infrastructure work.
  • Certain infrastructure components, such as models, prototypes, and other Enablers, should typically track ahead of development.

In addition, in large value streams multiple ARTs cooperate to build larger value in the form of Solution Capabilities. In such cases, some ART stakeholders participate in value stream ceremonies including the Solution Demo and Pre- and Post PI Planning.

Agile Release Train Roles

In addition to the Agile Teams, there are a number of additional key roles:

  • The Release Train Engineer is a servant leader and operates as a full-time “Chief Scrum Master” for the train.
  • Product Management (PM) has content authority for the Program Backlog and works with Product Owners (POs) to actively manage scope and quality. At scale, a single person cannot handle both product and market strategy while also being dedicated to an Agile Team. Therefore, the “PM/PO” team steers the train together.
  • Business Owners are key stakeholders, and they are “on the train.”
  • User Experience Designers and System Architects and Engineering are responsible for defining the Architectural Runway that supports new Feature development, as well as providing guidance for common solution behaviors, shared components, and separation of concerns.
  • The System Team helps with infrastructure, assists with integration, performs ART-level testing, is capable of evaluating conformance to Nonfunctional Requirements (NFRs), and assists with the train’s system demo.
  • DevOps is integral to the train to ensure a faster flow of value to the end user. This role provides mechanisms for tighter integration of development and deployment operations.
  • Shared Services assist the train with specialty functions that cannot be dedicated to the train.

Organizing Agile Release Trains

The organization of an Agile Release Train determines who will be planning and working together, as well as what products, services, features, or components the train will deliver. Organizing Agile Release Trains is part of the “art” of SAFe, and there are many factors to consider.

Effective Train Size

One primary consideration is size. Effective Agile Release Trains typically consist of 50 – 125 people. The upper limit is based on Dunbar’s number, which suggests a limit on the number of people with whom one can form effective, stable social relationships. Larger trains occur as well, but they face larger challenges, including:

  • Logistics for program level events become more complex
  • Longer or tighter timeboxes are needed for PI planning, the system demo, and the Inspect & Adapt workshop
  • There are more dependencies to manage
  • The program backlog becomes larger, and the queue size for a program increment increases WIP (work in process)
  • Gaining and maintaining alignment to the mission becomes more difficult

So again, 50 – 125 is the most typical range of people on an ART.

The lower limit is based mostly on empirical observation of SAFe implementations in larger enterprises. However, trains with fewer than 50 people can still be very effective (the authors are part of such a train) and provide many advantages over legacy Agile practices for coordinating Agile Teams. However, smaller trains typically make adjustments to SAFe to better suit their context.

ART Organization Depends on Value Stream Size

Given the size constraints, there are three outcomes for organizing ARTs, as illustrated in Figure 1 below.

Figure 1. Organizing ARTs based upon value stream size
Figure 1. Organizing ARTs based on value stream size
  1. Multiple value streams can be realized by a single ART: This is usually the exceptional case; it tends to occur in smaller enterprises, or in enterprises that build a large number of products with a modest number of people
  2. The value stream can be realized by a single ART: This is a common case and the easiest to manage, as the ART and the value stream are one and the same
  3. The value stream is large and requires multiple ARTs: This is also quite a common case for those building systems, but additional work is required, as described below

Splitting Large Value Streams

In the larger enterprise, it is very common to have large value streams that need to be split into multiple ARTs. Splitting value streams is part technical, part art, and part social and organizational science. Below are some common patterns for splitting large value streams into ARTs:

  • By solution capabilities or feature areas (see below)
  • By subsystems (applications, components, platforms, etc.; see below)
  • By customer or market segment
  • By subsets of value: enabling flows or value stream segments
  • Other considerations may play a role:
    • Trains should be focused on a single, primary product or solution objective
    • Teams with features and components that have a high degree of interdependencies should plan and work together
    • Locale is a major consideration—wherever possible, train teams should be collocated, or at least geographic distribution should be as limited as feasible, as that simplifies planning logistics and cooperation among the teams
    • Source of funding

The design of trains requires careful consideration of the trade-offs. In general, the design of trains usually involves a combination of the various patterns above. For example: Larger value streams with multiple ARTs typically require both capabilities and subsystems. The following section discusses the trade-offs of organizing trains with these two common patterns.

Organizing trains around capabilities and subsystems

Two of the major organizational patterns for ARTs are organizing around Capabilities or organizing around subsystems, as illustrated in Figure 2 below. For example: A train can be organized around “Customer Enrollment” end-to-end functionality (capability), or, alternatively, it can be organized around mobile applications (subsystem).

  • Capability ARTs are optimized for value flow and delivery speed. They are generally preferred; however, they require additional technical governance to keep architecture from decaying and, ultimately, decreasing velocity.
  • Subsystem ARTs are optimized for architectural robustness, critical components, or components that are used by many other elements. However, they may require significant content coordination to manage dependencies, as well as prioritization of different trains to maintain a reasonable velocity.
Figure 2. ARTs can be organized Capability and/or Subsystems
Figure 2. ARTs can be organized by capabilities and/or subsystems

Organizing Teams on the Train

Once the ART boundary is established, it will be clear which Agile Teams will be involved in actually building the value. The next step, then, is for the teams to organize for the larger purpose of maximizing velocity by minimizing dependencies and handoffs, while sustaining architectural and engineering robustness and system qualities. Teams can be organized around:

  • Features: A feature team is an Agile Team that is organized around user-centered functionality. Each team is generally capable of delivering end-to-end user value. Feature teams operate primarily with User Stories, Refactors, and Spikes. However, technical stories may also occasionally occur in their backlog.
  • Components:component team is an Agile Team whose primary area of concern is restricted to a specific component or set of components. Accordingly, the team backlog typically consists of Technical Stories (as opposed to user stories), refactors, and Enabler Stories (e.g., spikes).
  • Other: Platform, architectural layer, programming language, middleware, UI, DB, business logic, spoken language, technology, location, etc.

Most ARTs have a mix of feature teams and component teams:

  • Whenever possible, lean toward feature teams, as they provide higher velocity and have fewer dependencies. They also facilitate the development of T-shaped skills, so that all team members can better flex to the work at hand.
  • Use component teams when there are high reuse opportunities, high technical specialization, and critical NFRs. But component teams should work to the principle that each component is a potentially replaceable part of the system, with well-defined interfaces. This supports modularity, separation of concerns, and ease of reuse.

ARTs should generally avoid organizing around “other” (see above), as this creates tight coupling and generally impedes flow.

Learn More

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

[2] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

[3] Gladwell, Malcolm. The Tipping Point: How Little Things Can Make a Big Difference. Little, Brown and Company, 2000.

Last update: 20 July 2016