A company is about to launch Agile Release Trains within a Value Stream that consists of 200 people, 90 of whom are in the U.S. working on the system's business logic and databases, and 110 of whom…

Question

Options

• ALaunch it as two or more ARTs based on how the cost centers are defined.
• BLaunch it as two distributed ARTs organized around end-to-end functionality.
• CLaunch it as two geography-based ARTs, with one working on the UI and the other on business
• DLaunch it as a single ART and then conduct Inspect & Adapt at the end of the PI to determine

• A
  11% (4)
• B
  57% (20)
• C
  6% (2)
• D
  26% (9)

Explanation

Organizing ARTs around end-to-end functionality (B) aligns with the core SAFe principle that each ART should be able to deliver complete, working features independently - a 200-person value stream is too large for a single ART (SAFe recommends 50–125 people), so splitting into two functional ARTs lets each team own a full slice of value delivery across both US and India.

Why the distractors fail:

• A (cost centers): Cost centers are financial constructs, not value-delivery units - organizing ARTs around accounting lines creates teams that can't independently deliver customer value.
• C (geography/technical layer split): This is the most tempting wrong answer, but splitting UI from business logic means every feature requires cross-ART coordination, creating permanent dependencies and integration pain.
• D (single ART of 200): SAFe explicitly caps ARTs at ~125–150 people; exceeding this makes synchronization, PI Planning, and Inspect & Adapt sessions unmanageable - you can't just "see how it goes."

Memory tip: Think "ARTs ship features, not functions." If splitting your ART means neither half can deliver a complete feature alone, you've split it wrong - geography and cost centers are both red herrings.

No community discussion yet for this question.