Leadership for PI Planning practice questions

Approve the technical implementation details for every feature to ensure architectural integrity.

Why it fails: Business Owners are responsible for business outcomes, not technical implementation details. Architectural integrity is the domain of System Architects and the engineering teams. Involving Business Owners in technical minutiae distracts them from their primary responsibility of ensuring the business value of the proposed solutions.

Manage the team's daily stand-ups to ensure the plan is being followed exactly as written.

Why it fails: Business Owners do not manage team ceremonies. Daily stand-ups are for team members to sync on progress and blockers. The Business Owner's role is to provide direction and validate value, not to act as a project manager overseeing the daily execution of the team's work.

Let the team continue, as they will learn from their mistakes during the PI.

Why it fails: Learning from mistakes is good, but PI Planning is an expensive, high-stakes event. Waiting for failure is not an acceptable strategy when proactive coaching can prevent it. The goal is to build a successful plan, and that requires active leadership intervention when collaboration is clearly missing.

Write the dependencies for them and place them on the program board.

Why it fails: Writing the dependencies for the team denies them the opportunity to negotiate the work and understand the context. It creates a plan that the team may not fully support. The goal is to teach the team to manage their own connections, not to do the work for them.

Report the team's lack of collaboration to their department manager.

Why it fails: Reporting the team to their manager is punitive and does not solve the immediate need for communication. PI Planning requires real-time facilitation. The leader's role is to help the team succeed in the moment, not to look for opportunities to criticize their performance to external managers.

Inform the team they must resolve it alone to show maturity.

Why it fails: If the team could have resolved it, it would not be a significant, unmitigated dependency on the Program Board. Refusing to help when a team is blocked is a failure of servant leadership. Leaders must intervene when team-level resolution is insufficient for the complexity of the issue.

Wait until the next PI to handle the dependency.

Why it fails: Deferring critical dependencies until the next PI guarantees that the current PI's objectives will be missed. The Program Board is meant to be managed in the present; delaying the fix allows the risk to grow and prevents the team from delivering value in the upcoming PI.

Update the board with a note saying it will resolve itself.

Why it fails: Relying on things to 'resolve themselves' is not a strategy; it is wishful thinking. Dependencies require active management and clear ownership. Leaving a note that ignores the need for action provides a false sense of progress and leads to inevitable failure when the dependency remains unaddressed.

Remove the feature from the plan to avoid dependency and focus on other work.

Why it fails: Removing the feature may be a last resort, but it could compromise business value if the feature is critical. The Product Owner should first explore alternatives to deliver the feature, such as re-scoping or collaborating with other teams. Abandoning it without exploration may lead to missed opportunities and does not align with SAFe's problem-solving mindset.

Proceed with the plan as is, assuming the dependency will be resolved later since the other team is not present.

Why it fails: Ignoring the dependency risks plan failure and undermines the purpose of PI Planning to surface and address dependencies. SAFe emphasizes that dependencies must be made visible and resolved during planning. Assuming later resolution can lead to integration issues and missed objectives, violating the principle of alignment.

Escalate to the Release Train Engineer to contact the absent team and negotiate a solution after PI Planning.

Why it fails: Escalating to the RTE may be necessary if the dependency cannot be resolved, but it delays resolution and may impact the PI plan. The Product Owner should first attempt to resolve the dependency collaboratively with available teams. Proactive problem-solving during the event is preferred to maintain momentum and commitment.

Assign business value to each team's PI Objectives.

Why it fails: While Business Owners may provide input, assigning business value to PI Objectives is primarily done by the teams themselves, often with guidance from Product Management. Business Owners may review and adjust, but it is not solely their responsibility. The team's ownership of business value is important for engagement.

Facilitate the team breakout sessions to keep teams on schedule.

Why it fails: Facilitating team breakouts is not a Business Owner responsibility. It is typically done by Scrum Masters or Team Coaches. Business Owners focus on business outcomes, not process facilitation. Involving them in facilitation would distract from their primary role.

Resolve technical dependencies between teams during the management review.

Why it fails: Resolving technical dependencies is not the role of Business Owners. This is typically handled by the teams and the RTE. Business Owners may help remove business impediments, but technical issues are better addressed by those with technical expertise. Their focus should remain on business value and strategy.

Document the conflict as a program risk and defer resolution to the next PI Planning.

Why it fails: Deferring resolution to the next PI Planning is too late; the conflict will impact the current PI and likely cause delays or integration failures. The management review session exists precisely to resolve such issues in real time. Documenting it as a risk without action is insufficient. The Product Manager should seek immediate resolution to keep the PI on track.

Decide which team's plan takes precedence and inform them after the session.

Why it fails: Making a unilateral decision without involving the teams may lead to resentment and lack of buy-in. It also ignores the teams' technical insights and could result in a suboptimal solution. SAFe emphasizes collaborative problem-solving, and the management review is meant to facilitate resolution, not impose decisions from above without team input.

Escalate the conflict to the Chief Product Owner for a final decision.

Why it fails: Escalating to the Chief Product Owner may be necessary in some cases, but it should not be the first step. The management review session is designed to resolve cross-team issues at the ART level. Involving higher levels prematurely can slow down decision-making and disempower the ART. The Product Manager should first attempt to facilitate a resolution within the session.

Facilitate the breakout sessions to ensure teams stay on schedule.

Why it fails: Facilitating breakout sessions is typically the responsibility of the Scrum Master or Team Coach, not the Business Owners. Business Owners may circulate to answer questions, but their primary role is not facilitation. They should be available for consultation but should not interfere with the team's self-organization. The RTE oversees the overall event logistics.

Assign each team their PI Objectives based on the program backlog priorities.

Why it fails: Teams self-determine their PI Objectives during breakout sessions. Business Owners do not assign objectives; they provide context and then review and approve the team's proposed objectives. Assigning objectives would undermine team empowerment and ownership. The bottom-up planning approach is fundamental to SAFe, allowing teams to commit to work they understand and can deliver.

Determine the technical architecture for the upcoming PI.

Why it fails: Technical architecture is the domain of the System Architect and the teams. Business Owners focus on business value and priorities, not technical design. They may provide input on nonfunctional requirements, but they do not dictate architecture. Involving Business Owners in technical decisions would be inappropriate and could lead to suboptimal solutions.

Instruct the teams to continue planning and address the strategic alignment concerns during the first System Demo.

Why it fails: Waiting until the first System Demo to address strategic misalignment is too late. By that time, teams have already committed resources and effort to potentially incorrect goals, resulting in significant waste and lost time that cannot be recovered within the current Program Increment timeframe.

Direct the Release Train Engineer to unilaterally modify the team objectives to match the Business Owner's vision.

Why it fails: Unilateral changes bypass the collaborative nature of PI Planning, which relies on the team's commitment to their own plans. If teams do not have agency in defining their objectives based on realistic capacity, the ownership of the PI plan diminishes, leading to lower morale and reduced performance.

Ask the System Architect to rewrite the objectives to ensure they meet the technical standards of the enterprise.

Why it fails: While System Architects provide essential guidance, rewriting objectives without team input ignores the capacity and feasibility constraints identified during planning. PI Objectives must reflect the specific work the team is capable of delivering, not just architectural ideals that may be disconnected from the current team's workload.

Dictate the specific task-level assignments for each team member to ensure maximum resource utilization.

Why it fails: Micromanaging tasks shifts the focus away from value delivery toward resource utilization, which is an anti-pattern in Lean-Agile environments. Teams are best equipped to manage their own task distribution, and dictating assignments stifles autonomy, innovation, and the team's ability to self-organize around the planned objectives.

Minimize the interaction between Business Owners and teams to ensure the planning stays on schedule.

Why it fails: Limiting interaction between Business Owners and teams creates silos that prevent the essential alignment of business value with technical execution. Planning must include active negotiation to ensure that both parties have a shared understanding of the objectives, which is critical for success throughout the Program Increment.

Insist that every team plan for 100% of their capacity to guarantee maximum throughput.

Why it fails: Planning for 100% capacity ignores the reality of variability and uncertainty, leading to fragile plans that fail when minor issues arise. High-performing teams account for buffers and unplanned work, and leaders should support this realistic planning approach rather than forcing unsustainable, high-risk utilization targets on the teams.

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.

Ask the team to remove the dependency from the plan and work around it independently.

Why it fails: If the dependency is critical, ignoring it or working around it is not a viable strategy. Attempting to build without necessary external input or components will result in integration failures and rework, further jeopardizing the team's ability to meet their objectives by the end of the PI.

Instruct the team to mark the objective as 'at risk' and continue planning as if the supplier will deliver.

Why it fails: Marking an objective as 'at risk' is not enough if the work is fundamental to the delivery. It shifts the burden of failure onto the team without providing a solution, which undermines the purpose of PI Planning as a mechanism for alignment and realistic commitment.

Cancel the planned feature to maintain the team's velocity and focus on internal work.

Why it fails: Arbitrarily canceling features because of external dependencies ignores the strategic value of those features to the business. Leadership should first attempt to resolve the dependency issue before deciding to deprioritize or cancel work that was identified as high value by the Business Owners.

To finalize the release dates for the next three years of the product roadmap.

Why it fails: PI Planning focuses on the upcoming Program Increment, not long-term roadmap planning. Three-year planning is too far out for the level of detail required in PI Planning, and attempting to force such long-term commitments would lead to inaccurate and unreliable plans that cannot be sustained.

To celebrate the team's progress and distribute rewards for the previous PI's performance.

Why it fails: While celebrating is important, it is not the primary purpose of this session. This time is strictly reserved for solving the critical problems that currently impede the planning process. Using this time for non-essential activities would jeopardize the ability to complete a viable plan for the upcoming PI.

To conduct the confidence vote for all teams on the Agile Release Train.

Why it fails: The confidence vote happens at the end of the second day of PI Planning, not during the Management Review session. This session is for leadership to prepare the ground for that vote by solving the problems that would otherwise prevent a high-confidence outcome.

Agree to the extra features but plan for mandatory overtime throughout the entire PI.

Why it fails: Planning for mandatory overtime is a major anti-pattern that leads to burnout and decreased productivity over time. It creates a culture of overwork rather than sustainable flow and does not solve the fundamental issue of mismatch between business demand and team capacity.

Let the teams decide if they want to accept the extra features or not.

Why it fails: Leaving this decision to the teams puts undue pressure on them and can lead to over-commitment to please leadership. It is the responsibility of the leadership and the PO to protect the teams from unrealistic demands and ensure that the planning process remains grounded in empirical data.

Ignore the capacity planning and hope the team's productivity increases during the PI.

Why it fails: Hoping for an increase in productivity is not a strategy; it is a recipe for failure. Planning should always be based on known capacity, not aspirational targets. Ignoring this reality will lead to missed objectives, which damages the credibility of the entire Agile Release Train.

Force the teams to work in a cross-functional way to balance the load regardless of skill sets.

Why it fails: While cross-functional training is a goal, forcing it during PI Planning without proper preparation can lead to quality issues and delays. Teams need specialized skills to complete specific tasks, and simply mandating cross-functionality without the necessary expertise will not solve the capacity mismatch effectively.

Accept the plan as is, because the total capacity matches the total demand.

Why it fails: Accepting the plan without addressing the distribution mismatch will lead to failure. If a team is assigned work that exceeds its specific capacity, it will miss its targets, causing a domino effect that impacts the entire program. Total numbers do not account for individual team constraints.

Direct the Product Manager to remove all features until the total demand is below capacity.

Why it fails: Removing features is a last resort, not a first step. Before cutting scope, leadership should explore if the work can be moved to teams with available capacity. Only after all redistribution options have been exhausted should the PM consider reducing the scope to ensure the plan remains feasible.

To decide which features should be implemented in the upcoming PI.

Why it fails: Feature prioritization is the responsibility of the Product Management team and the Business Owners. The RTE's role is not to define the content of the program, but to facilitate the environment and the process that allows the team to plan for that content successfully and effectively.

To write the PI objectives for all of the teams on the train.

Why it fails: Each team is responsible for writing their own PI objectives. This ensures ownership and alignment with their specific capacity and the work they have committed to. If the RTE writes the objectives, the teams will lack the commitment and understanding necessary to execute the plan effectively.

To perform the technical design of all features on the Program Board.

Why it fails: Technical design is the responsibility of the System Architects and the individual teams. The RTE is a process leader, not a technical lead. Getting involved in technical design would distract the RTE from their primary role of facilitating the planning event and ensuring the program runs efficiently.

To ensure that management can hold teams accountable if they fail to meet their objectives.

Why it fails: The confidence vote is about shared commitment and alignment, not blame. If the goal is simply to hold people accountable, the vote will be seen as a threat, which will cause people to hide their real concerns rather than share them, defeating the purpose of the exercise.

To formally ratify the release dates in a legally binding contract.

Why it fails: PI Planning is an internal planning activity to build alignment and agility; it is not a legal contract. The confidence vote is a tool for team-level buy-in and alignment, not for creating a rigid, binding document that would contradict the flexible nature of the Scaled Agile Framework.

To rank teams based on their confidence to identify which teams need the most help.

Why it fails: The confidence vote is not a performance ranking mechanism. Using it to judge or rank teams undermines the spirit of collaboration and leads to people lying about their confidence to avoid appearing as the 'weak' team. It should always be used as a constructive tool for improvement.

Ask them to vote again after explaining the importance of showing a united front.

Why it fails: Asking for a second vote without addressing the underlying cause is coercive and dishonest. It forces a 'united front' that masks the true issues, which will eventually lead to failure during the PI. The goal is a realistic, honest plan, not a false sense of security.

Accept the low confidence and proceed, as it provides a realistic view of potential failures.

Why it fails: Accepting low confidence without action is a failure of leadership. If the plan is known to have a high risk of failure from the start, the team will start the PI already feeling defeated, which reduces motivation and makes it much harder to achieve even the smaller objectives.

Delegate the resolution to the team and rejoin when they have a better plan.

Why it fails: The team often lacks the authority or organizational influence to solve the issues causing low confidence, such as cross-team dependencies or resource shortages. Leaving them to solve it alone is a dereliction of duty; the leader must actively participate in resolving these systemic problems.

Approve the individual task assignments for every developer on the train.

Why it fails: Task-level assignments are the responsibility of the team, not the leadership. Engaging in this level of detail is micromanagement and prevents the team from organizing around their specific capacity and expertise. Leadership should stay at the program level, focusing on outcomes rather than day-to-day task allocation.

Determine the exact Jira workflow for every team for the next three months.

Why it fails: Standardizing workflows is an organizational level activity, not something to be decided during the final review of a PI. Furthermore, teams should have the flexibility to tailor their process to their specific needs, provided they maintain visibility and alignment with the rest of the train.

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.

Tell the team to use their best judgment and move on to avoid delaying the agenda.

Why it fails: Dismissing the need for clarity creates significant risks for the PI. Without a shared understanding of requirements, teams often build the wrong features, leading to rework and missed PI Objectives. Leaders should prioritize quality and alignment over strict adherence to the clock during the planning session.

Assign a senior architect to rewrite all the stories while the team waits.

Why it fails: This approach undermines team autonomy and prevents collective ownership of the backlog. Agile teams must participate in refinement and estimation to internalize the work. Relying on a single authority figure creates a bottleneck and prevents the team from developing the necessary domain expertise to succeed.

Escalate the issue to the Release Train Engineer to adjust the planning timeline.

Why it fails: Escalation to the RTE is premature when the Product Manager is the primary owner of the backlog. The Product Manager should first attempt to resolve requirement issues locally. Relying on the RTE to adjust schedules ignores the leader's responsibility to manage priorities and facilitate effective planning meetings.