Scenario practice questions

A SAFe Agile Release Train (ART) is seeing Cycle Time stretch from eight to fourteen days over three Program Increments, even though each team reports being fully utilized. Work is piling up in the Product Owner's "ready" column, and reviews of finished items are being scheduled only after every dependency is resolved. What is the most likely cause of the lengthening Cycle Time?

Trap 1: The Product Owner is applying weighted shortest job first when…

Weighted shortest job first is a recommended economic prioritization technique that tends to reduce average Cycle Time by sequencing smaller, higher-value items first. Treating it as the cause of lengthening Cycle Time inverts its purpose. The observed symptom of growing queues behind uneven capacity is not a prioritization-order problem, so this distractor fails.

Trap 2: The ART has not adopted a formal capacity allocation policy for…

Capacity allocation (for example, a percentage split between features and enablers) governs what type of work enters the backlog; it does not by itself explain growing Cycle Time when teams report full utilization and queues are building. The scenario points to flow mechanics rather than backlog composition, so this is a plausible but incorrect root cause here.

Trap 3: The ART has too few System Team members to support continuous…

An understaffed System Team can slow integration, but the scenario describes work waiting in the ready column and reviews deferred until all dependencies resolve, which is a demand-versus-capacity and batch-size issue rather than a tooling or staffing constraint. Assigning more System Team members would not address the accumulating queue, so this is not the best diagnosis.

A
The ART has optimized individual team utilization instead of limiting Work in Process across the full value stream.
When every team is pushed to 100 percent utilization, queues accumulate wherever capacity is uneven, so items wait longer in the ready column and before integration. SAFe's Flow principle asks the ART to visualize and limit Work in Process at the value-stream level, not just inside each team, so excess demand cannot silently become wait time. The scenario shows exactly that symptom, making this the correct diagnosis.
B
The Product Owner is applying weighted shortest job first when ordering the program backlog.
Why it fails: Weighted shortest job first is a recommended economic prioritization technique that tends to reduce average Cycle Time by sequencing smaller, higher-value items first. Treating it as the cause of lengthening Cycle Time inverts its purpose. The observed symptom of growing queues behind uneven capacity is not a prioritization-order problem, so this distractor fails.
C
The ART has not adopted a formal capacity allocation policy for enablers and features.
Why it fails: Capacity allocation (for example, a percentage split between features and enablers) governs what type of work enters the backlog; it does not by itself explain growing Cycle Time when teams report full utilization and queues are building. The scenario points to flow mechanics rather than backlog composition, so this is a plausible but incorrect root cause here.
D
The ART has too few System Team members to support continuous integration.
Why it fails: An understaffed System Team can slow integration, but the scenario describes work waiting in the ready column and reviews deferred until all dependencies resolve, which is a demand-versus-capacity and batch-size issue rather than a tooling or staffing constraint. Assigning more System Team members would not address the accumulating queue, so this is not the best diagnosis.

Question 2mediummultiple choice

A Release Train Engineer (RTE) notices that the ART consistently meets its PI Objectives, yet stakeholders complain about long delays between feature ideation and delivery. The RTE reviews the Value Stream and finds that features frequently wait in a 'ready' queue for weeks before development begins, even though teams are not fully utilized. Which action best addresses this situation according to SAFe's Product Development Flow principles?

Trap 1: Implement a new tool to track features more accurately in the ready…

Better tracking does not reduce queue size or wait time; it merely provides visibility. While visibility can be useful, the core issue is too much WIP in the ready state. Without limiting WIP and changing the pull system, the queue will persist. SAFe focuses on flow optimization through WIP limits and pull, not just improved monitoring.

Trap 2: Ask teams to work overtime to clear the ready queue faster.

Overtime can temporarily increase throughput but often leads to burnout, defects, and reduced sustainability. It does not address the root cause of excessive WIP and queue buildup. SAFe emphasizes sustainable pace and systemic flow improvements, not short-term heroics. Thus, this action fails to create lasting flow improvement and may worsen variability.

Trap 3: Increase the number of features in the Program Backlog to keep…

Adding more features to the Program Backlog increases work-in-process (WIP) and exacerbates queueing delays. In SAFe, excess WIP is a primary cause of long lead times. The scenario already shows a large ready queue; adding more items would further increase wait times and reduce flow efficiency, contrary to the goal of optimizing Product Development Flow.

A
Apply WIP limits to the 'ready' queue and pull features into development only when capacity is available.
Limiting WIP in the ready queue directly reduces the queue size and wait time, as described by Little's Law. In SAFe, controlling WIP is a key practice for improving flow. By pulling work only when capacity exists, the ART avoids overloading the system and shortens the lead time from ideation to delivery, aligning with Product Development Flow principles.
B
Implement a new tool to track features more accurately in the ready queue.
Why it fails: Better tracking does not reduce queue size or wait time; it merely provides visibility. While visibility can be useful, the core issue is too much WIP in the ready state. Without limiting WIP and changing the pull system, the queue will persist. SAFe focuses on flow optimization through WIP limits and pull, not just improved monitoring.
C
Ask teams to work overtime to clear the ready queue faster.
Why it fails: Overtime can temporarily increase throughput but often leads to burnout, defects, and reduced sustainability. It does not address the root cause of excessive WIP and queue buildup. SAFe emphasizes sustainable pace and systemic flow improvements, not short-term heroics. Thus, this action fails to create lasting flow improvement and may worsen variability.
D
Increase the number of features in the Program Backlog to keep teams busy and reduce idle time.
Why it fails: Adding more features to the Program Backlog increases work-in-process (WIP) and exacerbates queueing delays. In SAFe, excess WIP is a primary cause of long lead times. The scenario already shows a large ready queue; adding more items would further increase wait times and reduce flow efficiency, contrary to the goal of optimizing Product Development Flow.

Question 3easymultiple choice

A SAFe Practitioner is analyzing a value stream and notices that work items often wait in a queue before being deployed to production. The team has automated testing and continuous integration, but deployment still requires manual approval from a change advisory board (CAB) that meets only once a week. What is the primary flow issue in this scenario?

Trap 1: The deployment process is not automated, causing manual errors.

The scenario mentions that deployment requires manual approval, but it does not state that the deployment itself is manual or error-prone. The issue is the waiting time for approval, not the execution of deployment. Automating deployment would not eliminate the weekly CAB queue. The primary flow issue is the approval bottleneck.

Trap 2: The team is not using a Program Kanban to visualize work.

While visualizing work is important, the scenario does not indicate that lack of a Kanban is the cause of delays. The specific delay is due to the weekly CAB meeting. Even with a Kanban, the queue would persist. The root cause is the approval process, not the visualization tool. SAFe emphasizes addressing the actual constraint, not just visualizing it.

Trap 3: The team lacks automated testing, causing delays.

The scenario states that automated testing and continuous integration are already in place. Therefore, the delay is not due to missing automated testing. The bottleneck is the weekly CAB meeting, which introduces a long queue between development and deployment. Focusing on testing would not address the actual constraint in the flow.

A
The deployment process is not automated, causing manual errors.
Why it fails: The scenario mentions that deployment requires manual approval, but it does not state that the deployment itself is manual or error-prone. The issue is the waiting time for approval, not the execution of deployment. Automating deployment would not eliminate the weekly CAB queue. The primary flow issue is the approval bottleneck.
B
The team is not using a Program Kanban to visualize work.
Why it fails: While visualizing work is important, the scenario does not indicate that lack of a Kanban is the cause of delays. The specific delay is due to the weekly CAB meeting. Even with a Kanban, the queue would persist. The root cause is the approval process, not the visualization tool. SAFe emphasizes addressing the actual constraint, not just visualizing it.
C
The change advisory board (CAB) is a bottleneck that introduces a long queue and delays flow.
The weekly CAB meeting creates a waiting period for deployment approval, which is a classic queue. In SAFe, such approval gates often become bottlenecks that increase lead time and reduce flow. To improve flow, the organization should consider decentralizing approvals or automating compliance checks, enabling faster deployment and reducing batch size.
D
The team lacks automated testing, causing delays.
Why it fails: The scenario states that automated testing and continuous integration are already in place. Therefore, the delay is not due to missing automated testing. The bottleneck is the weekly CAB meeting, which introduces a long queue between development and deployment. Focusing on testing would not address the actual constraint in the flow.

Question 4easymultiple choice

A newly formed Agile Release Train (ART) is struggling with frequent integration issues because teams are developing components independently and only integrating at the end of the Program Increment (PI). The Release Train Engineer (RTE) wants to apply a SAFe Lean-Agile Principle to address this. Which principle should the RTE emphasize to improve integration and reduce risk?

Trap 1: Assume variability; preserve options

Assuming variability and preserving options is about keeping design options open and using set-based design to manage uncertainty. While this can help with integration by allowing flexibility, it does not directly mandate frequent integration. The scenario's issue is that integration is delayed until the end of the PI, causing issues. The principle that best addresses this is about cadence and synchronization, which encourages regular integration points. Preserving options is more about design decisions than integration frequency.

Trap 2: Apply systems thinking

Applying systems thinking helps understand the whole system and how parts interact, but it does not directly prescribe the practice of frequent integration. While systems thinking would highlight the integration problem, the principle that specifically addresses it is 'Assume variability; preserve options' or 'Apply cadence, synchronize with cross-domain planning'. However, the most direct principle for frequent integration is not systems thinking alone; it is more about building quality in through continuous integration, which aligns with 'Apply cadence, synchronize with cross-domain planning' by synchronizing integration points.

Trap 3: Unlock the intrinsic motivation of knowledge workers

Unlocking intrinsic motivation focuses on empowering and engaging employees, which can lead to better collaboration, but it does not provide a structural solution for integration issues. The problem described is about delayed integration due to lack of synchronization, not about motivation. While motivated teams might communicate better, the principle that directly addresses the need for regular integration points is cadence and synchronization. Therefore, this principle is not the best fit for the scenario.

A
Apply cadence, synchronize with cross-domain planning
Applying cadence and synchronizing with cross-domain planning means establishing regular, synchronized events like PI Planning and System Demos, which include integration points. By integrating frequently—at least at the end of each iteration and during the PI—teams can detect and resolve integration issues early. This principle directly addresses the problem of teams integrating only at the end of the PI by promoting a rhythm of integration and synchronization across teams, reducing risk and improving quality.
B
Assume variability; preserve options
Why it fails: Assuming variability and preserving options is about keeping design options open and using set-based design to manage uncertainty. While this can help with integration by allowing flexibility, it does not directly mandate frequent integration. The scenario's issue is that integration is delayed until the end of the PI, causing issues. The principle that best addresses this is about cadence and synchronization, which encourages regular integration points. Preserving options is more about design decisions than integration frequency.
C
Apply systems thinking
Why it fails: Applying systems thinking helps understand the whole system and how parts interact, but it does not directly prescribe the practice of frequent integration. While systems thinking would highlight the integration problem, the principle that specifically addresses it is 'Assume variability; preserve options' or 'Apply cadence, synchronize with cross-domain planning'. However, the most direct principle for frequent integration is not systems thinking alone; it is more about building quality in through continuous integration, which aligns with 'Apply cadence, synchronize with cross-domain planning' by synchronizing integration points.
D
Unlock the intrinsic motivation of knowledge workers
Why it fails: Unlocking intrinsic motivation focuses on empowering and engaging employees, which can lead to better collaboration, but it does not provide a structural solution for integration issues. The problem described is about delayed integration due to lack of synchronization, not about motivation. While motivated teams might communicate better, the principle that directly addresses the need for regular integration points is cadence and synchronization. Therefore, this principle is not the best fit for the scenario.

Question 5mediummultiple choice

Which of the following scenarios best demonstrates a 'pull' system in a SAFe ART?

Trap 1: The manager assigns tasks to team members based on their…

Manager-assigned tasks represent a 'push' system, where work is forced onto individuals regardless of their current workload or capacity. This often results in overloaded teams and long queues. A pull system relies on team members picking up work when they are ready, which is more effective for flow.

Trap 2: The team completes as much work as possible before the end of the…

Trying to complete as much as possible often leads to a 'push' mentality, where items are started without concern for system capacity. This causes multitasking and increases the likelihood of incomplete items at the end of the iteration. Pull systems prioritize finishing items over simply starting as many as possible.

Trap 3: The product owner dictates the exact sequence of all tasks for the…

Dictating a sequence ignores the reality of capacity and variability. A pull system allows the team to react to their actual current state. Top-down sequencing forces work into the system, which can create bottlenecks if the capacity does not match the planned demand, leading to inefficient resource utilization.

A
The manager assigns tasks to team members based on their availability.
Why it fails: Manager-assigned tasks represent a 'push' system, where work is forced onto individuals regardless of their current workload or capacity. This often results in overloaded teams and long queues. A pull system relies on team members picking up work when they are ready, which is more effective for flow.
B
The team pulls work into their process only when they have the capacity to address it.
A pull system is characterized by teams taking on new work only when they have available capacity. This prevents the accumulation of work-in-progress, keeps queues short, and ensures that work items move through the system steadily. It is the core mechanism for maintaining flow in a Kanban-based delivery model.
C
The team completes as much work as possible before the end of the iteration.
Why it fails: Trying to complete as much as possible often leads to a 'push' mentality, where items are started without concern for system capacity. This causes multitasking and increases the likelihood of incomplete items at the end of the iteration. Pull systems prioritize finishing items over simply starting as many as possible.
D
The product owner dictates the exact sequence of all tasks for the next month.
Why it fails: Dictating a sequence ignores the reality of capacity and variability. A pull system allows the team to react to their actual current state. Top-down sequencing forces work into the system, which can create bottlenecks if the capacity does not match the planned demand, leading to inefficient resource utilization.

Question 6mediummultiple choice

A large financial services organization is transitioning to SAFe. During a Lean Portfolio Management workshop, the CFO argues that the portfolio should only fund projects with a guaranteed positive return on investment, and that any investment in emerging technologies with uncertain outcomes should be deferred. The SAFe Program Consultant (SPC) explains that this approach conflicts with a core Lean-Agile Principle. Which principle is being violated?

Trap 1: Unlock the intrinsic motivation of knowledge workers

Unlocking intrinsic motivation focuses on creating an environment where employees are engaged, autonomous, and purpose-driven. The CFO's investment strategy does not directly undermine motivation; it is an economic policy. While it might indirectly affect morale, the primary conflict is with economic decision-making, not with how people are motivated. Thus, this principle is not the best answer for this scenario.

Trap 2: Decentralize decision-making

Decentralizing decision-making means pushing decisions to the lowest possible level while maintaining strategic alignment. The CFO's centralized control over funding decisions could be seen as a violation, but the core issue is not about who decides—it is about the economic reasoning used. Even if decisions were decentralized, the same flawed economic logic would persist. Therefore, this principle is not the most directly violated.

Trap 3: Apply cadence, synchronize with cross-domain planning

Cadence and synchronization are about aligning teams through regular planning intervals, not about how investment decisions are made across a portfolio. The CFO's stance on funding only guaranteed returns is an economic decision-making issue, not a planning rhythm issue. While cadence supports predictability, it does not address the need to make economic trade-offs under uncertainty, so this principle is not the primary one being violated here.

A
Take an economic view
Taking an economic view requires understanding the economics of the entire value stream and making decisions that maximize economic outcomes, including considering opportunity costs and the cost of delay. By insisting on guaranteed returns and deferring uncertain investments, the CFO is ignoring the economic value of optionality and the potential cost of delaying entry into emerging markets. This directly contradicts the principle of applying an economic view to all decisions.
B
Unlock the intrinsic motivation of knowledge workers
Why it fails: Unlocking intrinsic motivation focuses on creating an environment where employees are engaged, autonomous, and purpose-driven. The CFO's investment strategy does not directly undermine motivation; it is an economic policy. While it might indirectly affect morale, the primary conflict is with economic decision-making, not with how people are motivated. Thus, this principle is not the best answer for this scenario.
C
Decentralize decision-making
Why it fails: Decentralizing decision-making means pushing decisions to the lowest possible level while maintaining strategic alignment. The CFO's centralized control over funding decisions could be seen as a violation, but the core issue is not about who decides—it is about the economic reasoning used. Even if decisions were decentralized, the same flawed economic logic would persist. Therefore, this principle is not the most directly violated.
D
Apply cadence, synchronize with cross-domain planning
Why it fails: Cadence and synchronization are about aligning teams through regular planning intervals, not about how investment decisions are made across a portfolio. The CFO's stance on funding only guaranteed returns is an economic decision-making issue, not a planning rhythm issue. While cadence supports predictability, it does not address the need to make economic trade-offs under uncertainty, so this principle is not the primary one being violated here.

Question 7mediummultiple choice

Refer to the exhibit. Based on Little's Law, what is the estimated Lead Time for the current backlog?

Exhibit

Team Velocity: 40
Work Items in Queue: 120
Cycle Time: 3 weeks
Work Item Age: 1 week

Trap 1: 1 week

This ignores the relationship defined by Little's Law. If the throughput is 40, it will take three cycles of that velocity to clear a queue of 120 items. 1 week is insufficient given the current volume of work waiting in the queue to be processed by the team.

Trap 2: 2 weeks

This result does not match the calculation of WIP divided by throughput. Based on the provided data of 120 items and a velocity of 40, the math yields 3, not 2. Relying on incorrect estimates leads to poor planning and failed commitments in the Program Increment.

Trap 3: 4 weeks

This calculation is incorrect. 4 weeks would imply a throughput of 30, which does not align with the team's velocity of 40. Using inaccurate metrics for planning creates an unrealistic roadmap and forces the team into a state of constant 'catch-up' that damages morale and decreases overall flow quality.

A
1 week
Why it fails: This ignores the relationship defined by Little's Law. If the throughput is 40, it will take three cycles of that velocity to clear a queue of 120 items. 1 week is insufficient given the current volume of work waiting in the queue to be processed by the team.
B
2 weeks
Why it fails: This result does not match the calculation of WIP divided by throughput. Based on the provided data of 120 items and a velocity of 40, the math yields 3, not 2. Relying on incorrect estimates leads to poor planning and failed commitments in the Program Increment.
C
3 weeks
Little's Law is applied by dividing the WIP (120) by the Throughput (40), resulting in 3. This metric helps the team understand the expected time it will take for the current backlog to be completed, enabling more accurate forecasting and setting realistic expectations for stakeholders regarding the delivery of features.
D
4 weeks
Why it fails: This calculation is incorrect. 4 weeks would imply a throughput of 30, which does not align with the team's velocity of 40. Using inaccurate metrics for planning creates an unrealistic roadmap and forces the team into a state of constant 'catch-up' that damages morale and decreases overall flow quality.