BY Anshuman Singh | May 26, 2017

[Total: 4   Average: 5/5]

The concept of Agile Release Train (ART) is central to understanding the constructs of SAFe® and to implement them. So, what is an ART? Is it a set of teams working in tandem with each other following a common release calendar and Sprint timeline? Or is it a set of features scheduled for release at regular durations to continuously deliver the anticipated business value? Is there any role that is central to the running of an ART? We will try to answer these questions and have a closer look at ART in this blog.

What is an ART?

The Agile Release Train (ART) is the primary value delivery construct in SAFe®. The Agile Release Train is a long lived, self-organizing team of Agile Teams, a virtual organization (5 to 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.

Hence, an ART is basically a team of Teams responsible for the regular release of Features and business benefits. All the teams of an ART are bound by a common Vision, Program Backlog, and a Roadmap. An Agile Release Train typically consist of 50-125 people. (How many ARTs are associated with a “Vision” or a “Program”? Basically, is there 1 ART per Program or can there be multiple ARTs per program?)

How is Program Increment (PI) related to ART? 

Program Increments (PIs) provide a development timebox (default 10 weeks) that uses cadence and synchronization to facilitate planning, limiting WIP, provide for aggregation of value and assure consistent retrospectives. In other words, PI timeboxes are the duration over which the ART (team of Teams) has to deliver a piece of work.  (In the case of IT and software domain, that would mean working- software).  Each train has dedicated people and resources necessary to continuously define, build and test capabilities in every iteration.

Principles governing the Agile Release Train

The Agile Release Train provides alignment and helps manage risk by providing program level cadence and synchronization. It is based on agreement and adoption of a set of common operating principles and rules which are followed by all teams who are part of the train. The rules are agreed and shared with the entire ART over a 2-day PI Planning event. To read up more on PI Planning, you can access my last blog here (Unravelling PI Planning). These rules are as follows:

  • Frequent, periodic planning and release – the ART must ensure a regular value delivery model is followed and adhered to. The system demo typically should happen every 10 weeks.
  • Teams apply common iteration lengths – within a PI there are 5 Sprints of 2 weeks each and each team adheres to the iteration length.
  • Clearly defined, objective milestones are established. The milestones for each 10-week cycle are decided over the 2 day PI Planning event by the entire ART.
  • Continuous system integration is implemented at the top, system level, as well as at the feature and component level. The work accomplished by multiple teams over the Sprint must be integrated to keep the software in a releasable state.
  • Release increments are available at regular (typically 60-120 day) intervals for customer preview, internal review, and system-level QA. This is a high-level System Demo (also called the PI Demo) event that showcases the ART team’s achievement over the entire PI timeline of 10 weeks and senior stakeholders attend this event.


Release Train Engineer

The Release Train Engineer is a servant leader and operates as a full-time ‘Chief Scrum Master’ of the train. The Release Train Engineer (RTE) tracks the Features and Capabilities release dates. The RTE conducts the PI planning events for each ART. The RTE is responsible for ensuring the required stakeholders attend the two-day event and that all the logistics for the successful completion of the event are in place. The RTE needs to have the PI Planning, Iterations and System Demo dates defined so that a holistic picture of the work being executed by an ART can be made available to the stakeholders. It is worth noting that more than 1 ART can make up a Value Stream. Also, Capabilities are broken down into Features that are linked to an ART. ARTs derive their score from the features that have been allocated to the PI. The score refers to the Business Value that an ART is supposed to deliver during the PI.

ART Milestones

The milestones listed below are adhered to by an ART and are tracked regularly.

  • PI Planned Start Date (derived from the PI)
  • PI Planned End Date (derived from the PI)
  • Sprint Planned Start Date (derived from the Sprints inside a PI)
  • Sprint Planned End Date (derived from the Sprints inside a PI)
  • PI/Sprint Planning Dates (Entered at the PI/Sprint level; derived at the ART level)
  • PI System Demo (defined during the PI Planning meeting)

An Example

To recap the concepts covered in the blog – take a look at the image below. The image depicts a Sales Value Stream that comprises of 5 ARTs. Out of these, an elaboration of ART1 is presented. ART1 delivers releases over multiple PI timeboxes. Each of the PI timeboxes comprises of multiple Sprints. In other words, PI timebox is to a Sprint what an ART is to an Agile team. Also the backlog of the PI comprises of the Features that need to be delivered in the timeboxe by the ART.

Agile Release Train

The PI level Features are broken into User Stories that form the Sprint level backlog of various teams. Each of the PI are also accompanied with a list of identified risks that were uncovered by the ART team during PI Planning meeting.

This covers the most important concepts surrounding an ART and if there are any questions please put them in the Comments section below and I will be happy to answer them.

Learn how SwiftEASe Enables Agile software Development using Scaled Agile Framework.

Notify of
Oldest Most Voted
Inline Feedbacks
View all comments

This is really good info on ART. My org is implementing release train model and the example you mentioned in the diagram fits around 80% what i followed from the presentation shared. I am from QA org and would be really happy to know how in this model QA team can be fitted and make the most of it. Currently, we are agile based where continuous development and testing happens. Its a complex product. Even all features are complete we still need to have exploratory and integration testing planned because of the scale. Please suggest your thoughts for effective QA… Read more »

Mahesh Singh

Hi Nitin – thanks for your comment and question. It would be interesting to understand how your QA team currently fits in the Agile model that your team and organization have adopted. Given the way you have described your product’s current testing cycle, it would appear that a Kanban approach would possibly work for you where you work based on your current dev and test workflow with the current dev and test team members as is, and deliver based on the PI and Sprint cadence that you are implementing. Your number of stories delivered per sprint and PI may vary,… Read more »

Amit Kaushik

Hi, Thanks for sharing the valuable info. Based on my current organization setup i have a question: what is mapping between ART and Program i.e. is it 1:1 OR 1:N OR N:N Let’s say i have an ART with 5 Agile teams in it. At any given point of time i have say 6 programs for which these agile teams will be working (all or some teams). How do we do the PI planning, do we have one PI planning for the ART OR do we do multiple PI planning (1 for each program) ? If later then agile teams… Read more »

Mahesh Singh

Hi Amit, Thanks for visiting our blog and thanks for the question. You’ve asked a great question – something that I’d also asked during my SPC class 🙂 So, conceptually, an ART handles one Program, and so one Program Increment (PI) at a time, but over a period of time handles multiple PIs. So, at an instant of time, it is a 1:1 mapping, but over time, of course, it is a 1:N (1 ART: N PIs) mapping. Now, there is nothing stopping you from having your ART members multiplexing their time over multiple Programs/ PIs at a time. However,… Read more »


Thanks for the article on SAFe. I got some good concepts from this without the site trying to sell me some bootcamp or some other nonsense. Thanks much for the information Anshuman!


HI this text in article does not make sense? ” In the image below there are 3 Features that will be delivered by ART1 in its second PI (PI2).” There are alot more features shown across all of the sprints for PI2 than 3?


Join our Family of 50000+ subscribers who receive Actionable insights on Kanban, Scaled Agile & Digital Transformation