Refer to the Exhibit Practice Questions

The capacity allocation for Enablers is too high.

Why it fails: A 10% allocation for Enablers is actually quite conservative. If the Architectural Runway is depleted, the team may need to significantly increase this percentage to address technical debt and build the necessary infrastructure. Lowering it would exacerbate the existing runway deficiency and increase future technical risks.

The team capacity is currently underutilized.

Why it fails: The logs provide no information regarding team capacity or utilization rates. Inferring underutilization from an Architectural Runway status is a logical fallacy. The focus should remain on the technical readiness and the sequence of work required to ensure the upcoming PI is technically and operationally feasible.

The Program Board is not accurately updated.

Why it fails: While the Program Board tracks dependencies, the exhibit logs pertain to technical infrastructure and readiness, not the visualization of dependencies. The primary concern identified by the log is the state of the infrastructure, not the administrative status or the accuracy of the board's existing dependency mappings.

Reschedule the PI Planning event to next month.

Why it fails: Rescheduling PI Planning is a significant disruption that should be a last resort. The PM should first attempt to address the backlog and architectural runway issues by intensifying collaboration with the System Architect and Product Owners to refine the highest priority items and define necessary enablers immediately.

Direct the teams to work on technical debt during the first iteration.

Why it fails: Directing teams to work on technical debt without proper prioritization against new business value is poor practice. The PM must instead work to ensure that essential enablers are in the backlog so that the ART can decide how to best incorporate them into the upcoming PI plan.

Ignore the status and proceed with the current backlog.

Why it fails: Proceeding with an unprepared backlog and insufficient runway is a recipe for failure. It leads to poor planning, unrealistic objectives, and significant risks during the PI. The PM must recognize these indicators as critical blockers and take decisive action to prepare the ART for a successful planning session.

Feature F1

Why it fails: F1 has a score of 2.5, which is lower than the score of 3.0 for F3. Prioritizing F1 before F3 means delivering less value per unit of effort. The goal is to sequence based on the highest WSJF score to optimize the overall value delivery for the PI.

Feature F2

Why it fails: F2 has the lowest WSJF score of 1.0. This indicates that despite its high Cost of Delay, its large size makes it the least efficient choice relative to the others. Prioritizing it first would result in suboptimal value delivery for the program during the critical early stages of the PI.

Feature F2 and F1 combined

Why it fails: Combining features is not a valid approach to WSJF prioritization. Each item must be assessed individually based on its own cost and size. Attempting to group them ignores the specific economic profiles of each feature, leading to inaccurate prioritization and potentially missing the opportunity to deliver higher value first.

It guarantees that the features will be finished on time.

Why it fails: No amount of preparation can guarantee a finish date in complex environments. These criteria reduce risk and improve estimation accuracy, but they do not eliminate the inherent uncertainty of software development. They provide a sound basis for planning, but execution remains subject to reality and ongoing adjustments.

It removes the need for any further communication during the PI.

Why it fails: Agile is built on constant communication. Having ready features is a foundation for planning, but it does not replace the ongoing collaboration, feedback loops, and adjustments that occur during the PI. Continuous communication remains essential to manage changes and ensure the delivered value meets user needs.

It shifts the responsibility of feature delivery to the teams entirely.

Why it fails: The PM maintains responsibility for the product vision and backlog throughout the lifecycle. While teams take ownership of delivery, the PM provides ongoing support and guidance. This criteria check is an act of collaboration between the PM and the teams, not a transfer of total responsibility.

Keep Story A in the iteration and hope the server upgrade happens early.

Why it fails: Ignoring a known constraint is a recipe for failure. Relying on hope rather than data leads to blocked work and reduced team morale. The PO should adapt the plan based on the reality of the situation to ensure the team can actually deliver value within the current sprint.

Ask the team to work on Story B and wait for the upgrade to start Story A.

Why it fails: Focusing on low-value items while waiting for blockers leads to waste. The PO should instead look for other high-value items in the backlog that can be delivered independently. This ensures that the team’s effort is always aligned with the most important business goals during the iteration timeframe.

Declare the iteration failed and start planning for the next one immediately.

Why it fails: One blocked story does not mean an entire iteration failure. SAFe teams are expected to adapt. Declaring failure prematurely wastes valuable time that could be used for productive work. The PO should lead the team in re-planning the current iteration to salvage as much value as possible.

Commit to the full 40 points, as the buffer is intended for emergencies.

Why it fails: Treating the buffer as a capacity expansion tool is a common mistake that defeats the purpose of having a buffer. Buffers are meant to handle uncertainty. Over-committing puts the team at risk of failure and reduces their ability to handle real issues, leading to missed commitments and decreased stakeholder confidence.

Ask the team to work faster to cover the 5-point difference.

Why it fails: Demanding increased velocity is unrealistic and often counterproductive. Velocity is an empirical measure, not a variable that can be changed by command. Pressuring the team to 'work faster' leads to quality issues and technical debt. The PO should instead adjust the scope to reflect the team's actual and sustainable velocity.

Keep the plan as is and hope for the best during the PI.

Why it fails: 'Hoping for the best' is not a strategy. It is a recipe for failure. The PO is responsible for planning that is rooted in reality. By failing to address the capacity gap, the PO sets the team up for inevitable disappointment and damages the team's ability to maintain a consistent delivery cadence.

Add the fix to the existing work without removing anything.

Why it fails: Adding 10 points of unplanned work without removing existing tasks will cause the team to miss their sprint goal. This leads to burnout and reduced delivery consistency. The PO must actively manage the scope to ensure the team can succeed, rather than overloading them and hoping for the best outcome.

Ask the team to work overtime to finish everything.

Why it fails: Working overtime is not a sustainable practice in SAFe. It leads to lower quality, burnout, and decreased morale. The PO should manage the backlog to fit the capacity, not expect the team to sacrifice their well-being to compensate for poor prioritization or unforeseen issues. Sustainable development is a core agile principle.

Refuse the fix until the next iteration.

Why it fails: Refusing a truly critical emergency defect can lead to severe business consequences. A PO must balance the need for sprint stability with the reality of production issues. If the defect is truly an emergency, the PO must take responsibility for addressing it rather than ignoring it and hoping it disappears.

Ignore the dependency and push the team to start development immediately.

Why it fails: Ignoring dependencies leads to blocked work and failed commitments. If the architectural foundation is not ready, the team will encounter technical blockers that prevent them from completing the feature. This approach increases risk and compromises the quality of the solution, potentially causing significant rework later in the development process.

Remove the feature from the Program Backlog until the next PI planning.

Why it fails: Removing the feature arbitrarily without checking if the dependency can be resolved is inefficient. Product Management must collaborate with the System Architect to see if the runway can be built in time. Deferring without analysis potentially wastes the opportunity to deliver high-value features in the current PI cycle.

Assign the feature to a different team that does not have dependencies.

Why it fails: Assigning the feature to a team without checking their architectural capability does not solve the dependency. If the underlying infrastructure is missing, no team can effectively deliver the feature. Moving the work simply shifts the problem rather than solving the root cause, which is the missing architectural runway itself.

Because it is marked as 'High' priority.

Why it fails: High priority is exactly what the team should be working on. The issue is not the priority level, but the missing readiness criteria. Prioritization without readiness leads to poor planning, but the priority itself is actually a reason to include the feature, provided it can be properly prepared before the event.

Because it has already undergone architectural review.

Why it fails: Architectural review is a positive indicator that the feature has been checked for viability. This is a good thing and is not why the feature is unsuitable. The flaw lies in the missing acceptance criteria, which is a critical documentation requirement that has been overlooked for this feature, rendering it incomplete.

Because it is in 'In Progress' status.

Why it fails: Features that are 'In Progress' are frequently carried over into the next PI. Their status is not the reason they would be unsuitable. The issue is the combination of missing criteria and lack of recent activity, which points to a management failure rather than a problem with the feature being 'in progress'.

Extend the PI Planning event by two days to allow teams more time to resolve the dependencies themselves.

Why it fails: Extending the event duration does not address the underlying systemic issues causing the dependencies and blockers. If teams cannot resolve these on their own within the allocated time, leadership intervention is required to make trade-off decisions that teams are not empowered to make independently.

Ignore the blockers and proceed with the confidence vote, as teams are responsible for their own success.

Why it fails: Ignoring systemic blockers is a failure of leadership that sets the program up for failure. A confidence vote conducted under these conditions is meaningless because the teams know the plan is unrealistic, which leads to disengagement and a lack of accountability for the eventual outcomes.

Report the lack of progress to the PMO to initiate corrective action after the PI Planning event.

Why it fails: Post-event reporting does nothing to fix the issues currently hindering the planning session. Effective PI Planning requires real-time problem solving, and waiting for external PMO intervention reflects a lack of active engagement in the Scaled Agile process, resulting in a wasted planning opportunity.

Wait for the System Team to resolve the issue independently.

Why it fails: Waiting for others to resolve issues is a passive approach that risks the team's commitments. The PO must be an active participant in removing blockers. Relying on external teams without direct coordination leads to delays and lack of visibility into the progress, which is unacceptable when the item is critical.

Immediately pivot to a completely different feature to save time.

Why it fails: Abandoning a critical, high-priority objective without attempting to resolve the block is a failure of responsibility. The PO must first try to address the root cause of the blocker. Only after it is deemed truly unresolvable should the PO consider alternative plans, ensuring that the most valuable work is completed.

Remove the objective from the PI and update the stakeholders that it will not be delivered.

Why it fails: Removing an objective without exhausting resolution options is premature. Stakeholders expect the PO to manage risks effectively. Proactive resolution is part of the PO's role. Giving up on a critical objective without a fight undermines the purpose of planning and reduces the total value delivered to the business.

Ask the teams to ignore the enabler until the next PI.

Why it fails: Ignoring a critical enabler is a significant risk that could render current features unusable. The PM must address the enabler now, as it is a prerequisite for technical success. Pushing it to the next PI could lead to compounding technical debt and ultimately failure to deliver.

Tell the teams to find a workaround that avoids the enabler.

Why it fails: Workarounds often result in temporary fixes that increase technical debt and reduce long-term agility. The PM should address the root cause, which is the missing enabler. Finding a workaround is a short-term, risky solution that undermines the quality and sustainability of the system over time.

Submit a change request to the Portfolio management office.

Why it fails: Internal ART technical enablers usually do not require Portfolio-level approval. This is an operational decision within the ART. Escalating to the PMO creates unnecessary bureaucracy and delays, whereas the PM and Architect have the authority to manage the Program Backlog to ensure successful delivery.

Include Feature X in the plan anyway to avoid delays.

Why it fails: Ignoring policy leads to technical risk and potential failure during the increment. If a feature has not been vetted for viability, it is not ready for the plan. Planning for unvetted work creates uncertainty and can lead to major roadblocks during development, undermining the credibility of the entire plan.

Ask the Scrum Master to sign off on the technical viability instead.

Why it fails: The Scrum Master is not responsible for technical architecture or system viability. Violating the established process by seeking sign-off from the wrong role creates confusion and potentially dangerous technical compromises. The System Architect is the required role for this validation, and their input is non-negotiable for ensuring system stability.

Mark the feature as 'ready' and note that the Architect will review it during the sprint.

Why it fails: Marking a feature as 'ready' when it violates policy is dishonest and bypasses critical quality gates. Reviewing during the sprint is too late, as the team will have already begun working on it. This leads to wasted effort if the Architect identifies significant design flaws during the actual sprint execution.

Have the teams document the risks in their own backlogs and resolve them individually.

Why it fails: Risk management is a shared responsibility that requires transparency across the train. If teams handle risks individually, there is no shared understanding or program-level visibility, and many risks, like external dependencies, cannot be managed by a single team. This would lead to predictable project failures.

Ignore the risks as they are just possibilities and not actual work items.

Why it fails: Ignoring risks is the most common cause of PI failure. Risks are not just possibilities; they are threats to the plan. By failing to categorize them, the train misses the opportunity to mitigate them, which almost guarantees that they will become major issues during the Program Increment.

Assign all risks to the Product Manager to handle during the next sprint.

Why it fails: The Product Manager cannot resolve all risks alone, especially those related to technical environments or vendor dependencies. Risk management requires input and action from various roles, including Scrum Masters, Architects, and leaders. Concentrating all risk ownership on one person creates a bottleneck and prevents effective resolution.

Permanently lower the team's capacity for all future iterations.

Why it fails: Permanently adjusting for a temporary disruption like turnover is an overreaction. The team will likely regain productivity as new members onboard. The PO should analyze trends over a longer period and collaborate with the team to determine their true sustainable velocity after the stabilization of the new team.

Ignore the I4 data as an anomaly and use the average of I1-I3.

Why it fails: Ignoring data points is dangerous in Agile planning. The turnover represents a real constraint that impacts the team's immediate capacity. While it may not reflect the long-term potential, failing to account for the impact of team changes leads to over-committing, which can cause significant stress and failure.

Request the Scrum Master to force the team to return to a velocity of 30.

Why it fails: Forcing velocity is a major anti-pattern that creates artificial, unreliable metrics. Agile teams should be allowed to stabilize their velocity organically through continuous improvement and collaboration. Dictating velocity destroys trust and encourages teams to inflate estimates, which ultimately masks real issues rather than solving the underlying team dynamics.