SAFe 5: The Art of the ART

In the old days, release planning was a 3-way altercation about scope, schedule, and quality. Now, successful software organizations operate under the principle that quality is a given, that is, its a non-negotiable parameter of delivering software. For many others alas, this is more a platitude than a serious commitment, as they have not built in fundamental quality practices like code reviews, unit test automation, TDD, continuous integration, and so on, and rely upon wishful thinking to convince themselves that their software is solid. Assuming quality is indeed a given, many organizations continue to plan on the basis of scope versus schedule tradeoffs. The agile release train (ART) concept eliminates this problem by having product release dates set at regular fixed intervals, leaving just one release parameter to be decided – scope. Scope is determined at release planning (or PI Planning) events – decribed in detail here.

Plan Driven vs. Value-Driven
Plan Driven vs. Value-Driven

At fixed intervals, say every 6 weeks, the organization produces a production-quality, fully tested and deployable product increment. Every one of these releases need not be deployed to production, or as the saying goes, produce on cadence, deliver on demand. Deployment becomes a business decision, completely separate from any development considerations. The quality of all PI’s is completely consistent, assuming the investment has been made to put all of the prerequisite practices in place.


  • Portfolio: A collection of programs (that realize products or services, from which an organization gets revenue).
  • Program Backlog: Ranked list of features for a given program.
  • PI: Program Increment – a potentially deployable increment of the product.
  • Agile Release Train (ART): A mechanism to synchronize the work of multiple teams to produce a deployable product increment on a fixed cadence.

Agile Release Trains (ARTs)

  • Synchronizes the activities of multiple development teams building software from a single program backlog
  • Optimized for 5-12 teams (50-125 people)
  • Default time-box is 10 weeks (5 iterations)
  • ART delivers a PI every 10 weeks
  • PI planning is 2 days every 10 weeks. All attend in person
  • Product manager (‘Chief PO’) owns feature priorities
  • Architects for dependencies and interfaces
  • Teams own story creation and estimates
  • PI objectives is mostly a list of features, but can contain other items such as higher level business objectives, milestones (e.g. trade show event), and ‘enablers’ (infrastructure upgrades, architectural enhancements).
  • Features fit in a single PI, and are implemented incrementally via user stories
  • User stories describe product behavior
  • User Stories fit in a single iteration
  • ‘Enabler stories’ include exploration work, architecture, infrastructure work. (All work is accounted for).
  • Teams operate in synchronized cadence

Here is an example showing an ART with 3 teams, doing 2-week iterations, producing product increments every 6 weeks.

Agile Release Train
Agile Release Train with 3 Teams

Of course, every iteration should produce a production-quality release. The decision to release is a business one, not a technical one. (Produce on cadence, release on demand).

Feature Delivery by Multiple Teams
Feature Delivery by Multiple Teams

ART Roles

  • Release Train Engineer (RTE) – Chief scrum master – orchestrates all ART ceremonies
  • Product Manager – Chief product owner – owns the PI backlog
  • System Architect – Owns definition of overall technical solution
  • Teams – Own PI Planning and feature delivery.
  • Development Management – plays a supportive role. Works to eliminate impediments that are beyond the control of the teams, actively supports teams with training, tooling and any other support needed for success.
  • Business Stakeholders – Ensure programs are aligned with strategic themes and roadmap. Actively participate in program-level events.

ART Ceremonies

  • PI Planning Preparation – Feature intake, refinement and ranking
  • PI Planning – 2 days, every 10 weeks.
  • Scrum-Of-Scrums – synchronization and alignment of teams during the PI time-box – at least weekly. More details here.
  • System demos – end-to-end demo of integrated work from all teams at end of each iteration.
  • PI demo – demo of entire PI upon completion of PI.
  • PI retrospective – retro on completion of PI objectives.

ART Artifacts

  • Actively maintained program wall-board. (Use stickers on cards to indicate status: To Do, In Progress, Done). Or, Feature Progress Board (Re-purposed Program Board)
  • Feature completion reports.
  • PI burnup chart – story points completed by iteration.

For those that have the luxury of a dedicated physical space for their Scrum-Of-Scrums, have all 3 of these charts on display for the program team. These information radiators will focus these events and ensure a high degree of alignment.

Program Wall Board
Program Wall Board
Feature Progress Tracking
Feature Progress Board
Feature Completion Report
Feature Completion Report
Here is an alternative (more scaleable) way to present feature progress. X-axis is story points or a simple story count per feature:
Progress By Feature
Progress By Feature
We also want to see how the overall PI is progressing. For this we use a PI burnup chart, which shows completed story points by sprint:
PI Burnup Chart
PI Burnup Chart


Regularly scheduled meeting, facilitated by a program scrum master (RTE in SAFe) with representatives (‘ambassadors’) from each team contributing to the program. Discuss what features are planned for delivery this sprint, any related dependencies, and any problems or impediments that need to be addressed. Whereas team-level standups are focused on sprint goals, the scrum-of-scrums should be about PI goals. Let’s remember that one of the outputs of the PI planning event is a ranked list of program objectives – things can and do change on a program mid-flight, and the scrum-of-scrums needs to be monitoring the overall health of the program and making adjustments for the purpose of ensuring maximum value delivery, even if any one objective fails to be realized – the goal is the overall success of the train – not any one individual team.

One way to operate the meeting is to have a huddle around at the program-level information radiators, and cycle through each team asking program-level versions of the 3 questions: (Its useful to have scrum-of-scrums immediately after the team standups):

  • What has my team accomplished towards its PI objectives since the last time we met
  • Which PI goal is my team working on completing next, and
  • What impediments does my team currently have.


  • Aligned program team
  • Actions or plan adjustments to address problems or other required changes
  • Updated program radiator (program wall board, feature progress board and release burn-up chart).