PI Planning Preparation practice questions

Feature A

Why it fails: Feature A has a WSJF score of 45. While it is higher than Features B and C, it is significantly lower than Feature D. Prioritizing this feature over Feature D would result in lower economic returns for the organization during the program increment, which contradicts the goal of maximizing delivered value.

Feature B

Why it fails: Feature B has the lowest WSJF score of 12 and is in 'draft' status. It is not ready for implementation and does not offer the highest value or cost-of-delay mitigation. Prioritizing this feature would be inefficient and fail to address the most pressing needs of the stakeholders and customers.

Feature C

Why it fails: Feature C has a WSJF score of 38, which is lower than Features A and D. Prioritizing this feature would mean delaying higher-value work, which leads to suboptimal outcomes. A disciplined approach to WSJF requires selecting the highest value items first to ensure the best possible return on investment.

Individual developer task assignments.

Why it fails: Product Managers should focus on features and outcomes, not individual task assignments. Managing individual tasks is the responsibility of the Scrum teams. Focusing on individual tasks at the program level creates a command-and-control environment that reduces team autonomy and prevents the teams from managing their own work effectively and efficiently.

The exact wording of the team's internal sprint goals.

Why it fails: Team-level sprint goals are defined by the teams during the iteration planning process. While they should align with PI objectives, the PM should not dictate their specific wording. Doing so interferes with the team's ownership and accountability for their sprint progress and undermines the collaborative spirit of the planning event.

Increased team autonomy and faster decision-making.

Why it fails: Poor preparation actually decreases autonomy because teams spend their time waiting for information or trying to resolve issues that should have been addressed earlier. It leads to confusion and dependency on external guidance, slowing down the decision-making process rather than accelerating it. This is the opposite of the intended Agile benefit.

Higher team morale due to less structure.

Why it fails: Lack of structure is generally associated with lower morale because teams feel frustrated and unsupported. Structure, in the form of clear vision and prioritized backlogs, provides the guidance teams need to succeed. Without it, team members feel lost, which leads to increased frustration and a significant drop in overall team morale and satisfaction.

Faster synchronization across all teams.

Why it fails: Synchronization requires clear objectives and understanding of dependencies, both of which are hindered by poor preparation. Without a clear plan, teams struggle to align, making it difficult to synchronize their work. Poor preparation disrupts the flow, making it nearly impossible to coordinate effectively across the entire Agile Release Train during the event.

Perform final acceptance testing on all features planned for the PI.

Why it fails: Acceptance testing is an ongoing activity that occurs during the delivery phase, not during planning preparation. Trying to complete testing before planning begins creates a bottleneck and ignores the iterative nature of development, where features are refined and validated throughout the PI's execution cycle and through continuous integration.

Assign specific tasks to individual developers to guarantee velocity.

Why it fails: In SAFe, teams self-organize to determine how they will achieve the PI objectives. Product Managers focus on the 'what' via features and stories, while team members determine the 'how' and specific task assignments. Direct assignment by the PM undermines team autonomy and reduces the effectiveness of the planning process.

Mandate the removal of all technical debt from the Program Backlog.

Why it fails: While addressing technical debt is important for long-term health, it should be balanced with new business value. The PM and System Architect must collaborate to prioritize enablers alongside features. Mandating the removal of all debt is rarely feasible and ignores the need for incremental investment in system quality.

The Team Backlog.

Why it fails: The Team Backlog contains the detailed stories for a specific team. It is too granular to represent the overall Vision. The Vision is a high-level strategic statement that encompasses the entire ART, whereas the Team Backlog is focused on the tactical execution of work within a specific team.

The Iteration Burn-down chart.

Why it fails: The Iteration Burn-down chart is a tactical tool used to track progress against the sprint goal. It provides real-time status, not the long-term Vision. It helps teams manage their day-to-day work, but it does not contribute to the strategic communication needed at the start of PI Planning.

The System Demo results.

Why it fails: System Demo results provide feedback on the current state of the solution. While important, they reflect the past and present, not the future Vision. The Vision is about where the ART is going, whereas the System Demo is about what has already been achieved and validated.

To verify that the budget has been allocated.

Why it fails: The confidence vote has nothing to do with budget approval. It is purely about assessing the feasibility and realism of the plan developed by the teams. Mixing financial topics into the planning vote would confuse the purpose, which is to assess team commitment to the work plan they just created.

To allow the Product Manager to pick the favorites.

Why it fails: The vote is not an opinion poll on favorites. It is a commitment mechanism. Using it as a popularity contest would destroy the scientific and data-driven spirit of SAFe. The focus must remain on the feasibility and the shared commitment to the goals defined by the PI Planning process.

To determine who receives a bonus.

Why it fails: Confidence votes are never tied to individual bonuses. Tying performance or compensation to these votes would prevent people from being honest about their concerns. It would force a false sense of security, leading to hidden risks and a failure to identify the true bottlenecks in the PI plan.

Assign the feature to a single team and let that team coordinate with others during PI Planning.

Why it fails: Assigning a cross-team feature to one team contradicts the collaborative nature of PI Planning and may lead to misalignment. The Product Manager should not unilaterally assign work; instead, teams should self-select during planning. This approach ignores the need for the feature to be properly defined and may cause dependencies to be overlooked.

Request that the Release Train Engineer (RTE) break down the feature into program increments before PI Planning.

Why it fails: The RTE facilitates PI Planning but does not own feature decomposition; that is the Product Manager's responsibility. Asking the RTE to break down features into program increments misinterprets the RTE role and delays readiness. Features are defined by the Product Manager, and the RTE ensures the event runs smoothly, not the content.

Split the feature into smaller, independently deliverable stories that each team can estimate and plan.

Why it fails: Splitting into stories may be premature because the feature itself must first meet readiness criteria, including clear acceptance criteria and business value. Stories are typically created by teams during PI Planning, not by the Product Manager beforehand. This action skips the essential step of ensuring the feature is properly defined and sized for the Program Backlog.

Wait until PI Planning to gather team input on business value and then assign scores collaboratively.

Why it fails: Waiting until PI Planning to assign business value would delay critical decisions and consume valuable planning time. Teams need prioritization upfront to plan their work effectively. The Product Manager should prepare business value scores beforehand to enable efficient and focused discussions during the event.

Use only the feature's cost of delay to prioritize, ignoring other factors like job size or risk.

Why it fails: While cost of delay is a key component of WSJF, ignoring job size and risk reduction leads to suboptimal prioritization. A feature with high cost of delay but enormous size may not be the best next item. The Product Manager should consider all WSJF components to maximize economic outcomes.

Delegate all feature prioritization to the Release Train Engineer (RTE) to ensure an unbiased view.

Why it fails: The RTE facilitates the ART and removes impediments but does not own feature prioritization. Delegating this to the RTE would bypass the Product Manager's accountability for value delivery and could lead to misalignment with business strategy. Prioritization remains with the Product Manager, who is closest to the customer and business needs.

Include a summary of the strategic themes in the PI Planning opening presentation.

Why it fails: Including strategic themes in the opening presentation is helpful, but it is a one-way communication that may not ensure deep understanding. The Product Manager should engage the ART in a dialogue about how the PI objectives align with strategic themes. A brief mention may not be sufficient for teams to internalize the connection and make informed trade-offs during planning.

Wait until the ART sync during PI Planning to explain the strategic themes.

Why it fails: Explaining strategic themes during the ART sync is too late; teams need this context before they begin planning to make informed decisions. The ART sync is for reviewing draft plans and resolving dependencies, not for introducing foundational strategic information. Pre-event communication is essential to set the stage for effective planning.

Send an email outlining the strategic themes and ask teams to review them before PI Planning.

Why it fails: Email communication is passive and may not effectively convey the importance of strategic themes or how they relate to the work. Teams may skim the information without fully grasping the implications. Without discussion, misunderstandings can persist, and alignment may be weak. Active engagement is needed to ensure the ART internalizes the strategic context for planning.

To create the Program Board and assign features to iterations before the event.

Why it fails: Creating the Program Board and assigning features to iterations is a key activity during PI Planning, not before. The Program Board is built collaboratively by teams during the event to visualize dependencies and timing. Pre-building it would bypass team collaboration and reduce the effectiveness of the planning process. The pre-PI Planning meeting focuses on preparation and alignment, not on creating planning outputs.

To review team capacity and adjust feature priorities based on available resources.

Why it fails: Reviewing team capacity and adjusting priorities is part of PI Planning itself, not typically a pre-PI Planning meeting with the RTE and System Architect. While capacity may be discussed, the primary purpose of this meeting is technical alignment. Adjusting priorities based on capacity before the event could undermine team self-selection and negotiation during planning.

To finalize the PI objectives and assign them to teams before the event.

Why it fails: Finalizing PI objectives and assigning them before PI Planning contradicts the collaborative nature of the event. PI objectives are created by teams during planning, based on the features and their capacity. Pre-assigning objectives removes team ownership and can lead to disengagement. The pre-PI Planning meeting is not for finalizing objectives but for aligning on vision and readiness.

Proceed with planning using the previous PI's Vision to avoid delaying the event.

Why it fails: Using outdated vision statements leads to misalignment with the current strategic direction of the enterprise. PI Planning requires current input to ensure that the Program Backlog accurately reflects the latest market conditions and business objectives. Relying on stale data undermines the purpose of synchronized cadence-based planning.

Delay PI Planning until the executive leadership completes the strategic theme definition.

Why it fails: Delaying the entire PI Planning event is rarely feasible in a time-boxed environment. While strategic themes are essential, the Product Manager must collaborate with stakeholders to synthesize existing information into a workable Vision. Proactive preparation ensures the train remains on schedule while still maintaining necessary strategic alignment.

Ask the Release Train Engineer to create the Vision on behalf of the Product team.

Why it fails: The Release Train Engineer facilitates the process but is not responsible for defining the product vision or strategy. Product Managers must own the Vision to ensure it aligns with customer needs and market requirements. Delegating this responsibility creates a disconnect between the strategy and the execution teams.

Selecting the specific technical tasks for every team.

Why it fails: Technical tasks are the responsibility of the Agile teams themselves, not the Product Manager. Micromanaging tasks at the team level undermines the principle of decentralized decision-making. Teams must maintain autonomy to determine the best technical approach to deliver the features defined by the Product Manager during planning.

Assigning story points to every feature in the backlog.

Why it fails: Feature estimation is typically done through collaborative estimation sessions like WSJF or relative sizing, not assigned by the Product Manager. Assigning points unilaterally ignores the collective knowledge of the team and leads to inaccurate estimates. Teams must participate in sizing to ensure shared understanding and accountability for delivery.

Conducting all team-level sprint demos.

Why it fails: Sprint demos are held at the team level to showcase progress to stakeholders and get feedback. While the PM may attend, conducting them is not a preparation step for PI Planning. This activity is part of the ongoing execution cycle rather than a specific prerequisite for the planning event.

Scrum Master

Why it fails: The Scrum Master is a servant leader who facilitates team processes and removes impediments. They do not have the authority or responsibility to manage the program-level backlog or prioritize business-facing features. Their focus is on team performance and adherence to Agile practices, rather than product strategy and backlog management.

Release Train Engineer

Why it fails: The Release Train Engineer acts as the chief Scrum Master for the Agile Release Train. Their primary role is to facilitate program events and coach teams, not to manage the product backlog. Assigning backlog management to the RTE would distract them from their core duties of ensuring program execution flow.

System Architect

Why it fails: The System Architect focuses on the technical vision, architectural runway, and system design. They work alongside the Product Manager but do not own the business-focused Program Backlog. Their involvement is essential for ensuring that the features are technically feasible, but they are not the primary authority for backlog prioritization.

To finalize the exact technical implementation details for every team.

Why it fails: Technical implementation details are handled by the Agile teams. The purpose of the Draft Plan review is to align on business objectives, not to dictate how the work should be done. Controlling technical decisions from the top-down stifles team creativity and undermines the empowerment needed for high-performing teams.

To formally sign off on the team's final PI commitment.

Why it fails: The formal sign-off on PI objectives occurs at the end of the second day during the final plan review. The Draft Plan review is an intermediate step meant for collaboration and course correction, not for final commitments. Rushing to a commitment too early leads to unrealistic plans and low confidence.

To re-prioritize the entire Program Backlog for the next two increments.

Why it fails: Re-prioritizing the entire backlog during the review would be counterproductive and disrupt the planning flow. The focus during this session is on the current PI draft, not long-term strategic shifts. Such decisions require more analysis and stakeholder consultation than can be provided in a brief draft review session.

Proceed with planning and let the teams define criteria during the first iteration.

Why it fails: Leaving acceptance criteria undefined until the iteration begins creates ambiguity and increases the risk of scope creep. Teams need clarity to plan effectively. Relying on teams to define criteria during execution can lead to inconsistent understanding of quality standards and prevents the team from committing to a realistic scope.

Use the previous PI's criteria for these features to save time.

Why it fails: Reusing old acceptance criteria is dangerous because business requirements and technical standards change over time. Each feature should have criteria specific to its current context. Using outdated information leads to poor quality and potentially delivers features that do not meet the needs of the stakeholders or the customer.

Remove the features from the backlog until criteria are established.

Why it fails: Removing features from the backlog without attempting to refine them is an overreaction that ignores the value they provide. The Product Manager's role is to facilitate the clarification process, not simply discard work. Collaboration with stakeholders and teams is the correct path to resolve ambiguity rather than simply deleting items.

The team's velocity report.

Why it fails: While velocity is useful for capacity planning, it is not a strategic document that provides alignment or context. The vision is far more important for ensuring that teams understand the purpose of their work. Velocity is a tactical metric and should not be confused with the strategic direction.

The detailed unit test plans.

Why it fails: Unit test plans are highly technical documents that are relevant at the iteration level, not at the program planning level. They do not help the ART align on the business value or strategic intent of the upcoming increment. Providing these during PI Planning would be an unnecessary distraction for the teams.

The meeting minutes from the last stakeholder review.

Why it fails: Meeting minutes are historical records and rarely provide the forward-looking strategic alignment needed for PI Planning. They are not intended to guide the future work of the ART. Relying on meeting minutes would likely lead to confusion about priorities and current goals for the upcoming program increment.

They are solely responsible for physically drawing the dependencies.

Why it fails: While the PM helps identify dependencies, the responsibility for drawing them is shared across the entire ART. The Program Board is a team-based visualization tool. Expecting the PM to do all the work prevents the teams from taking ownership of their own dependencies and understanding the complexity of the delivery.

They must approve every dependency listed on the board.

Why it fails: Approval of every dependency is not a formal requirement and would create a bottleneck in the planning process. The PM focuses on the business value and priority of features, while teams manage the technical dependencies. Collaboration is preferred over a formal approval process for managing dependencies on the board.

They should prevent any dependencies from being placed on the board.

Why it fails: Trying to prevent dependencies is unrealistic in complex systems. The goal of the Program Board is to identify and manage them, not to ignore or forbid them. Ignoring dependencies leads to hidden risks that will inevitably surface during execution, causing delays and potentially jeopardizing the entire program increment's success.

Individual team member task lists.

Why it fails: Individual team member task lists are too granular for the program backlog. The program backlog should focus on features and enablers, not individual tasks. Including these would clutter the backlog and make it difficult for the Product Manager to manage the high-level priorities of the entire Agile Release Train.

Personal development plans for all engineers.

Why it fails: Personal development plans are a matter for the individual and their manager, not the program backlog. Including these in the backlog would confuse the focus of the ART and is outside the scope of PI planning, which is dedicated to delivering value to the enterprise and its customers.

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.

It eliminates the need for any discussion during the planning event.

Why it fails: PI Planning is inherently collaborative and requires extensive discussion among team members. The goal of preparation is not to eliminate discussion, but to make it more productive and focused on planning rather than discovery. Discussion is essential for building a shared understanding and commitment among the members of the ART.

It guarantees that no changes will occur during the PI.

Why it fails: Change is inevitable in Agile environments. Preparation does not prevent change; it simply provides a solid foundation for managing it. Even with a well-prepared backlog, the team will need to adapt as they learn more during the increment. The goal is to provide enough clarity to handle change effectively, not to prevent it.

It allows the Product Manager to avoid attending the PI Planning event.

Why it fails: The Product Manager is an essential participant throughout the entire PI Planning event. They are needed to clarify requirements, adjust priorities as needed, and support the teams as they develop their objectives. Their absence would significantly undermine the effectiveness of the planning and the quality of the final committed PI objectives.