Scaling with ARTs

For organizations running SAFe at scale, AgileNotes.AI rolls multiple teams up into an Agile Release Train (ART). Select the ART from the team selector and every view you've seen so far switches into an aggregate, train-wide read — plus two scaled-only views: the Program Board and Dependencies.

In the Demo, three teams — Dragons and Tigers (Scrum) and Juggernauts (Kanban) — belong to a Sample ART. Pick it from the team selector and the app re-scopes to the whole train.

Switching into ART scope

The team selector lists your ARTs alongside your teams. Choosing an ART:

• Re-scopes the Dashboard, Summary, Statistics, and Charts to aggregate every team on the train.
• Unlocks the Program Board and Dependencies views.
• Presents an RTE / Coach perspective — a train-wide read — while each team keeps working in its own team-scoped views exactly as described in the rest of this manual.

Because Scrum teams measure committed-vs-delivered story points while Kanban teams measure flow, the ART views stay framework-aware: they keep the two kinds of delivery side by side rather than adding mismatched numbers together.

Delivery dimensions

The hard part of running a train is that an ART is a collection of teams — one team having a rough sprint doesn’t put the whole train in peril. Rather than a single opaque score, AgileNotes reads the train across a small set of delivery dimensions, each showing an observable state — Stable, Elevated, or High — so an RTE can see at a glance where attention is genuinely needed, and why.

Each dimension weighs how much of the train is affected — by delivery size, so a larger team counts for more than a small one — against whether it’s being managed: is the drift owned and worked down, or unmanaged and disrupting delivery? A lone team struggling is surfaced but doesn’t raise the whole ART. A dimension only reads High when the strain is spread across the train and going unmanaged. Each state names the teams driving it, so you can go straight to them.

The train-wide dimensions are:

• Delivery Stability — are teams delivering to their own framework? (Scrum: projected delivery + velocity consistency; Kanban: throughput forecastability.) It escalates only when the committed scope is genuinely at risk — not when a team hits a bumpy stretch the train can absorb.
• External Dependency Load — cross-team friction: at-risk or overdue hand-offs and waiting-on / blocked-by notes raised in your ceremonies, not the count of dependencies. Having dependencies is healthy collaboration; only friction going late is a concern.
• Aging Work — work that’s been open too long: Kanban tickets past their service-level expectation, Scrum committed work that has rolled over and is still open. First-tier aging that’s being worked stays calm; work well past its expectation, spread across the train, is what raises it.
• Unplanned Work — unplanned work that disrupted committed sprints — pulled in while commitments were still open — not work taken on as spare capacity after commitments were done.
• Objective Risk — un-managed risk posture (un-ROAMed or high-severity risks left open against your committed objectives), not the number of open risks. A fully-ROAMed register reads Stable however many risks it holds.

There is no leaderboard and no 0–100 number. States read the same underlying metrics you already track — combined with the notes, ROAM posture, and projections that tell you whether a number is actually a problem.

The ART Dashboard

The Dashboard leads with a program snapshot — the delivery dimensions above, Scope Progress (how much committed work is done), and an On Track? projection — followed by a per-team drift list. Below that, the familiar stat row aggregates the train: blockers, risks, bugs, dependencies, and Avg Velocity.

Delivery is split so the two frameworks stay readable: a Done / Forecasted (SP) card for the Scrum teams and a separate Done (SP) · Kanban card, rather than one blended total. Days Since Release reflects the most recent release across any team on the train.

The ART Summary

The Summary opens with the same program snapshot, then assembles an AI-written ART Overview that narrates the increment honestly across frameworks — for example, “Scrum teams committed X of Y points; Kanban teams delivered Z points” — never merging the two. Below it, aggregated blockers, decisions, risks, observations, accomplishments, and sprint goals from every team.

As on a team Summary, the Overview is cached and refreshes at the end of the iteration or when you click Regenerate, and an editable ART Context note lets you add train-level framing for the AI to weave in.

ART Statistics & Charts

Statistics in ART scope shows a team breakdown — each team’s headline metrics side by side, framework-aware — so you can compare delivery and flow across the train in one table.

Charts aggregate trends across every team and iteration of the PI, so a train-wide view rolls the teams up without double-counting the sprints they share.

The Program Board

The Program Board is the classic PI-planning wall, rendered live from your data. Each team is a row and each iteration of the PI is a column, so the whole train’s plan — features, milestones, and the dependencies between teams — is visible in one place.

• Features and epics sit in the iteration where they’re planned to land; an Uncommitted lane holds work that isn’t slotted yet.
• Milestones and significant events can be placed as cards on the board.
• Because it’s generated from the same tickets and sprints the teams work in day to day, the board is never out of date — there’s no separate plan to maintain.
• Export image, Export vector, or Export CSV to take the board into a whiteboard tool (Miro, Hoylu, Lucid, Mural) or a spreadsheet — the PNG for a visual drop-in, the SVG for an editable vector that imports as shapes, the CSV for every card with its team, iteration, status and links.

Dependencies

The Dependencies view tracks cross-team dependencies as first-class items: who needs what, from whom, and by when.

• Each dependency records the providing and consuming teams, what’s needed, and a needed-by date.
• Overdue and at-risk dependencies surface in the AI signals and on the Program Board, so a hand-off slipping on one team becomes visible to the teams depending on it — before it becomes a fire.

PI Capacity

In ART scope, the Capacity view leads with the PI Capacity table — the number you take into PI Planning.

• One row per team, one column per iteration of the PI; each cell is the team’s net person-days (member base days, capped by workdays, minus PTO — workdays exclude weekends and company holidays).
• Row totals give each team’s capacity for the whole PI; the bottom row totals the ART per iteration, down to a grand total.
• Export CSV to take the table into your PI Planning prep, and the PTO calendar below shows the underlying time-off across every team.

PI Objectives & business value

The Objectives view is where the train records what each PI will deliver, in business language, and scores the value of delivering it — the outcomes you report upward.

• Each objective belongs to a team or to the train (ART-level), and carries a planned business value (0–10) set at PI planning and an actual business value recorded at the Inspect & Adapt.
• The ART Predictability Measure at the top is actual ÷ planned business value, averaged across teams. The reliable zone is 80–100% — it’s the single number business owners recognise, and it trends over PIs as your history builds.
• Mark stretch work Uncommitted so it’s excluded from the commitment but still counts any value it delivers, and use each objective’s status to show where it stands through the PI.
• Link the epics that deliver it. In the editor, pick a team then its epics (a train-level objective can pull epics from several teams). Each objective then shows those epics live — their current name, a status colour, and a delivery % (story points done ÷ total). When a team is connected to Jira the status comes straight from the sync, so re-syncing updates the objective on its own; teams without an APM tool use the epics they maintain by hand. Business value stays your judgement — the epics are the live evidence beside it.

ART Sync

The ART Sync view is where the RTE runs the train’s recurring coordination meetings from live data. A toggle switches the view to the meeting you’re in, so you see what matters for that conversation and nothing else:

• Scrum of Scrums — the cross-team dependencies and signals: which hand-offs are at risk and who needs to talk to whom.
• PO Sync — objectives and predictability: which objectives are off track and where the ART predictability sits and is trending.
• ART Sync — the combined review of both.
• The Focus for this sync line summarises what needs attention for the meeting you’re in.
• Generate brief produces a short, grounded set of AI talking points to open the meeting — tuned to the meeting type, drawn only from what’s on screen, and editable like every other AI answer.
• Capture follow-ups as Action notes tagged ART Sync — they roll forward until done and can be filtered from the Notes view anytime.

ART Notes

Everything you capture while running the train has a home. In ART scope, Capture (the + button or Ctrl + Q) records an ART note — the train’s own, kept apart from any one team’s notes — and you tag it with the meeting it came from:

• SoS, PO Sync, ART Sync, and Demo notes file under the current iteration — the coordination of the sprint you’re in.
• Planning, PI, I&A, and Retro notes file under the PI — the increment-level record. These attach to whichever PI is selected in the header, so switch to the PI you’re planning for before you capture.
• The Sprint / PI toggle at the top switches which of the two you’re reading; the team selector still decides whether you’re looking at a team or the whole train.
• ART Notes shows only the train’s own notes — a team’s notes live on that team’s Notes view, one selection away — so the RTE’s record stays about the train, not buried in team chatter.

ROAM program risks

The ROAM view is the train’s Program Risk register — the risks raised at PI Planning that the ART owns, distinct from a team’s day-to-day risks (those stay on the team’s own surfaces so this view isn’t cluttered).

• Raise a risk and it lands in the To ROAM lane; then drag each card into Owned (someone’s on it), Accepted (live with it), Mitigated (action has reduced it), or Resolved (closed).
• The To ROAM count is what the risk-management review exists to clear. The whole train can see the register; the RTE/Coach raise and ROAM.

The ART Program Report

From the ART Summary, click Generate ART Report to publish a single stakeholder-facing report for the whole train — it opens as a shareable link you can send straight to business owners.

• The report leads with a PI summary strip (which iteration the train is in, the Predictability Measure, committed epics complete, and the delivery projection), then objectives & business value, milestones, the program risks with their ROAM disposition and owner, open cross-team dependencies, and a delivery-dimensions table showing each team’s states — under a roll-up footer that names the train, the RTE, and how many teams (Scrum and Kanban) it covers.
• The link stays live for 90 days; regenerating the report keeps the same link with a fresh window, so a URL you’ve already shared always shows the latest published version.
• Because it’s generated from the same live data the RTE works in day to day, it’s never out of date — there’s no separate deck to assemble for the business review.