Agile Release Trains

The long-lived team of teams the Program Increment cadence actually runs inside.

The container for the Program Increment Cadence: a long-lived, cross-functional team of teams — roughly 5–12 teams, 50–125 people — organized around one shared value stream, not a single project. Individual initiatives come and go; the train stays:

  • Virtual, not org-chart — a train pulls people from wherever they sit functionally; it's a planning and delivery structure layered on top of reporting lines, not a replacement for them. Cisco and John Deere both have public case studies of running multiple ARTs company-wide, each with its own PI cadence running in parallel.
  • Long-lived, not project-scoped — the train keeps its own cadence indefinitely; what it's building against changes, but the rhythm and the roster mostly don't. This is the opposite of standing up a project team and disbanding it at launch — stability is the point, so teams get better at the cadence itself over time.
Example

Train: Checkout Experience ART — 6 teams, ~42 people

PI length: 10 weeks

Cadence: 2-day PI Planning → five 2-week iterations, each with a System Demo → 1-day Inspect & Adapt, then repeat

Who actually runs a train day to day is its own topic — see Roles & Responsibilities.

Try It

Paste this into ChatGPT, Claude, or whatever AI tool you use:

Help me think through whether my organization should be structured as one or more Agile Release Trains. Ask me how many teams are working toward a shared outcome and whether they already plan against a shared backlog, then help me decide if a single train makes sense or if the work actually splits into more than one.