Scaled Agile for Many Teams at Once

01Train

• Agile Release Trains

  A train carries a name, a code, its PI length, its iteration length, and whether it runs an Innovation and Planning iteration.

• Teams on the train

  Attach and detach teams with the dates they joined and left, so the history of the train stays accurate.

• The four SAFe roles

  Assign Release Train Engineer, Product Manager, System Architect, and Business Owner, each with assigned and revoked dates.

• Projects on the train

  Attach projects so their epics, features, and stories become the train's backlog rather than a separate list.

• A health view

  Current increment and how far through it you are, objective value delivered, open risks, dependency count, and who the RTE is.

• Duplicate, archive, export

  Copy a train to start the next one, archive a finished one, and export the train list as CSV or PDF.

02Increment

• Program Increments

  Each increment carries a theme, its business context, its dates, and its status.

• Iterations made for you

  The increment is sliced into iterations of the train's length and named automatically, so the cadence is never typed twice.

• The IP iteration

  When the train uses one, the last iteration is marked as the Innovation and Planning iteration.

• Lock and close

  An increment moves from planning to executing to closed in one direction only, and the lock records who did it and when.

• A guided planning event

  PI planning runs as four steps: objectives, ROAM risks, confidence vote, then a summary.

03Planning

• PI objectives

  Committed or uncommitted, owned by a team, with planned business value and, later, the actual value delivered.

• The program board

  Teams across, iterations down, with features placed in cells and a committed load percentage on each placement.

• Dependencies

  Link backlog items as blocks, related, duplicates, or parent of, and see the cross team ones drawn on the program board.

• ROAM risks

  Every programme risk is resolved, owned, accepted, or mitigated, with an owner and the date it was identified.

• Confidence vote

  A fist of five vote per person, optionally per team, over as many rounds as the event needs, with the average shown.

04Backlog

• WSJF prioritisation

  Score business value, time criticality, risk reduction, and job size, and the ranking is calculated and kept as history.

• Three levels

  Epics, features, and stories overlay your existing work items rather than creating a second backlog to keep in step.

• Enabler stories

  Mark a story as an enabler and say which kind: architecture, exploration, infrastructure, or compliance.

• Six filters

  Narrow by text, level, programme, train, increment, and team, then clear the lot in one click.

05Boards

• One per level

  Epic, feature, and story each get their own Kanban with the states you define, starting from a Funnel to Done default.

• A WIP limit per state

  Cap how much sits in any state, set which state is the entry point, and mark which ones mean done.

• Audited transitions

  Define which moves are allowed, attach a required permission to a move, and every move is written to an audit row.

06Measures

• Flow velocity

  Items completed per week, computed from real state transitions, with a recompute button and CSV export.

• PI predictability

  Actual business value against planned, per team and for the train, counting committed objectives only.

• Inspect and Adapt

  Record the session, the date it was held, the system demo notes, and the predictability it produced.

• Improvement items

  Each one carries the problem, the root cause, the countermeasure, an owner, and the increment it is aimed at.

07Running it

• A dashboard you arrange

  Eight cards covering progress, objectives, train health, features, dependencies, risks, roadmap, and the next ceremonies, in the order you drag them.

• 44 permissions

  Nine groups covering train management, backlog, WSJF, PI planning, the program board, objectives, risks, Inspect and Adapt, and metrics.