SAFe

SAFe on one screen

Here is the whole framework first. SAFe defines events at four levels, but a train runs on the first two alone — everything above the Agile Release Train is optional and comes later, if at all. The first table lists every event with its level, cadence, who attends and what comes out of it. The second says who sits at each level and what they own.

The unit is the train

Start with the problem SAFe is trying to solve. One Scrum team of eight people works fine. Put sixty people on one product and something breaks — not the coding, but the coordination. Team A finishes something that Team B needed three weeks ago. Nobody knows who decided what. Integration happens at the end and nothing fits.

SAFe’s answer is the Agile Release Train, usually shortened to ART. An ART is a long-lived group of five to twelve teams — typically 50 to 125 people — that plans together, commits together and delivers together. The upper limit is deliberate: SAFe cites Dunbar’s number, the rough ceiling of about 150 on how many working relationships a person can keep up.

The word "train" is meant literally. The train departs on a schedule whether or not your feature is on board. Every team on it runs the same iteration length and lands on the same boundary, so the whole group has synchronised moments where everything can be integrated and inspected.

That shared boundary is the Planning Interval, or PI. It runs eight to twelve weeks — most commonly four two-week development iterations followed by one Innovation and Planning iteration — and it is the unit everything in SAFe is organised around. Until SAFe 6.0 in March 2023 it was called the program increment, and most of what has been written about SAFe still uses that name. The rename says something real: the PI is a planning rhythm, not a release date. SAFe’s phrase for it is "develop on cadence, release on demand" — plan together on a fixed beat, and ship whenever a piece is ready.

The Release Train Engineer is worth a closer look, because the role is easy to misread. An RTE is a servant leader for the train — they run the train’s events, chase impediments across team boundaries and keep the flow visible. They do not assign work to teams and do not decide what gets built. An RTE who is doing either has become a programme manager with a SAFe job title. Two supporting groups sit beside the teams: a System Team, which builds and runs the shared integration and test environment the System Demo depends on, and Shared Services — specialists such as security or data architects whom every team needs occasionally and none needs full time.

The same rename touched most of the vocabulary. Anyone reading older material, or joining an organisation that adopted SAFe before 2023, will meet the left-hand column.

One more naming note, because it is recent. In June 2026 Scaled Agile released AI-Native SAFe, a second operating model with smaller AI-augmented teams, shorter cycles and a new AI value architect role. It sits beside the existing framework, which the company now calls Core SAFe, rather than replacing it. Everything on this page is Core SAFe.

Four configurations — start with the smallest

SAFe is not one thing you adopt whole. It comes in four configurations, each adding a level to the core of teams on a train. Choosing the smallest one that solves your problem is the single most important decision in a SAFe adoption — and the one most organisations get wrong by starting too large.

• Essential SAFe

  One Agile Release Train and nothing above it. This is the minimum viable SAFe and where every adoption should start. If your problem is coordinating fifty to a hundred people on one product, this is the whole answer.

• Large Solution SAFe

  Several trains building one very large system — aircraft, defence systems, telecoms infrastructure. Adds a Solution Train to coordinate the ARTs. Rare outside genuinely large engineering.

• Portfolio SAFe

  Adds funding and strategy above the trains: lean budgets, portfolio epicsepica large backlog itemA large piece of work that is split into features or stories before anyone builds it, best written as a bet with a hypothesis and a condition that closes it. Its size depends on whose vocabulary is in use — anything above a story in Jira, a portfolio investment with a business case in SAFe — so check before comparing two epics.Full article →All terms, an investment view. This is where SAFe stops being about delivery and starts being about where money goes.

• Full SAFe

  All levels at once. Genuinely appropriate for a handful of very large organisations, and the configuration most often adopted for the wrong reason — because the poster shows it.

The implementation roadmap

SAFe publishes its own sequence for adopting it. It is usually quoted as twelve steps; the revision of April 2025 has thirteen, reproduced here under their own names and in their own order.

• 1. Reaching the Tipping Point
• 2. Train Lean-Agile Change Agents
• 3. Create a Lean-Agile Center of Excellence
• 4. Train Executives, Managers, and Leaders
• 5. Lead in the Digital Age
• 6. Organize Around Value
• 7. Create the Implementation Plan
• 8. Prepare for ART Launch
• 9. Train Teams and Launch ART
• 10. Coach ART Execution
• 11. Launch More ARTs and Value Streams
• 12. Enhance the Portfolio
• 13. Accelerate

Two things are worth noticing in that list. Step 6 is the one that decides everything else: organising around value means drawing the train around the path a product takes to a customer, and a train drawn around the existing departments will coordinate them without changing anything. And the first train does not run until step 9. Steps 2, 4 and 9 are training, and SAFe’s training and certification are also the business model of the company that publishes it — a fact worth holding in mind when a roadmap spends its first half in classrooms.

PI Planning, the IP iteration and Inspect & Adapt

If an organisation takes only one thing from SAFe, it should be PI Planning. Most of the value teams report comes from here, and it is the practice most worth stealing even if you never adopt the rest. It takes two full days, and every team on the train is present — all fifty to a hundred and twenty-five people, in one room or one video call. SAFe publishes a standard agenda for it.

Three terms from that agenda need a sentence each. ROAM sorts every train-level risk into one of four states: Resolved — no longer a concern; Owned — someone has taken it and will report back; Accepted — it cannot be solved, and the train goes ahead knowing it; Mitigated — a plan reduces its impact. Its value is that a risk cannot be left in a fifth state, "mentioned".

PI objectives are the short statements of what each team intends to achieve in the PI, written in business terms rather than as a list of features. Each one is either committed — the team promises it — or uncommitted, which means planned into the capacity but not promised, so the team has room to absorb surprises. Business Owners give every objective a business value from 1 to 10, and those numbers come back at the end of the PI.

The confidence vote is a fist of five: everyone, not only the team leads, holds up fingers. A plan whose average is three or more is accepted; anything lower is reworked, and the individual ones and twos are asked about rather than outvoted.

The IP iteration

The IP iteration deserves attention because it is the first thing organisations cut, and cutting it is a mistake. It is a whole iteration at the end of the PI with no planned feature work in it. Teams use it for innovation, for learning, for infrastructure, for the final integration of the PI, for Inspect & Adapt and the next PI Planning — and as the buffer that absorbs everything the PI plan got wrong.

Inspect & Adapt

Inspect & Adapt closes the PI in three parts. The PI System Demo shows everything the train built in the PI, integrated. The measurement review goes through the numbers the train agreed to watch, starting with the predictability measure in the next section. And a problem-solving workshop takes the most important problem and works it in six steps: agree on the problem to solve, analyse its root causes with a fishbone diagram and the five whys, identify the biggest root cause with a Pareto analysis, restate the problem, brainstorm solutions, and turn the best ones into improvement items for the next PI Planning.

How SAFe measures itself — and how each measure is gamed

SAFe groups its measures into three domains: outcomes — is the business getting what it paid for; flow — how well value moves through the system; and competency — how well the organisation practises the framework. Four instruments do most of the work, and each has a known way of going wrong.

The predictability measure

At Inspect & Adapt, Business Owners score what each team actually delivered against the business value they gave its objectives at PI Planning. The team’s score is achieved value divided by planned value, and the train’s is the sum. SAFe asks for 80 to 100 percent: high enough that the business can plan on it, low enough that teams are still taking some risk.

Six flow metrics

SAFe 6.0 names six flow metrics. Most of them are the Kanban measures under new names, which is worth knowing, because the arithmetic behind them — Little’s Law, percentiles rather than averages — is explained on the Kanban page and applies unchanged.

WSJF, and what the SAFe version drops

SAFe orders its backlogs by WSJF, Weighted Shortest Job First: cost of delaycost of delaywhat one more week of waiting costsHow much value is lost for each unit of time a piece of work waits — high from the first minute for an outage, nothing until the deadline for a regulatory date, steadily growing for ordinary work. Putting even a rough number on it is what lets a team compare urgency instead of arguing about it.Full article →All terms divided by job size. Cost of delay is what one more week of waiting costs, and SAFe estimates it as the sum of three relative scores — user and business value, time criticality, and risk reduction or opportunity enablement — each on a modified Fibonacci scale. Job size stands in for how long the job takes. The item with the highest ratio goes first.

The idea comes from Donald Reinertsen, and the SAFe version changes it in two ways worth knowing. Reinertsen divides a cost of delay in money by the job’s duration; SAFe adds three rankings and divides by a size estimate, and adding rankings is arithmetic on numbers that only say "bigger than" — a 13 is not known to be worth exactly 13 of the 1s. And size is a proxy for duration that fails exactly where ordering matters most: a small job that must wait on another team is short on paper and long in reality. Used as a conversation about why one item is more urgent than another, WSJF is useful. Used as a formula whose output settles the argument, it is precision the inputs do not have. The Roadmapping page sets it beside RICERICEReach, Impact, Confidence, Effort — a score for ordering ideasA prioritisation score from Intercom: reach times impact times confidence, divided by effort, so a big claim with no evidence is marked down. It has no notion of time — a contract date and a nice-to-have score alike — and its inputs are guesses, so the argument it forces is worth more than the ranking.Full article →All terms, KanoKano modelhow satisfaction responds to a featureNoriaki Kano’s 1984 classification of features by how customer satisfaction responds to them: must-be (no praise when present, anger when absent), one-dimensional (more is better), attractive (delight when present, not missed when absent), indifferent and reverse. It says what customers expect, not what to build first.Full article →All terms and MoSCoWMoSCoWMust have, Should have, Could have, Won’t have this time — must, should, could, won’tA prioritisation rule from DSDM that sorts requirements into Must, Should and Could Have, plus Won’t Have this time — the one common model that writes a refusal down. Must Haves should take no more than about 60% of the effort, or nothing is left to give up when the estimate slips.Full article →All terms.

Normalised story points

For a new train’s first PI, SAFe gives a recipe for estimating in the same units across teams: give the team eight points per developer-tester for a two-week iteration, subtract a point for every day of leave or holiday, and call a story that takes about half a day to build and half a day to test a 1. It is a sensible way to get a first plan. It also makes one point roughly one day of work, so a train that keeps it has turned story pointsstory pointsrelative size, not hoursA unit for estimating the relative size of backlog items — an 8 is roughly twice a 5 — deliberately not tied to hours. They are useful for one team’s planning and nothing else: turned into a target or compared across teams, they inflate instead of measuring.Full article →All terms back into person-daysman-dayone person, one working dayA unit of effort: one day of one person’s work, usually eight hours — the unit quotes, fixed-price bids and time-and-materials invoices are counted in. It measures effort, not calendar time: twenty man-days is not four weeks for anyone until focus, meetings and dependencies are accounted for.Full article →All terms — and once points are comparable across teams, someone will compare the teams by them.

Four values and ten principles

Underneath the roles and events sit four core values and ten principles. They are usually skipped in training, which is unfortunate — they are the part that explains why the machinery is shaped the way it is, and the part an adoption can be measured against.

The four values replaced the SAFe 5 set — alignment, built-in quality, transparency and program execution — in 2023; built-in quality is still a practice, no longer a value. The ten Lean-Agile principles, in SAFe’s own order:

• 1. Take an economic view — decisions are trade-offs about money and delay, so make the economics explicit.
• 2. Apply systems thinking — optimise the whole flow, not each team separately.
• 3. Assume variability; preserve options — do not lock the design at the point of least knowledge.
• 4. Build incrementally with fast, integrated learning cycles — integrate constantly, not at the end.
• 5. Base milestones on objective evaluation of working systems — not on documents being finished.
• 6. Make value flow without interruptions — remove the queues and handoffs between teams.
• 7. Apply cadence, synchronize with cross-domain planning — a fixed rhythm turns coordination into a habit.
• 8. Unlock the intrinsic motivation of knowledge workers — individual incentives break collaboration.
• 9. Decentralize decision-making — centralise only the rare, far-reaching, economy-of-scale decisions.
• 10. Organize around value — structure teams by what the customer receives, not by technical component.

Principle 5 is the one that separates SAFe from Waterfall most sharply: a milestone is a working system someone has seen, not a signed document. Principles 9 and 10 are the ones worth measuring an adoption against. If decision-making has not decentralised and teams are still organised by technical component, then whatever was installed is not SAFe — it is the old structure holding SAFe events.

What the evidence shows, and the case against

SAFe attracts more criticism than any other framework on this site, and it is worth understanding rather than dismissing. Start with what is actually known, because there is less independent evidence than either side suggests.

Now separate the weak version of the argument against SAFe from the strong one. The weak version is "it is not really agile" — usually meaning it has too many boxes on its diagram. That is aesthetics, not analysis. A framework for two thousand people will be more complicated than one for eight, and that is not automatically a flaw.

The strong version is different and worth taking seriously. A framework this prescriptive lets an organisation adopt the vocabulary and the calendar while leaving its decision-making structure completely untouched. You can run PI Planning every ten weeks and still have every meaningful decision made by the same three executives it was made by before.

Where it degrades

Here is the diagnostic question for any SAFe adoption. A team discovers in week four that one of its PI objectives is simply wrong — the assumption behind it turned out to be false. What happens next?

If the answer is "we re-plan and tell the train at the next ART Sync", the framework is working as designed. If the answer is "we deliver it anyway and raise it at Inspect & Adapt", the organisation has bought a ten-week waterfall with a two-day kickoff — and it will get waterfall results while using agile vocabulary to describe them. The US Defense Innovation Board’s 2018 guide "Detecting Agile BS" asks the same thing more bluntly: is working software reaching at least some real users every iteration, and is their feedback changing the plan?

The honest limit: SAFe coordinates what an organisation has already decided to build, and it cannot make that decision better. At its best it surfaces dependencies; it does not remove them. Removing them is a matter of how teams are drawn — principle 10 — which SAFe states clearly and has no way to enforce.

• PI objectives treated as fixed scope commitments rather than as forecasts.
• Adopting Portfolio or Full SAFe before a single train delivers reliably.
• A train drawn around the existing departments rather than around a value stream, producing coordination without purpose.
• No System Demo of a genuinely integrated system, so integration debt lands at the PI boundary.
• The IP iteration filled with committed features, removing all the slack from the plan.
• Predictability reported as the train’s total, so a team at 60 percent and a sandbagging team at 125 average out.
• Normalised story points used to compare teams, so estimates inflate until the comparison means nothing.
• An RTE who assigns work and decides scope — a programme manager with a new title.
• Inspect & Adapt run as a status report, with no problem-solving workshop and no improvement items in the next plan.
• Certificates counted as adoption: everyone trained, nothing about who decides has changed.

When to use it

Related pages

• ManagementLeSSLeSS (Large-Scale Scrum) is a framework that scales Scrum by running many teams as one: one Product Owner, one Product Backlog, one Sprint, one product. It scales by removing organisational structure rather than adding it, which makes it the most demanding framework to adopt and the closest to Scrum itself. The page opens with every rule and every event on one screen, then covers descaling and the product definition, feature teams and what LeSS removes, the ten principles, each event, LeSS Huge and its Requirement Areas, what four dated adoptions show, and where it degrades.
• ManagementNexusNexus is Scrum.org’s framework for three to nine Scrum teams building one product, and it adds exactly one accountability to Scrum: a Nexus Integration Team. Its premise is that at this scale integration, not planning, is what breaks first. The page opens with every Nexus element on one screen — each event and what it does to its Scrum counterpart, and the three artefacts with their commitments — then covers why the one addition, who is really on the Integration Team, each event as the 2021 Guide defines it and what changed from 2018, how to find and remove dependencies, how Nexus compares with LeSS, SAFe and Scrum@Scale, what the evidence shows and where it degrades.
• ManagementScrum@ScaleScrum@Scale is Jeff Sutherland’s framework for scaling Scrum to a whole organisation: twelve components on two linked cycles, one for what gets built, one for how. Teams group four or five at a time into a Scrum of Scrums, the same pattern repeats at every level, and at the top two leadership groups run as Scrum teams. The page opens with all twelve components on one screen — what each is for, who carries it and what it looks like when nobody does — then covers the scaled roles and events, each cycle, where the cycles meet, how to adopt it in the order your problems demand, how it compares with Nexus, LeSS and SAFe, what the evidence shows and where it degrades.