Free SAFE-SPC Practice Test

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.” ===========