The portfolio Vision is an aggregation of every Agile Release Train's Vision?
B
Explanation:
The portfolio Vision is not simply an aggregation of the ARTs’ Visions. Instead, the portfolio Vision is a
higher-level, strategic expression of the portfolio’s direction and purpose, informed by the enterprise
strategy and objectives. While ART Visions may align to and support the portfolio Vision, the
portfolio Vision is created at the portfolio level and provides the overall context for the ARTs, not the
other way around.
Reference:
SAFe 6.0 Website: Portfolio Vision
SPC 6.0 Guide: “The portfolio vision provides strategic direction for all value streams and ARTs, and is
not merely the sum of ART visions.”
===========
(Select 2) What applies to the Portfolio Backlog?
C, D
Explanation:
C: The Portfolio Backlog is used as a low-cost holding area for approved Business and Enabler Epics
until they are ready for implementation, avoiding premature commitment of resources.
D: Weighted Shortest Job First (WSJF) is the recommended method for prioritizing Epics in the
Portfolio Backlog, balancing the cost of delay and job size to deliver maximum value.
Option A is incorrect because the Portfolio Kanban holds Epics, not Capabilities (which are managed
at the Solution/ART level). Option B is incorrect because programs do not wait to exhaust the
Portfolio Backlog before working on local priorities; local priorities are managed at the ART level.
Reference:
SAFe 6.0 Website: Portfolio Backlog
SPC 6.0 Guide: “Epics are held in the Portfolio Backlog and prioritized using WSJF.”
===========
When does the System Demo happen?
B
Explanation:
The System Demo is a key event in SAFe that happens at the end of every iteration. It provides an
integrated view of the new features delivered by all the teams in the Agile Release Train during the
most recent iteration. This demonstration allows stakeholders to evaluate the solution’s progress and
provide feedback.
Reference:
SAFe 6.0 Website: System Demo
SPC 6.0 Guide: “System Demos occur at the end of every iteration, providing feedback on the fully
integrated solution increment.”
===========
Test automation is typically included in the Definition of Done (DoD).
A
Explanation:
Test automation is a best practice in SAFe and is typically included in the Definition of Done (DoD).
The DoD ensures that all work is tested and validated before being considered complete. Including
test automation in the DoD supports continuous integration, reduces manual testing effort, and
increases the reliability of every increment.
Reference:
SAFe 6.0 Website: Built-in Quality
SPC 6.0 Guide: “Definition of Done includes automated testing to ensure built-in quality.”
(Select 2) When might Feature size not be a good substitute for the duration of WSJF?
B, D
Explanation:
WSJF (Weighted Shortest Job First) uses job size or duration as the denominator to prioritize work.
SAFe often uses feature size (story points) as a proxy for duration. However, this is not always
accurate:
B: If a Feature involves a team or member who is a bottleneck, the actual duration may be longer
than estimated by size, due to limited availability.
D: If a Feature depends on a remote third-party vendor with formal approval processes, duration may
be impacted by external delays not reflected in the feature’s size.
Options A, C, and E do not directly impact the suitability of size as a proxy for duration.
Reference:
SAFe 6.0 Website: WSJF
SPC 6.0 Guide: “Use feature size as a proxy for duration unless bottlenecks or dependencies (e.g.,
with external vendors) distort that relationship.”
===========
(Select 3) Which of the following have acceptance criteria?
A, D, F
Explanation:
A . Business Capabilities: In SAFe, Capabilities (including Business Capabilities) are large solution
behaviors that have acceptance criteria to ensure they are fully defined and testable.
D . Enabler Features: All Features, including Enabler Features, require acceptance criteria to clarify
when the Feature is done.
F . Program Epics: Epics require acceptance criteria to define the conditions for completion and
evaluation.
Portfolio Enabler Epics (B) have a higher-level definition and are not typically assigned granular
acceptance criteria. Strategic Themes (C) and Spikes (E) do not have acceptance criteria; Spikes are
research items.
Reference:
SAFe 6.0 Website: Features and Capabilities
SPC 6.0 Guide: “Each Feature, Capability, and Epic should have clear acceptance criteria.”
===========
Your organization decided to thoroughly implement the SAFe Principle "Assume variability; preserve
options." What is the optimum path for success?
D
Explanation:
SAFe Principle #3 states: “Assume variability; preserve options.” The optimum path is to preserve
flexibility in both system functionality and design as long as possible, enabling better decision-
making with more information and reducing the risk of suboptimal solutions.
The other options either fix one dimension or another, which is contrary to the principle.
Reference:
SAFe 6.0 Website: SAFe Principles
SPC 6.0 Guide: “Maintain options in both design and requirements for as long as economically
feasible.”
===========
What is the correct statement about Work in Process (WIP)?
C
Explanation:
Lowering WIP limits reduces multitasking, exposes bottlenecks, and encourages team members to
collaborate to finish work before starting new work. This is a core Lean and SAFe principle to increase
flow and throughput.
A is incorrect; excessive WIP delays feedback. B is incorrect; WIP is highly related to utilization and
flow.
Reference:
SAFe 6.0 Website: Team Kanban
SPC 6.0 Guide: “Lowering WIP limits increases collaboration and speeds up flow.”
What does Little's Law tell us?
A
Explanation:
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.”
===========
The Spanning Palette can apply to the Team Level.
A
Explanation:
The Spanning Palette is a set of roles and artifacts that may apply across multiple SAFe levels,
including Team, ART, Solution Train, and Portfolio. The Spanning Palette includes functions like
System Architect, Release Management, Shared Services, and more. SAFe explicitly notes that these
elements are used “as needed at each level, including the Team level, depending on context.”
Reference:
SAFe 6.0 Website: Spanning Palette
SPC 6.0 Guide: “Spanning Palette elements are used across one or more SAFe levels, including the
Team level.”
===========