Architecture Runway Plan: [Agile Release Train, product or solution name]

Plan for building and maintaining the architectural runway of one agile release train, product or solution: the existing code, components and technical infrastructure that the next features need so they can be delivered without major redesign or delay. It records the architectural intent and guardrails (what is decided up front and what is left to emerge), the upcoming features, the current runway and its gaps, the enabler backlog, spikes, capacity allocation, sequencing, governance and runway health metrics. Terminology follows the Architectural Runway and Enabler concepts of the Scaled Agile Framework (SAFe 6.0, Core SAFe; AI-Native SAFe, introduced in June 2026, builds on it) and the intentional versus emergent architecture distinction found in agile architecture practice, including the Open Agile Architecture standard. Replace every [bracketed] value and every row marked Example.

Document control

Approvals

Revision history

Contents

1. Purpose, scope and planning horizon
2. Architectural intent and guardrails
3. Upcoming features and capabilities
4. Current runway inventory
5. Runway gap analysis
6. Enabler backlog
7. Spikes and exploration
8. Capacity allocation
9. Sequencing and dependencies
10. Governance and decision rights
11. Runway health metrics
12. Risks and assumptions
13. Glossary and references

1. Purpose, scope and planning horizon

1.1 Purpose

[One paragraph: why the runway matters now for this train, which business outcomes depend on it and which decision this plan informs.]

Example: The merchant payments train (8 teams) will launch two new markets and an instant payout product over the next three PIs. Each needs capabilities the platform lacks today: a provider adapter layer, multi-currency ledger support, regional data residency and an event backbone for payout status. This plan identifies the enablers that must land one PI ahead of the features that depend on them and the capacity the train will reserve for them.

1.2 Scope

1.3 Planning horizon

2. Architectural intent and guardrails

2.1 Intent statement

[Three to five sentences: the architectural direction the runway moves toward, linked to the architecture roadmap (architecture/architecture-roadmap-transition) and principles (architecture/architecture-principles).]

Example: Every payment flow runs through a provider-neutral core with adapters at the edge. State changes are published as events on a single backbone, and consumers never read another service's database. Data for each market stays in its residency region. Teams choose their own internal design within these rules.

2.2 Intentional or emergent

Use the criteria below to place each architecture decision.

2.3 Guardrails

Guardrails are the rules every team follows so that emergent design stays compatible with the intent. State each as a rule that can be checked, and automate the check where possible.

3. Upcoming features and capabilities

4. Current runway inventory

5. Runway gap analysis

6. Enabler backlog

6.1 Enabler list

6.2 Enabler definition

Write one block per enabler that is planned for the next PI.

ENB-02 (Example): multi-currency balances and FX postings

[ENB-nn]: [title]

6.3 Enabler readiness checklist

• The enabler closes a named gap that blocks a named feature.
• Acceptance criteria are testable and include at least one quality measure taken from a scenario in requirements/quality-attributes.
• Its size fits within one PI for the owning team, or it has been split into parts that each do.
• The system remains releasable at the end of every iteration while the enabler is built.
• The team that will consume the runway has reviewed the interface; for new interfaces consider an ARID review (architecture/arid-design-review).
• Run costs and operational ownership after delivery are agreed.

7. Spikes and exploration

Where a spike compares several architectural strategies with a cost and benefit, a short CBAM (architecture/cbam-analysis) can rank them before the enabler is committed.

8. Capacity allocation

8.1 Allocation for the next PI

Example: Enabler demand for the next PI is ENB-02 (2.0), ENB-03 (1.5), ENB-04 (1.0), ENB-05 (0.5) and the remaining 3.0 of ENB-01, which has slipped from the current PI: 8.0 team-iterations, equal to the 25 percent allocation. Any further slip in ENB-01 would push ENB-03 out, and with it FEAT-02.

8.2 Allocation history

8.3 Allocation rules

• Reserve enabler capacity for gaps whose dependent features start within the next two PIs; defer the rest.
• Do not borrow enabler capacity for features without product management and the system architect agreeing, and record the consequence on the dependent feature dates.
• Use the innovation and planning iteration for spikes and runway hardening where the train's cadence includes one.

9. Sequencing and dependencies

Example: PI n runs from 2026-09-02 to 2026-11-10, PI n+1 from 2026-11-11 to 2027-01-19 and PI n+2 from 2027-01-20 to 2027-03-30. The slip of ENB-01 means it now finishes mid PI n+1 and FEAT-03 starts straight after it in the same PI, which breaks the one-PI-ahead rule. The risk is recorded as RR-01. Record every such tight pair in section 12.

10. Governance and decision rights

10.1 RACI

R: responsible, A: accountable, C: consulted, I: informed.

10.2 Cadence

10.3 Records

• Record each intentional decision as an ADR in the decision log (architecture/architecture-decision-log) and link it from section 2.2.
• Record guardrail exceptions with an expiry date; an exception without an expiry becomes technical debt and belongs in the debt register.
• Link each enabler to the fitness functions it adds, so the runway is protected from erosion after delivery.

11. Runway health metrics

Example: The next two PIs are PI n+1 and PI n+2. They contain four features: FEAT-01, FEAT-02, FEAT-03 and FEAT-04 (FEAT-05 and FEAT-06 are in PI n+3 and are not counted). Only FEAT-04 has Ready runway (RWY-01), so coverage is 1 of 4, or 25 percent. When ENB-01 completes, FEAT-03 becomes covered and coverage rises to 50 percent. State which features you count so the metric can be recomputed.

12. Risks and assumptions

13. Glossary and references

13.1 Glossary

13.2 References

Standard and licence note

Structure aligned with the Architectural Runway and Enabler concepts of the Scaled Agile Framework (SAFe 6.0, as listed at framework.scaledagile.com) and with the intentional versus emergent architecture distinction named in agile architecture practice, including the Open Agile Architecture Standard, Version 2.0, of The Open Group. This template uses only the names of these concepts; all text, tables, metrics and the worked example are original and do not reproduce SAFe or Open Group content. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.; Open Agile Architecture is a trademark of The Open Group. This template is not affiliated with or endorsed by either owner. Check the current SAFe version (SAFe 6.0 is presented as Core SAFe; AI-Native SAFe, introduced in June 2026, builds on it) and the current Open Group publication before use. Template licence: MIT.