What is a Solution Train?
A Solution Train is the SAFe structure for building one large solution with several Agile Release Trains (ARTs) and suppliers. Scaled Agile defines it as "the organizational construct used to build large solutions that requires the coordination of multiple ARTs and suppliers."[1] It adds its own roles, a shared backlog of capabilities and events that keep every train on the same plan.
A single ART can deliver a lot, but some systems are too big for one train: a medical device, a car, an aircraft, a core banking platform. Solution Trains "align multiple Agile Release Trains (ARTs) and Suppliers to a shared mission" and "help manage the inherent risk and variability of large-scale solution development."[1] The value comes from alignment across the trains, not from any one train being excellent on its own.
When do you need a Solution Train?
You need a Solution Train when one solution needs more than one ART, and often external suppliers, to deliver it. If each train can deliver its product on its own, keep the trains independent and coordinate them lightly.
Scaled Agile describes the solutions that need this construct as ones that "often have an unacceptable social or economic cost for failure" and are "often subject to industry and regulatory standards."[1] Typical signs you need one:
- One solution, several trains. A capability can only be released when work from two or more ARTs is integrated.
- Suppliers build parts of it. Internal or external organisations deliver components or subsystems to your schedule.
- Compliance needs evidence. The whole system, not each part, must show it meets standards.
- Dependencies cross trains every PI. RTEs keep discovering the same cross-ART dependencies late.
Solution Trains form in two ways: new ARTs and teams are set up for a large initiative, or existing ARTs are combined. In the second case Scaled Agile recommends quickly creating the foundations, "Solution Train Vision, Backlog, and roles," so work can reach the existing trains.[1] Large Solution SAFe is the configuration that adds these roles, events and artifacts to Essential SAFe; see the scaling agile guide for how it fits with other approaches.
Solution Train roles
Three roles lead a Solution Train: the Solution Train Engineer facilitates, Solution Management owns what is built, and the Solution Architect owns the shared technical direction. They work with the RTE, Product Management and System Architect of each ART.
Solution Train Engineer (STE)
The STE "is a servant leader and coach who facilitates Solution Train events and processes, coordinates the work of ARTs and Suppliers, and supports ARTs in delivering value."[2] The STE does for the Solution Train what the Release Train Engineer does for one ART: runs the events, keeps the flow of work visible, escalates impediments and works closely with the RTEs of every train.
Solution Management
Solution Management is "the function responsible for defining desirable, viable, feasible, and sustainable large solutions that meet customer needs and for supporting development across the solution life cycle."[3] In practice it represents the customer, owns the Solution Train Backlog, defines and prioritises capabilities, and works with Product Management in each ART to split them into features. It is usually several people, not one.
Solution Architect
The Solution Architect "is responsible for defining and communicating a shared technical and architectural vision for a Solution Train to help ensure the solution under development will be fit for its intended purpose."[4] Like Solution Management, it is often a small team that aligns the ARTs and suppliers on one technical direction and the enablers needed to support it.
Other participants
Large solutions also involve people outside the three leadership roles. Suppliers deliver components, subsystems or services. The customer, internal or external, takes part in demos and gives feedback. A system team often helps integrate and test the work of several trains, and shared specialists such as security or data experts support more than one ART. Some organisations add a release or governance group that approves content and scope for regulated releases.
Capabilities vs features
A capability is the Solution Train's backlog item: large solution behaviour that usually needs more than one ART. A feature is the ART's backlog item, sized for one train. Capabilities are split into features that individual ARTs plan in PI Planning.
Scaled Agile defines a capability as "large solution functionality whose implementation often spans multiple ARTs and is sized to be delivered within a PI," and a feature as functionality "sized to be delivered by an Agile Release Train within a PI."[5] Capabilities live in the Solution Train Backlog, "the container for upcoming capabilities and enablers, each of which can span multiple ARTs."[6]
Because one capability is delivered by several trains, its progress is the sum of features in different ART backlogs. Tracking that by hand is where most Solution Trains lose sight of what is really landing in the PI.
Solution Train vs Agile Release Train
An ART is a team of agile teams that plans and delivers together. A Solution Train is a team of ARTs and suppliers building one solution. The Solution Train mirrors the ART one level up: its own backlog, facilitator, content and architecture roles, and demo.
| Agile Release Train (ART) | Solution Train | |
|---|---|---|
| Made of | Agile teams | Several ARTs, plus suppliers |
| Builds | A product or system one train can deliver | A large solution no single train can deliver |
| Backlog item | Features, sized for one ART and one PI | Capabilities, which often span several ARTs and are split into features |
| Backlog | ART Backlog | Solution Train Backlog |
| Facilitator | Release Train Engineer (RTE) | Solution Train Engineer (STE) |
| Content and technical direction | Product Management and System Architect | Solution Management and Solution Architect |
| Planning | PI Planning for the train | Pre-Plan, then PI Planning in every ART |
| Demo | System Demo of the train's increment | Solution Demo of the integrated solution |
| Dependencies | Between teams in one train | Between trains and with suppliers |
For how a single train is set up, sized and run, read the Agile Release Train guide.
Solution Train events
A Solution Train runs on the same PI cadence as its ARTs. Leaders align the trains in Pre-Plan, each ART holds its own PI Planning, the trains coordinate during the PI, and the PI ends with a Solution Demo and Inspect and Adapt.
| Event | When | What happens |
|---|---|---|
| Pre-Plan | Before PI Planning | Solution Train leaders align the ARTs on the upcoming capabilities and the cross-ART dependencies to work on |
| PI Planning | Start of the PI, in every ART | Each ART plans its features, objectives, risks and dependencies, in the same window as the others |
| Coordinate and Deliver | During the PI | Regular solution syncs on progress, dependencies, risks and integration across ARTs and suppliers |
| Solution Demo | End of the PI | The integrated work of all ARTs and suppliers is shown to customers and stakeholders |
| Inspect and Adapt | End of the PI | The integrated solution is evaluated and the trains agree what to improve |
Pre-Plan
Pre-Plan "describes the activities that align and prepare ARTs within a Solution Train for PI planning."[7] Scaled Agile says Solution Train leaders "must ensure their ARTs enter PI Planning aligned on a shared vision, goals, and objectives for the upcoming PI."[7] In practice this means agreeing which capabilities are in scope, how they split across ARTs, which cross-ART dependencies and milestones matter, and what suppliers will deliver.
PI Planning in every ART
Each ART then runs its own PI Planning, ideally in the same window so cross-train questions can be answered on the spot. Representatives of the Solution Train and suppliers attend where their work is involved. After the ARTs have planned, Solution Train leaders bring the ART plans together into one view of the solution and resolve what does not fit.
Coordinate and Deliver
"Coordinate and Deliver describes the practices Solution Trains use to maintain the alignment and collaboration needed to continuously deliver value to large solution customers."[8] The core of it is a regular solution sync on capability progress, cross-ART dependencies, risks and integration, plus continuous or frequent integration so problems show up before the end of the PI.
Solution Demo
The Solution Demo "provides stakeholders an integrated view of the contributions of multiple ARTs and suppliers to obtain objective evidence of solution performance and to gather feedback."[9] Teams show the new capabilities, compliance with nonfunctional requirements and fitness for purpose, and the results inform the next investment decisions.[9]
Inspect and Adapt
At solution level, Inspect and Adapt is "a significant event where the current state of the integrated solution across all ARTs is demonstrated and evaluated."[6] The trains review the results together and agree improvements for the next PI.
Cross-ART dependencies and suppliers
Most Solution Train risk sits between trains: one ART needs an interface, a component or a test environment from another ART or a supplier. Make every cross-ART dependency visible with both ends, an owner and an iteration, and review the open ones at every solution sync.
- Find them early. Use Pre-Plan to list the dependencies each capability creates, so ARTs plan for them instead of discovering them in breakouts.
- Show both sides. A dependency that only the receiving train knows about is not a commitment.
- Watch the order. Flag dependencies where the provider plans to deliver after the receiver needs the work.
- Treat suppliers like trains. A supplier is "an internal or external organization that develops and delivers components, subsystems, or services, which help Solution Trains deliver solutions to customers."[6] Plan their deliveries on the same cadence and put them on the same board.
The dependency management guide covers how to map dependencies and reduce them at the source.
Common Solution Train challenges
The most common problem is the lack of one simple view of the whole solution. Each ART has a good plan, but nobody can quickly answer how a capability is progressing, which dependency is late or which risk affects several trains.
- No single view for stakeholders. The STE spends days collecting status from every train to answer simple questions about progress and risk.
- Problems found late. In a system this complex, a slipping feature in one ART shows up as a missed capability only at the Solution Demo.
- Several tools. Trains and suppliers often work in different Jira or Azure DevOps instances, so nobody sees the whole backlog.
- Local optimisation. Trains protect their own objectives and treat cross-ART work as lower priority.
- Integration left to the end. Without regular integration, the Solution Demo becomes the first time the parts meet.
The benefits are the reverse of these problems: several trains working toward one vision, a shared cadence that makes planning routine, customer feedback every PI, and the flexibility to change course in a very large development effort.
How Kendis supports a Solution Train
The Kendis solution board puts a whole Solution Train on one board: up to 30 PI boards, one swimlane per ART, with capabilities, cross-ART dependencies, objectives, ROAM risks and milestones in one place, synced with Jira and Azure DevOps.
- Every ART in its own swimlane. Link up to 30 PI boards to one solution board, each with its own iterations.
- Jira and Azure DevOps together. Bring in work from several Jira and Azure DevOps accounts on the same board.
- Capability progress. See how much of each capability is landing this PI and which ART carries the largest share.
- Cross-ART dependencies. Both ends and the line between ART swimlanes, coloured when a dependency is overdue or in the wrong order.
- Objectives, risks and milestones. Solution objectives with business value, one ROAM view across every train's risk register, and a timeline with milestones.
The STE can run Pre-Plan and the solution sync from the board, and each ART keeps planning on its own PI board. See the solution board page for how it is set up.
Run your Solution Train in Kendis, 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.
More SAFe guides
Solution Train: frequently asked questions
What is a Solution Train in SAFe?
A Solution Train is the SAFe structure for building a large solution that needs several Agile Release Trains and suppliers. It adds the Solution Train Engineer, Solution Management and Solution Architect roles, a backlog of capabilities, and events such as Pre-Plan and the Solution Demo.
When do you need a Solution Train?
When one solution cannot be delivered by a single ART: several trains and often suppliers must integrate their work, cross-ART dependencies appear every PI, and the whole system has to meet regulatory or safety standards.
What is the difference between a Solution Train and an ART?
An ART is a team of agile teams that plans and delivers features together. A Solution Train is a team of ARTs and suppliers that delivers capabilities for one large solution, with its own backlog, roles and Solution Demo.
What does a Solution Train Engineer do?
The Solution Train Engineer is a servant leader and coach who facilitates the Solution Train events, coordinates the work of the ARTs and suppliers, and works with the Release Train Engineer of each train.
What is the difference between a capability and a feature?
A capability is large solution functionality that often spans several ARTs and sits in the Solution Train Backlog. A feature is sized for one ART within a PI. Capabilities are split into features that each ART plans.
How do you manage a Solution Train in Jira or Azure DevOps?
Each ART plans in Jira or Azure DevOps, but neither shows several trains, their dependencies and capability progress in one view. Kendis adds a solution board on top of both, with up to 30 PI boards on one board, and is free for six months.
Sources
Every external claim in this guide links to the primary source below. All links were checked on 20 October 2026.
- Scaled Agile, Inc. Solution Train (Extended Guidance).
- Scaled Agile, Inc. Solution Train Engineer (Extended Guidance).
- Scaled Agile, Inc. Solution Management.
- Scaled Agile, Inc. Solution Architect.
- Scaled Agile, Inc. Features and Capabilities.
- Scaled Agile, Inc. Large Solution SAFe (last updated 5 December 2022).
- Scaled Agile, Inc. Pre-Plan.
- Scaled Agile, Inc. Coordinate and Deliver.
- Scaled Agile, Inc. Solution Demo.
Definitions and quoted text come from the publicly visible parts of Scaled Agile's pages linked above; parts of those pages require a login and are not quoted. Practical advice and examples are Kendis guidance, not SAFe requirements. If something is out of date, tell us and we will correct it.