Scaling Agile: Essential SAFe

Why Scrum Alone Isn't Enough at Scale exam

This Part answers one question: what do you do when a product is too big for one Scrum team? The material comes from the Week 10 lecture (W10) and from Tutorial 10, whose NovaSuite case is worked in full in 11.13 and 11.14. The lecturer shows SAFe's huge "big picture" poster but calls it "a navigation map", not something to memorise. What you need for the exam is the concepts, roles and events, and above all the comparisons between Scrum and SAFe.

A Scrum refresher: what SAFe builds on

SAFe does not replace Scrum; it is built out of Scrum teams. So start with the single team (Part III has the full story). A Scrum team has three accountabilities. The Product Owner (PO) decides what is built and keeps the Product Backlog, an ordered list of everything the product might need. The Developers build it. The Scrum Master (SM) keeps the process healthy and removes obstacles. The team works in sprints, short fixed timeboxes, and each sprint turns the top of the backlog into an increment: a working, usable addition to the product.

Everything a Scrum team does is steered by the three pillars of empirical process control: transparency (everyone can see the real state of the work), inspection (it is checked often) and adaptation (the plan changes when the checks show it should). SAFe keeps all of this inside each team and adds a coordinating layer above the teams.

Two scenarios: TaskTidy and CareConnect+

The lecture makes the point with two products. TaskTidy is a small personal task app that one team can build with plain Scrum. CareConnect+ is a government-funded digital health platform that is far larger in scope, stakeholders and duration, and that size is exactly what makes it a case for SAFe. You will meet CareConnect+ again and again in this Part.

(An EHR is an electronic health record, the hospital's system of patient records. A stakeholder is anyone who affects or is affected by the project.)

What goes wrong as the number of teams grows

One team coordinates itself by talking across the desk every day. With three teams, a handful of conversations are needed. With eight or more, every team may need something from every other, and the number of links explodes. The W10 slides name the three problems that appear: dependencies increase, alignment becomes difficult, and shared architecture and delivery timelines need coordination. SAFe fills these gaps while keeping Agile values.

The CareConnect+ challenges and SAFe's answer to each exam

The slides list the questions CareConnect+ raises, and SAFe has an answer to each. Don't worry if the answers use unfamiliar names yet (ART, PI, RTE): each one gets its own section below, and this figure is the map of where you are heading.

What Essential SAFe Is

Once you accept that many teams need a coordinating layer, the next question is what that layer should contain. SAFe's answer is a fixed set of extra roles, events and artefacts. This section gives the definition, the map that lays them all out, and the seven key areas the lecture organises them into.

An artefact, as in Scrum, is a tangible thing the process produces or maintains, such as a backlog or a plan. An event is a scheduled meeting with a fixed purpose, such as a planning session or a demo.

The big-picture map

SAFe's poster crams every element onto one page. Simplified, it shows four groups of things stacked on top of each other: the roles that work across the whole train, the teams, the backlogs that feed them, and the timeline they all march to. Read the figure from top to bottom; every label is explained in a later section.

In words, the map highlights four groups:

• The ART roles are the Business Owners, Product Management, the System Architect and the RTE (Release Train Engineer).
• The team roles are the Agile Teams, the Product Owner and the Scrum Master/Team Coach.
• There are two kinds of backlog: the ART (Program) Backlog, which is prioritised with WSJF and constrained by NFRs (non-functional requirements, such as speed or security), and a Team Backlog for each team.
• The PI timeline runs from PI Planning, through iterations that each end in a System Demo, to an IP iteration with I&A. It produces PI Objectives and carries Features, Enablers and Stories. It sits under the continuous delivery pipeline (Continuous Exploration, Continuous Integration, Continuous Deployment, Release on Demand) and over the architectural runway.

The seven key areas of Essential SAFe exam

The lecture organises Essential SAFe around seven key areas. This is a counted list worth knowing by heart, because "name and explain the key areas" is an easy written question. Each gets its own section later in this Part.

1. PI Planning. All the ART's teams plan together and agree a shared plan (11.6).
2. Agile Release Train. A team of agile teams (50–125 people) that delivers in a synchronised way (11.3).
3. Roles and responsibilities. At train level: the RTE, Product Management, the System Architect and the Business Owners. At team level: the Scrum Master and the Product Owner (11.7).
4. Dependency management (Scrum of Scrums) coordinates work and resolves dependencies across teams (11.8).
5. Program Backlog. The prioritised Features that guide the ART during a PI (11.5).
6. System Demonstration. Teams demonstrate integrated work to stakeholders (11.9).
7. Inspect & Adapt workshop. At the end of each PI, the ART reviews progress, identifies improvements and plans the next increment (11.9).

What SAFe claims to deliver

The slides quote Scaled Agile's own figures, which also put SAFe's reach at over 1,000,000 practitioners in 20,000 companies. These are vendor claims: Scaled Agile sells SAFe training and certification, so treat the numbers critically, and say so if an exam answer uses them.

Qualitatively, the lecture credits SAFe with bringing alignment, transparency, a predictable cadence and integrated delivery, and with exposing dependencies and risks early. Those qualitative benefits are the ones to argue from in an answer, because they follow directly from SAFe's mechanisms.

The Agile Release Train (ART) exam

Five to twelve teams can't each go their own way and still produce one product. SAFe's first move is to bind them into a single long-lived unit that plans, commits and delivers together. That unit is the Agile Release Train, and nearly everything else in SAFe exists to run it.

The W10 slides list the ART's characteristics:

• It works in fixed-timebox PIs (Program Increments), 10 weeks by default, each made of 4–5 iterations. A timebox is a period whose length is fixed in advance and never extended.
• Its iterations and PIs are synchronised: every team shares the same iteration length and the same start and end dates, so that their work can be integrated. (An iteration is SAFe's name for a sprint.)
• It gets architectural and UX guidance from the System Architect. (UX is user experience: how the product looks and feels to use.)
• It produces frequent, evaluable system-level solutions, which are shown at the System Demo.
• It manages dependencies between teams.
• It is facilitated by the RTE (Release Train Engineer).

How the train is organised

The diagram shows how the ART-level roles relate to the teams, and how the teams' work comes together. Read it top to bottom: Business Owners and Product Management decide what matters, three kinds of influence flow down to the teams, and the teams' outputs converge into one integrated increment.

The train metaphor: dates are fixed, scope varies

The name is deliberate. A train leaves on schedule, whoever is late. For an ART this means the PI dates are fixed and what varies is the scope. A Feature that isn't ready doesn't delay everyone else; it simply catches the next train, the next PI. The slide's loop, "Define → Implement → Acceptance test → Deploy", repeats "until further notice", because the ART lives as long as its product.

Why 5–12 teams and 50–125 people?

The size limits follow the official SAFe rationale. With fewer than about five teams, the train's extra roles and events cost more than they save. The upper bound reflects Dunbar's number: the idea that people can keep up only about 150 stable relationships, so a train much bigger than 125 people stops being a group whose members know each other.

The Program Increment and the Shared Cadence

Teams can only integrate their work if they finish at the same moments. SAFe therefore gives the whole train one calendar: a longer timebox, the PI, divided into iterations that every team starts and ends together. The PI is to the train what the sprint is to one team.

One PI on the default cadence

The chart lays out one 10-week PI. Time runs across in weeks. The top row is what the teams do; the rows beneath are the train-wide events, which sit at fixed points on the calendar.

The cadence runs at two levels at once. On the program calendar, the whole ART holds PI Planning sessions, System Demos and Inspect & Adapt workshops. At team level, each of these has a smaller counterpart, held by every team inside every iteration.

Features, Enablers and the Program Backlog

A single Scrum backlog of user stories is too fine-grained to steer twelve teams: nobody can prioritise a thousand stories against a business strategy. SAFe adds a coarser layer of work item, the Feature, and one backlog of Features for the whole train. The teams still work on stories, but those stories now come from Features.

Features exam

A functional need is something the system does (show a list of courses); a non-functional need is a quality the system must have (load in under 3 seconds). The slides' example shows both inside one Feature.

Feature versus User Story

A Feature and a User Story differ in level, size and ownership. Getting these the wrong way round is a classic pitfall, so the figure lines them up.

Enablers and the architectural runway

Not every backlog item is something a user can see. Enablers appear on the SAFe map: they are backlog items with no direct user function, covering architecture, infrastructure, compliance or exploration. A new database cluster, a security audit or a technical experiment are enablers. Enablers extend the architectural runway, which is the technical foundation that lets upcoming features be built without redesign: like a runway that must be long enough before a plane can take off, the platform must be ready before the Features that need it. NFRs (non-functional requirements) constrain both backlogs, so every Feature and every Story must respect them.

The Program Backlog exam

Because it is a single backlog, it aligns all teams on one set of priorities, and it drives PI Planning, where the teams take the top Features. In PI Planning, Features are broken into Stories, which are spread across the teams by capacity, expertise and dependencies, and the Stories go into each team's Team Backlog, owned by its PO.

WSJF: ordering the Program Backlog

The map says the Program Backlog is prioritised with WSJF (Weighted Shortest Job First), but the slides don't explain it, so here is the method. The idea is economic: if two jobs are equally valuable, do the small one first, because its value starts flowing sooner; and if two jobs are the same size, do the one that hurts most to delay.

Time criticality is how fast the value decays if you wait (a feature tied to a deadline scores high). Risk reduction/opportunity enablement scores how much the job lowers risk or opens the door to future work. Job size is the relative effort.

A: 21 ÷ 3  = 7.0
B: 30 ÷ 10 = 3.0
C: 12 ÷ 2  = 6.0

PI Planning exam

If twelve teams plan separately, nobody discovers until integration that Team 4 needs an API that Team 9 never scheduled. PI Planning prevents that by putting every team in the same room for two days at the start of each PI, so that dependencies, risks and commitments are worked out together, face to face, before any code is written.

"Cadence-based" means it happens at a fixed rhythm, at the same point in every PI, so everyone can plan around it. Each participant has a part to play:

The inputs to PI Planning are the vision and business context, the top prioritised Features (from the Program Backlog), the architecture vision and team capacity (how much work each team can take on, given its size and availability).

The two days, step by step

The two-day agenda below and the outputs listed after it follow official SAFe; of the outputs, only the PI objectives appear on the slides' map. Step through it to see how a plan is drafted on day 1, stress-tested overnight and committed on day 2.

The four outputs

1. PI objectives are each team's (and the ART's) goals for the PI, written in business language. Business Owners score each one 1–10 for business value, and each objective is either committed or uncommitted (stretch). A committed objective is a promise; a stretch objective is planned in but may not be achieved.
2. The program board (in SAFe 6.0, the ART planning board) shows which team delivers each Feature in which iteration, plus milestones, with dependencies drawn as strings between teams.
3. Risks are ROAMed: each one is Resolved, Owned, Accepted or Mitigated (compare Part IV on risk responses).
4. The teams produce iteration plans and take a confidence vote (fist of five). If confidence is low, the plan is reworked.

What goes wrong without PI Planning exam

The slides list what goes wrong without PI Planning:

• Teams plan in isolation, and the vision drifts.
• Dependencies surface late, at integration, which leaves teams blocked and causes rework.
• The architecture diverges.
• There is no shared commitment, so delivery is unpredictable.
• Cross-team risks have no owner.

SAFe Roles exam

A coordinating layer needs people whose job is to coordinate. SAFe adds four roles that work across the whole train and keeps Scrum's three inside every team. Exam questions love the pairs: RTE versus Scrum Master, Product Management versus Product Owner. Learn each SAFe role together with its nearest Scrum role.

SAFe has four roles at ART level and three at team level. The last column links each one to its nearest Scrum role: two of the ART-level roles are Scrum roles scaled up, and the System Architect has no Scrum analogue at all.

Two terms in the table: an impediment (or blocker) is anything that stops a team making progress, such as a missing API, an unanswered question or a broken test server. Enterprise standards are the organisation-wide technical rules (approved languages, security practices, data formats) that every team must follow.

The RTE's five responsibilities

The Release Train Engineer is the role students most often misdescribe, so the slide gives it its own diagram of five responsibilities.

RTE versus Scrum Master exam

The RTE is the train's "Chief Scrum Master", but the two roles differ in scope, leadership, authority, dependencies and business alignment. Note in particular that the RTE facilitates rather than assigning work. A servant-leader leads by serving: clearing the way and helping others succeed rather than giving orders.

To escalate is to pass a problem up to someone with the authority to decide it, for example taking a priority clash between two teams to Product Management and the Business Owners.

Product Management versus Product Owner

Product Management faces customers and owns the Feature-level what and why for the whole train, while each team's PO turns Features into Stories and accepts them. There is one Product Management function per ART and one PO per team.

Dependency Management: Scrum of Scrums

Teams on a train depend on each other for parts of Features and for shared components, and unmanaged dependencies cause delays, rework and integration problems (W10). A dependency is any case where one team can't finish its work until another team delivers something. SAFe doesn't rely on a single mechanism for these; it deals with them at several points.

Scrum of Scrums

The last line of defence is a regular meeting between the teams. Scrum of Scrums (W10) exists to coordinate the teams within the ART. The slides call it a "Scrum for Scrum Masters": just as a team's Daily Scrum syncs its members, this syncs the teams.

• Participants: the Scrum Masters or other team representatives.
• Facilitator: the RTE.
• Frequency: weekly, and more often at critical times, for example around PI Planning.
• Topics: cross-team dependencies, risks and blockers, and progress.
• Outcome: shared understanding, aligned priorities and early risk mitigation.

System Demo and Inspect & Adapt exam

Twelve teams can each finish their stories and still produce a product that doesn't work, because the pieces were never put together. SAFe's two "inspect" events work at train level: the System Demo shows the integrated product, and Inspect & Adapt improves both the product and the way the train works. Each has a Scrum counterpart, and "compare" questions on these pairs are common.

System Demo versus Sprint Review

In the System Demo, all ART teams demonstrate the integrated solution, with everyone's features working together, to Product Management, Business Owners, the RTE and stakeholders. It validates progress towards the PI's goals and collects live feedback. In Scrum, the Sprint Review (the slides also say "Showcase") shows one team's increment.

Inspect & Adapt versus Sprint Retrospective

The I&A workshop is held at the end of every PI. The whole ART, together with Product Management, Business Owners, the RTE and stakeholders, reflects on product, process and people and realigns with business goals. A root-cause analysis, which the workshop uses, means asking "why?" repeatedly until you reach the underlying cause of a problem rather than its symptom.

The table compares the I&A with the Sprint Retrospective. The main differences are that the I&A covers the product as well as the process, deals with systemic cross-team issues, and includes a demo.

Mapping Scrum onto SAFe exam

The fastest way to remember SAFe is to see it as Scrum with one extra layer. Every Scrum artefact, event and role either survives inside the teams unchanged or gains a train-level counterpart. The three mappings below are the ones to put on your notes sheet. In the event and role figures, the right-hand column (shaded) is the coordinating layer SAFe adds above the teams.

Roles

Events

Artefacts and structures

(The Definition of Done is the team's agreed checklist of what "finished" means, such as tested, reviewed and documented. Sharing one across the train means a Story that is "done" in Team 3 is done by the same standard as in Team 7, which is what makes integration possible.)

Worked Example: CareConnect+ as an ART

Knowing the parts of SAFe is half of an exam answer; the other half is assembling them for a specific case. The guide's worked example does that for CareConnect+, the digital health platform from 11.1. Step through it: each step is one decision you would write in an answer.

The cadence arithmetic, written out: a month is about 52 ÷ 12 ≈ 4.33 weeks, so

18 months × 52/12 = 78 weeks    78 ÷ 10 weeks per PI = 7.8  ≈ 8 PIs
24 months × 52/12 = 104 weeks   104 ÷ 10 weeks per PI = 10.4 ≈ 10 PIs

The System Team is a team whose job is integration and DevOps for the whole train (building the shared test and delivery environment), rather than one module.

When Is SAFe Warranted? exam

The exam rarely asks "describe SAFe" on its own. It asks whether a given organisation should adopt it, and the right answer is often "no". This section gives you the signals to look for, the case against SAFe, the pitfalls examiners look for, and a seven-step answer structure.

A model answer structure

1. Identify the scale signals in the case (number of teams and people, dependencies, horizon, stakeholders, regulation).
2. Recommend Scrum or SAFe and justify the choice from those signals.
3. Design the ART: the teams and their size.
4. Assign the roles: RTE, Product Management, System Architect, Business Owners; a PO and SM per team.
5. Set the cadence: PI length, iterations, number of PIs.
6. Describe the events and what each fixes: PI Planning, Scrum of Scrums, System Demo, I&A, each tied to a problem in the case.
7. Note the risks, including SAFe's own (overhead, mini-waterfall).

Applying it to the Medic case

Medic is the tutorials' running case: a team of 12 developers plus 2 managers building a surgical simulator for surgeons at RVEEH, the client hospital, so that trainees can practise cochlear-implant and temporal-bone surgery without cadavers. The developers are inexperienced, and C++, stereoscopic 3D and haptics (force feedback) are all new to them (see Part I).

Medic has 12 inexperienced developers, one client group and one simulator, which makes at most two teams. SAFe is overkill. Instead, use Scrum with the Scrum Guide's multi-team guidance: one PO, one Product Backlog and a shared Definition of Done.

NovaSuite (T10): the Case and the Roles

Tutorial 10, held in Week 11, applies Essential SAFe to a new case, NovaSuite, through a four-question recap quiz and two team activities. The Week 12 revision lecture says that tutorial content is examinable including the case studies, so treat NovaSuite the way you treat Medic: know its facts well enough to use them in an answer.

The case in brief

TechNova is a mid-sized software company that has built its reputation running one or two Scrum teams on small and medium projects. Its new product, NovaSuite, is an integrated productivity and analytics suite for enterprise clients, built as four components by four Scrum teams working in parallel:

• a web dashboard, where administrators manage their staff's accounts and see charts and reports on usage, which they can download or schedule;
• a mobile app, a lighter iOS and Android companion with basic reporting, account management and push notifications, synced in real time with the web app and backend;
• a cloud backend, which stores user data, reports and settings securely, serves both apps in real time, and connects to third-party tools such as calendars and payment gateways;
• an AI insights module, which finds patterns in user behaviour, gives personalised recommendations and helps managers predict trends.

More than 40 people now work across the four teams. Leadership's strategic goal is to launch NovaSuite in six months with three key features: a unified dashboard for web and mobile, AI-powered recommendations, and integration with third-party services such as Google Drive and OneDrive.

The case groups its troubles under three headings, and each is one of the scaling problems from 11.1. Step through them.

The recap quiz

The four recap questions are single-answer polls. Each answer rests on a section above.

Activity 1: the SAFe roles at NovaSuite

Task 1 asks why each of five roles matters. Task 2 asks how each role would help with NovaSuite's challenges, and how it differs from the nearest role in single-team Scrum. The worked answers take the roles one at a time and cover both tasks together. The figure shows which problem each role attacks.

Is SAFe warranted at this size?

A strong answer notices that NovaSuite has four teams and a little over 40 people, just under the ART's usual 5–12 teams and 50–125 people (11.3, 11.12).

It then argues that Essential SAFe is still justified, because the four teams build one integrated product with heavy cross-team dependencies (the Backend team appears in all eight backlog Features, see 11.14), against a fixed strategic deadline, for a leadership that needs one view across the teams. Keep it to Essential SAFe and keep its events lean. The case says leadership judged scaling essential and the tutorial assumes SAFe, so answer within SAFe; but noticing the size shows the critical evaluation that the subject's learning outcomes ask for (see Part XII).

NovaSuite (T10): Designing PI Planning

Activity 2 is the closest thing in the subject to a full SAFe exam question. It works from the case's sample Program Backlog of eight Features and asks for three things: a program objective for the PI that aligns with the strategic goals, a plan of Features and team assignments, and the dependencies between teams and how you would manage them.

The sample Program Backlog

(Multi-factor authentication, MFA, asks for a second proof of identity such as a phone code; single sign-on, SSO, lets staff log in once with their company account.) Laid out as a grid, the backlog reveals the case's structural problem at a glance.

The program objective (official, T10 slide 14)

Notice the shape of this objective, because it is the pattern to copy. It is written in business language, it names outcomes rather than tasks, and it commits fully only to what one PI can deliver, taking the two harder launch features only as far as their foundations. It also includes push notifications (F-2), which is not one of the three launch features; the tutorial justifies it by user engagement, and it is work the Mobile team had already prioritised.

Worked plan: the roadmap

Assume the default 10-week PI from 11.4: four two-week iterations plus an IP iteration. Six months is about 26 weeks, or roughly two and a half PIs, so a sensible roadmap is the following.

Worked plan: the program board for PI 1

The program board for PI 1 might look like this; it is one reasonable plan, not the only one. Step through it iteration by iteration, then watch the dependency strings appear.

The PI objectives follow from the board:

The remaining Features, F-6 authentication, F-7 analytics and F-8 offline mode, wait for later PIs, where Product Management can rank them with WSJF (11.5). One judgement to raise at PI Planning is whether enterprise clients will insist on MFA and single sign-on (F-6) before launch; if the Business Owners say yes, F-6 has to come forward.

Dependencies and how they are managed

The diagram shows who supplies what to whom in PI 1. Each arrow runs from the team that provides something to the team that needs it, and the Backend team sits at the centre of almost all of them.

The dependencies are handled in the same few ways:

• Dashboard (F-1). The System Architect and the three teams agree the API contract on the first day of PI Planning; Backend delivers the API in Iteration 1, and Web and Mobile build against a stub until then. The program board shows this as a string from Backend's Iteration 1 to the consumers' Iteration 2.
• Notifications (F-2) get the same treatment, from Backend's Iteration 2 to Mobile's Iteration 3.
• Recommendations (F-3) run both ways: the AI team needs usage data from the backend, while Web and Mobile need a recommendation API to display the results. That is the dependency the case says the AI team didn't know about. Putting it on the board fixes it: the API is defined in Iteration 1, Backend's usage feed arrives in Iteration 2, and the AI team publishes a stub for Web and Mobile in Iteration 3.
• File upload (F-4), Mobile's blocked feature, is scheduled explicitly: the storage API in Iteration 3 and Mobile's integration in Iteration 4. That turns the case's open-ended wait into a dated commitment.
• Third-party integration (F-5) has an external dependency on the providers' APIs and access terms, so the Iteration 4 spike reduces that risk before PI 2 commits to it.

The biggest dependency is structural: the Backend team is involved in all eight Features, so its capacity is the train's bottleneck. Because every team plans to its own capacity at PI Planning, Backend's overload shows up at the first day's draft plan review. Management problem-solving then makes the trade-off openly, for example by deciding whether the analytics database scaling that blocked Mobile belongs in this PI at all, by moving people into Backend, or by having the System Architect simplify the interfaces. In the case, that trade-off was made silently inside one team. Throughout the PI, the weekly Scrum of Scrums (the RTE and the four Scrum Masters) walks the strings on the program board, a System Demo each iteration shows the integrated dashboard on both platforms, and the I&A at the end of the PI measures the objectives and feeds PI 2's planning.

The risks, ROAMed

The main risks are ROAMed before the confidence vote (11.6):