SAFE-SPC Practice Questions

One of the key measures of success in Design Thinking, as highlighted in SAFe, is whether the

solution is “desirable”—that is, if it meets real customer needs. Desirability is one of the three core

aspects evaluated (desirable, feasible, viable) in Design Thinking.

Reference:

SAFe 6.0, “Design Thinking” article

SPC 6.0 Guide, “Building Solutions with Agile Product Delivery”

===========

SAFe promotes continuous delivery and recommends releasing products and solutions whenever

they meet both business (market) and governance criteria, regardless of iteration or PI boundaries.

This enables faster value delivery and more frequent feedback from customers.

“The best time to release is whenever the solution meets market opportunity and governance

requirements, not necessarily at PI or iteration boundaries.”

(Source: SAFe 6.0 Framework: Release on Demand; SPC 6.0 Guide, “Building Solutions with Agile

Product Delivery”)

The Continuous Delivery Pipeline in SAFe includes four steps: Continuous Exploration, Continuous

Integration, Continuous Deployment, and Release on Demand. “Deploy” is the activity most directly

associated with the “Release on Demand” step, where solutions are made available to end users

whenever the business needs it.

Reference:

SAFe 6.0, “Release on Demand” in the “Continuous Delivery Pipeline” article

SPC 6.0 Guide, “Building Solutions with Agile Product Delivery”

===========

In SAFe 6.0, Capabilities are defined as "higher-level solution behaviors that typically span multiple

ARTs." They are maintained in the Solution Train Backlog and are sized and split into Features for

implementation by individual ARTs. The SAFe 6.0 guidance specifically states:

“Capabilities are larger solution behaviors that often span multiple Agile Release Trains. They are

typically sized to be delivered in a Planning Interval (PI) and are broken down into Features to

facilitate implementation.”

This distinguishes Capabilities from Epics and Features. Unlike Epics, which require Lean Business

Cases and approval through Portfolio Kanban, Capabilities follow a breakdown path to Features for

execution. Therefore, they are a level above Features, not a synonym for Epics or Features.

Reference:

SAFe 6.0 Website: Capabilities

SAFe Practice Consultant SPC (6.0) Training Guide — "Building Solutions with Agile Product Delivery"

Module

Terminology Update: "Solution Backlog" → "Solution Train Backlog" confirms the hierarchical

location of Capabilities

The ROAM technique (Resolved, Owned, Accepted, Mitigated) is used during Planning Interval (PI)

Planning to manage and categorize ART PI Risks. In the PI Planning session, all identified risks are

discussed and then categorized using the ROAM framework, which helps teams and stakeholders

clarify ownership, mitigation strategies, and acceptance of each risk. According to the SAFe 6.0

official guidance:

"During PI Planning, teams identify program risks and then use the ROAM technique to classify each

risk as Resolved, Owned, Accepted, or Mitigated. This collaborative activity ensures transparency and

allows teams to address significant risks before proceeding."

This activity does not take place during backlog refinement, ART syncs, or general team

management; it is specific to the PI Planning event.

Reference:

SAFe 6.0 Website: PI Planning and ROAM

SAFe Practice Consultant SPC (6.0) Training Guide — "Launching an Agile Release Train" Module

New Terminology: "Program PI Risks" are now referred to as "ART PI Risks"

Features in SAFe should be right-sized, delivering value and being small enough for incremental

delivery within a PI. If the current backlog items are too large (“big tasks”), the best technique is to

split them into smaller, more manageable Features. This enables meaningful WSJF prioritization and

supports flow-based delivery.

Reference:

SAFe 6.0 Website: Features and Capabilities

SPC 6.0 Guide: “Right-size Features to fit within a PI for effective prioritization and delivery.”

===========

A: Business Owners assign business value to PI Objectives during PI Planning, ensuring alignment

with business priorities and objectives.

B: Business Owners participate in PI events (including Post-PI Planning) and help ARTs adjust plans to

better meet business needs.

Assigning value to Epics/Features (C) is the responsibility of Product Management. Ensuring the

Solution Demo (D) is a shared leadership responsibility, not specific to Business Owners. Determining

the roadmap (E) is owned by Product Management.

Reference:

SAFe 6.0 Website: Business Owners

SPC 6.0 Guide: “Business Owners assign business value to objectives and participate in PI Planning

and ART events.”

===========

SAFe’s guidance for new teams without historical velocity is to assign 8–12 points per team member

(typically 10) except Scrum Master and Product Owner, subtracting points for planned absences.

“For initial velocity, a simple guideline is to assume 8–12 points per team member (excluding Scrum

Master and Product Owner), then subtract 1 point for each day of vacation or holiday.”

(Source: SAFe 6.0 Framework: PI Planning Preparation)

The Innovation and Planning (IP) Iteration is a vital part of SAFe’s Program Increment (PI) cycle. Its

main purposes include innovation, planning for the next PI, and supporting activities such as

continuing education, infrastructure work, and hackathons. While it can be used for fixing defects or

technical work, its explicit inclusion of continuing education distinguishes it from routine

development.

Reference:

SAFe 6.0, “Innovation and Planning Iteration” article

SPC 6.0 Practice Guide, “Coaching ART Execution”

===========

Little’s Law is a fundamental concept in Lean and flow-based systems. It states that the average wait

time (Lead Time) in a queue or process is proportional to the number of items in the system (Work in

Process, WIP) divided by the average processing rate. The easiest, most direct way to achieve better

flow (reduce wait time) is to reduce the queue length (WIP). SAFe 6.0 specifically cites Little’s Law as

the basis for limiting WIP to optimize flow.

Other options are incorrect or incomplete:

B is false; long queues increase wait time.

C is only partially true but not always possible; reducing queue length is usually easier and more

controllable.

D is incorrect; Little's Law applies to average, stable systems, not varying rates.

E is unrelated to Little’s Law specifically.

Reference:

SAFe 6.0 Website: Principle #6 – Visualize and limit WIP, reduce batch sizes, and manage queue

lengths

SPC 6.0 Guide: “Little’s Law demonstrates that reducing queue length is the fastest way to reduce

wait time and improve flow.”

===========