The Agile Release Train in 60 seconds
- Definition: "a long-lived team of Agile teams that incrementally develops, delivers, and often operates one or more solutions in a development value stream."[1]
- Size: generally 50 to 125 people.[1]
- Key roles: Product Management, System Architect, Release Train Engineer and Business Owners.[1]
- Cadence: a Planning Interval of 8 to 12 weeks.[2]
- Events: PI Planning, ART Sync, System Demo, Inspect and Adapt.
What is an Agile Release Train?
An Agile Release Train (ART) is the SAFe structure for delivering value with many teams. It is a stable, cross-functional group of agile teams that share a backlog, a cadence and a mission, and that plan together every 8 to 12 weeks in PI Planning.
The train metaphor is deliberate. A train leaves on a schedule whether or not every piece of cargo is ready. Work that misses this departure catches the next one, so the schedule stays predictable and nobody holds the whole train for one feature.
Three things make an ART different from a group of teams that happen to work on the same product:
- It is long-lived. People stay together across planning intervals, so the train learns.
- It is organised around value. An ART sits inside a development value stream: "Each DVS comprises one or more Agile Release Trains."[3]
- It has everything it needs. The roles and infrastructure "to deliver fully working and tested business solutions."[4]
How big is an Agile Release Train?
SAFe states that "ARTs are generally made up of 50 to 125 people."[1] With agile teams of typically ten or fewer[5], that works out at roughly 5 to 12 teams. SAFe's Essential SAFe article, last updated in 2022, gives the range as 5 to 15 agile teams.[4]
The lower bound is about cost: below roughly 50 people, the overhead of train-level roles and events is hard to justify, and a lighter approach such as Nexus or LeSS may fit better. The upper bound is about people. Beyond about 125, PI Planning stops being a conversation and individuals stop knowing each other. When a train outgrows that, split it along a value boundary and coordinate the two with a Solution Train.
What are the roles on an Agile Release Train?
An ART is led by three roles working together, the Release Train Engineer, Product Management and the System Architect, with Business Owners as the key stakeholders. Agile teams, each with a Product Owner and a Scrum Master or Team Coach, do the work, supported by a System Team and shared services.
| Role | What SAFe says | In practice |
|---|---|---|
| Release Train Engineer | "A servant leader and ART coach who facilitates ART events and processes, and supports teams in delivering value."[5] | Runs PI Planning and the ART Sync, clears impediments, owns the train's improvement. |
| Product Management | "Responsible for defining desirable, viable, feasible, and sustainable solutions that meet customer needs."[5] | Owns the ART Backlog and its priorities.[6] A train may need more than one Product Manager.[7] |
| System Architect | "Responsible for defining and communicating a shared technical and architectural vision."[5] | Guides enablers and non-functional requirements. A train may have several.[8] |
| Business Owners | "Key ART stakeholders who have the primary business and technical responsibility for return on investment (ROI), governance, and compliance."[5] | Assign business value to PI Objectives and accept the plan. |
| Product Owner | "The Agile team member primarily responsible for maximizing the value delivered by the team."[5] | Owns the team backlog. |
| Scrum Master / Team Coach | "A servant leader and coach for an Agile team."[5] | Facilitates team events and represents the team in the Coach Sync. |
| System Team | "A specialized Agile team that assists in building and supporting the Agile development environment."[5] | Integration, environments and the delivery pipeline. |
| Shared services | "Specialty roles, people, and services required for the success of an ART... but that are not dedicated full-time."[5] | Security, UX, data, legal and similar. |
What events does an Agile Release Train run?
Four events hold an ART together: PI Planning at the start of each interval, the ART Sync during it, a System Demo every iteration, and Inspect and Adapt at the end. All run on a fixed cadence.
| Event | When | Purpose |
|---|---|---|
| PI Planning | Start of each PI | "A cadence-based event for the entire ART that aligns teams and stakeholders to a shared mission and vision."[5] |
| ART Sync | Weekly or fortnightly | Combines the PO Sync and the Coach Sync.[5] |
| Coach Sync | Within the ART Sync | "Helps coordinate ART dependencies and provides visibility into progress and impediments."[5] |
| PO Sync | Within the ART Sync | Gives "visibility into the ART's progress toward meeting its PI objectives."[5] |
| System Demo | End of each iteration | "An integrated view of new features for the most recent iteration delivered by all the teams on the ART."[5] |
| Inspect and Adapt | End of each PI | "A significant event held at the end of each PI."[5] |
What is the ART Backlog?
The ART Backlog is "a Kanban system that is used to capture and manage the features and enablers intended to enhance the solution and extend its architectural runway."[5] Product Management owns it, and it is the single source of work for the train.[6]
- Features are "solution functionality that delivers business value, fulfills a stakeholder need, and is sized to be delivered by an Agile Release Train within a PI."[5]
- Enablers "extend the architectural runway of the solution under development or improve the performance of the development value stream."[5] They come in four kinds: exploration, architecture, infrastructure and compliance.[9]
- The ART Kanban is "a method to visualize and manage the flow of features from ideation to analysis, implementation, and release."[5]
- Prioritisation is usually done with WSJF before each PI.
Older material calls these the Program Backlog and Program Kanban. The names changed with SAFe 6.0.
How do you launch an Agile Release Train?
Pick a value stream, define the train, fill the key roles, train everyone, prepare a backlog and set the cadence, then launch with the first PI Planning event. In SAFe's Implementation Roadmap, "Train Teams and Launch the ART" is the ninth of fourteen steps.[10]
- Identify the value stream and the solution the train will build.
- Define the ART: which teams, which people, which systems, and what is out of scope.
- Appoint the RTE, Product Management and System Architect and confirm the Business Owners.
- Form the teams as stable, cross-functional units of ten or fewer.
- Set the calendar: PI dates, iteration dates and every event, for a year ahead.
- Train the leaders, then the teams. SAFe recommends training teams together, noting that the big room approach "is typically three to five times more cost-effective than individual team training."[10]
- Prepare the ART Backlog with ranked, refined features.
- Set up tooling so the plan can be made and tracked in one place.
- Run the first PI Planning. That is the launch.
- Coach through the first PI and hold a real Inspect and Adapt at the end.
How do you know whether an ART is working?
A healthy ART delivers what it committed to, integrates every iteration, has stable membership and improves from one interval to the next. The clearest single indicator is predictability: business value delivered against business value planned.
- Predictability is steady and high. In SAFe the ART Predictability Measure is "an average of the achievement score for each teams on the ART for the PI."[5]
- The System Demo shows integrated, working software every iteration.
- Dependencies are known before the PI starts and mostly resolved on time.
- Scope change after PI Planning is small and explained.
- Flow metrics are improving. See the flow metrics guide.
- People stay on the train and Business Owners turn up.
Warning signs are the mirror image: a train that is a reporting line and not a team, PI Planning used to hand out pre-made plans, demos of slides, and an IP iteration that is always spent finishing features.
What happens when you have several ARTs?
Several ARTs that build one large solution are coordinated by a Solution Train, "the organizational construct used to build large solutions that requires the coordination of multiple ARTs and suppliers."[11]
The Solution Train has its own roles, including a Solution Train Engineer, and its own alignment activities before and after each PI.[12] In tooling terms you need a view above the single program board. In Kendis that is the solution board, which combines several ARTs and their cross-train dependencies.
Put this into practice, free for 6 months
Kendis is a PI Planning and tracking platform that sits on top of Jira and Azure DevOps. The free trial runs for six months, long enough to plan and track two full PIs with your real backlog before anyone has to approve a budget.
- 6 months free, no credit card
- Choose EU hosting (OVHcloud, Frankfurt) or US hosting (AWS)
- Planning board, dependencies, PI objectives, ROAM risks, solution boards
- Two-way sync with Jira Cloud, Jira Data Center and Azure DevOps
- ISO/IEC 27001 certified, GDPR compliant, DORA Schedule available
- No user caps and no setup costs during the trial
One trial per organisation that has not used Kendis in the last twelve months. After the trial, Premium Cloud is $14 per user per month billed annually, or $16 monthly, and you license only the people who plan. SSO, Kendis AI and premium support are part of paid plans. See pricing and the free trial terms.
Agile Release Train: frequently asked questions
What is an Agile Release Train in SAFe?
An Agile Release Train (ART) is a long-lived team of agile teams that incrementally develops, delivers and often operates one or more solutions in a development value stream. It plans together every 8 to 12 weeks in PI Planning.
How many people are on an Agile Release Train?
SAFe states that ARTs are generally made up of 50 to 125 people. With teams of ten or fewer, that is roughly 5 to 12 teams.
Who leads an Agile Release Train?
The Release Train Engineer, Product Management and the System Architect lead the train together. The RTE facilitates, Product Management owns the backlog and priorities, and the System Architect owns the technical vision.
What is the difference between an ART and a Scrum team?
A Scrum or agile team is typically ten or fewer people delivering in iterations. An ART is a team of those teams, usually 50 to 125 people, with shared planning, a shared backlog and train-level roles.
What are the main ART events?
PI Planning at the start of each Planning Interval, the ART Sync during it, a System Demo at the end of each iteration, and Inspect and Adapt at the end of the PI.
What is the ART Backlog?
The ART Backlog is a Kanban system used to capture and manage the features and enablers for the train. Product Management is responsible for it. It was called the Program Backlog before SAFe 6.0.
How do you launch an Agile Release Train?
Identify the value stream, define the train and its teams, appoint the key roles, set the calendar, train leaders and teams, prepare the backlog and launch with the first PI Planning event.
Sources
Every external claim in this guide links to the primary source below. All links were checked on 12 October 2026.
- Scaled Agile, Inc.. Agile Release Train.
- Scaled Agile, Inc.. Planning Interval (PI).
- Scaled Agile, Inc.. Development Value Streams.
- Scaled Agile, Inc.. Essential SAFe (last updated 30 November 2022).
- Scaled Agile, Inc.. SAFe Glossary.
- Scaled Agile, Inc.. ART and Solution Train Backlogs.
- Scaled Agile, Inc.. Product Management.
- Scaled Agile, Inc.. System Architect.
- Scaled Agile, Inc.. Enablers.
- Scaled Agile, Inc.. Train Teams and Launch the ART.
- Scaled Agile, Inc.. Solution Train (Extended Guidance).
- Scaled Agile, Inc.. Pre-Plan.
How this guide is maintained: definitions are checked against the framework pages and other primary sources listed above, and the guide is updated when terminology or guidance changes. Examples, checklists and practical advice are Kendis guidance and are not official SAFe material. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.