PI Execution practice questions

New requests from external stakeholders that were not discussed during PI planning.

Why it fails: Ad-hoc requests distract the team from their committed PI objectives. Significant new work should be managed through the Program Backlog and potentially introduced in a subsequent PI. While minor changes occur, major distractions disrupt the team's focus and reduce the likelihood of successfully meeting the planned program commitments.

Tasks that the developers find most interesting or fun to work on.

Why it fails: While team engagement is important, backlog prioritization must be driven by business value and strategic goals. Prioritizing tasks based on preference rather than value leads to misalignment with customer needs and organizational objectives. The PO must remain focused on delivering the most critical work for the business and customer.

The amount of technical debt the team has accumulated in the last two sprints.

Why it fails: While technical debt is a concern, it is not the primary factor for deciding whether to stretch a feature to another PI. Technical debt should be managed continuously within the backlog. Moving a feature is a strategic business decision based on value and capacity, not just on internal technical status.

The personal preference of the lead developer for the current sprint.

Why it fails: Personal preferences should never drive backlog decisions. Prioritization is a business decision based on data, stakeholder needs, and strategic goals. Allowing team preference to dictate the scope is unprofessional and leads to a product that does not meet the needs of the business or the intended target market.

The total number of story points completed by the team in the last year.

Why it fails: Yearly velocity is a lagging indicator that is too broad to inform current PI decisions. The team should focus on their recent, relevant velocity within the current PI to determine capacity. Using old data can lead to inaccurate planning and unrealistic expectations about what the team can actually deliver.

Tell the team to take the rest of the PI off as a reward for their speed.

Why it fails: Taking time off is not an Agile practice and wastes valuable capacity. The PO should ensure the team remains engaged in meaningful work. High-performing teams should use extra time to improve their systems, pay down debt, or get a head start on critical future features, not stop working.

Ask the team to do a 'deep clean' of the office area.

Why it fails: While keeping the office clean is nice, it does not provide business value or improve the product. The PO should focus on work that helps achieve the organization's goals. Using the team's engineering capacity for janitorial tasks is a major misuse of valuable resources and unprofessional for a PO.

Create new features that were not requested to surprise the stakeholders.

Why it fails: Building features without stakeholder input or validation is a recipe for building the wrong thing. The PO should stick to the agreed-upon priorities and work with the train to determine what provides the most value. Surprising stakeholders with unrequested features is rarely a successful strategy for product development.

It eliminates the need for Iteration Planning meetings

Why it fails: Refinement prepares the backlog but does not replace the planning meeting where the team commits to the Iteration Goal and plans their specific tasks. Iteration Planning is a distinct event required for synchronization and commitment, even if the backlog has been thoroughly refined in advance of the session.

It allows the Product Owner to assign tasks to specific developers

Why it fails: In SAFe, Agile teams are self-organizing, and developers pull work based on their capacity and skills. The Product Owner's role in refinement is to clarify 'what' needs to be built and 'why', not to assign 'who' does the work or 'how' it is technically implemented at the task level.

It ensures that the PI Predictability Measure remains at 100%

Why it fails: While refinement helps predictability, no single practice can guarantee a 100% predictability measure, which is often unrealistic in complex environments. Predictability is influenced by many factors including technical risks, dependencies, and external changes, whereas refinement specifically focuses on the clarity and size of upcoming work items.

Increase the Work-In-Process (WIP) limit for the Testing state

Why it fails: Increasing the WIP limit will only allow more Features to pile up in the bottleneck, further slowing down the overall cycle time. WIP limits are designed to highlight bottlenecks, not hide them. The correct response is to address the capacity constraints in testing rather than allowing more work into it.

Prioritize more new Features for development to keep teams busy

Why it fails: Adding more work into the system when there is an existing bottleneck at the end of the pipeline is highly inefficient. This leads to high multitasking and longer wait times. The focus should be on 'finishing' work that is already in progress rather than 'starting' new work.

Delete the Features that are stuck to clear the board

Why it fails: Deleting features that have already been developed is a massive waste of effort and investment. It does not solve the underlying process issue that caused the bottleneck in the first place. The Product Manager should instead focus on identifying why the testing is taking longer than expected.

Team Building and Social Events

Why it fails: While team building is important for culture, it is not a formal category in the Capacity Allocation model for backlog management. Capacity Allocation specifically refers to the distribution of the ART's engineering and development effort across different types of backlog items like features, enablers, and maintenance.

Individual Performance Review Meetings

Why it fails: Administrative tasks like performance reviews are not part of the capacity allocation for the ART's backlog. Capacity allocation is focused on the 'productive' work items that appear in the Kanban and backlog, not the overhead associated with managing the organization's human resources or personnel.

Competitor Analysis and Marketing Campaigns

Why it fails: Competitor analysis is a Product Management activity (Continuous Exploration) rather than work performed by the Agile teams on the ART. Marketing campaigns are also typically external to the ART's development capacity, which is focused on building and maintaining the actual software or system solution.

Immediately cancel the affected features and pivot to new ones.

Why it fails: Canceling features prematurely ignores the potential for mitigation strategies or re-sequencing. PI execution requires empirical evidence and collaborative problem-solving before making drastic changes to the committed scope. Abandoning work without a thorough impact assessment undermines the planning process and wastes previously invested resources on those specific items.

Ignore the delay and hope the external team catches up quickly.

Why it fails: Ignoring dependencies is a primary cause of PI failure. Proactive management is essential for ART success; pretending a delay does not exist prevents the team from re-planning effectively. Transparency is a core SAFe value, and leadership must address risks immediately to ensure visibility across the entire train.

Instruct the team to work overtime to compensate for the delay.

Why it fails: Forcing overtime is unsustainable and violates the SAFe principle of building long-term productivity. Sustainable development requires the ART to manage its workload within the available capacity. Relying on heroics masks systemic issues and often leads to burnout, decreased quality, and a loss of team morale during critical iterations.

Increase team velocity by reducing the amount of documentation required.

Why it fails: Arbitrarily reducing documentation is not a sustainable way to increase velocity and often leads to long-term quality issues. Documentation is part of the 'definition of done,' and skipping it risks technical debt and future rework. Improvement should come from process optimization rather than cutting corners on quality-related activities.

Extend the duration of the PI by two iterations.

Why it fails: Extending the PI is a major disruption that affects the entire release cadence and planning cycle. It should only be a last resort. The PM must first attempt to manage scope and prioritize value within the original timeline before considering changes to the PI duration or the release schedule.

Ask the teams to build a temporary workaround and continue with their original commitments, documenting the technical debt for later resolution.

Why it fails: Building a workaround may be a tactical fix, but it does not address the systemic vendor issue and could introduce significant technical debt. The Product Manager should first attempt to resolve the dependency at its source. A workaround might be part of a broader solution, but it is not the most effective first action.

Instruct both teams to stop work on the dependent features and reprioritize their backlogs to deliver other items until the vendor resolves the issue.

Why it fails: This response abdicates responsibility for a critical dependency and risks missing PI Objectives. Simply stopping work does not solve the external blocker; it may cause further delays and demoralize teams. The Product Manager should actively facilitate resolution rather than unilaterally redirecting teams away from committed work.

Add the vendor API issue to the Program Board as a risk and wait for the next PI Planning to address it.

Why it fails: Waiting until the next PI Planning is too late; the issue is impacting current execution. While the Program Board tracks dependencies, it is not a mechanism for real-time problem-solving. The Product Manager must act now to unblock teams and preserve the PI's goals, not defer action.

Collect detailed status reports from each team for documentation purposes.

Why it fails: Collecting detailed status reports for documentation is not the purpose of ART Sync. The event is meant for coordination and problem-solving, not for generating paperwork. The PM should focus on actionable outcomes, such as resolving dependencies and re-prioritizing, rather than bureaucratic reporting that adds little value to execution.

Review each team's detailed iteration plan and adjust tasks as needed.

Why it fails: Reviewing detailed iteration plans and adjusting tasks is not appropriate for the Product Manager during ART Sync. That level of detail is the team's domain, and micromanaging tasks undermines self-organization. The ART Sync should focus on higher-level coordination, not tactical task management, which is handled within the team's own events.

Assign tasks to individual team members to balance workload.

Why it fails: Assigning tasks to individual team members is a team-level activity, not a Product Manager responsibility. The PM should not interfere with how teams organize their work. Doing so would violate agile principles of self-organization and could disrupt the team's flow. The ART Sync is for coordination, not for task assignment.

Ask teams to commit to fewer objectives in the next PI Planning to create buffer for unplanned work.

Why it fails: While committing to fewer objectives might provide some buffer, it does not address the systemic issue of unplanned work. It may also lead to underutilization and missed business opportunities. The focus should be on improving dependency management and enabler prioritization, not simply reducing commitments.

Increase the number of iterations in the PI to allow more time for unplanned work.

Why it fails: Adding iterations to a PI disrupts the cadence and does not address the underlying causes of unplanned work. SAFe emphasizes a fixed cadence and synchronized iterations. Changing the PI length would create more problems than it solves and is not a recommended practice.

Instruct Product Owners to reject all unplanned work during the PI to protect the team's capacity.

Why it fails: Rejecting all unplanned work is unrealistic and may ignore critical emergent needs. Instead, the Product Manager should help establish a defined capacity allocation for unplanned work and prioritize it against planned objectives. A blanket rejection can damage stakeholder relationships and miss important opportunities.

Assign blame to the team members responsible for the missed objective to ensure accountability.

Why it fails: Blaming individuals is counterproductive and violates SAFe's principle of psychological safety. The I&A is a blame-free environment where teams analyze systemic issues. The Product Owner should foster a culture of learning, not punishment. Assigning blame can stifle openness and hinder improvement.

Prepare a presentation that highlights only the team's successes to maintain morale.

Why it fails: Focusing only on successes hides problems and prevents learning. The I&A is designed to inspect both successes and failures. The Product Owner should encourage transparency and a growth mindset. Ignoring challenges can lead to repeated mistakes and erode trust within the ART.

Ensure the team's PI Objectives are updated to reflect the missed objective before the I&A.

Why it fails: PI Objectives should not be altered after the PI to reflect actuals. The I&A is meant to inspect what actually happened, including misses. Changing objectives undermines the transparency and learning that the workshop aims to achieve. The team should present the original objectives and discuss the reasons for the miss.

Direct the team to proceed without the dependency and accept the risk.

Why it fails: Proceeding without resolving a critical dependency can lead to integration failures and unmet objectives. The Product Manager should address the dependency proactively rather than accepting unnecessary risk. Ignoring it may also impact other teams and the overall solution integrity.

Wait until the Inspect and Adapt workshop to address the dependency.

Why it fails: Waiting until the end of the PI to address a critical dependency is too late; it could jeopardize the PI Objective. The Product Manager should act during PI Execution to resolve or mitigate the issue. The Inspect and Adapt is for problem-solving after the fact, not for real-time dependency management.

Escalate the dependency to the Release Train Engineer to coordinate with the other ART.

Why it fails: While the Release Train Engineer can help coordinate dependencies, the Product Manager is responsible for managing cross-ART dependencies at the program level. Escalation alone may not resolve the issue; the Product Manager should actively engage with the other ART's Product Management to find a solution and adjust plans as needed.

Escalate to the Release Train Engineer to have the production support work reassigned to a different team.

Why it fails: Reassigning support work may not be feasible and could simply shift the problem. Production support is often unavoidable and may require the team's specific knowledge. The Product Owner should first make the work visible and adjust plans, rather than assuming another team can absorb it without impact.

Instruct the team to work overtime to catch up on the planned features and maintain the original commitment.

Why it fails: Overtime is unsustainable and often leads to burnout, defects, and further velocity loss. It does not address the root cause of unplanned work and may violate the team's capacity. The Product Owner should focus on adapting the plan, not forcing the team to meet an outdated commitment.

Ignore the velocity drop and continue executing the original plan to avoid disrupting the ART's predictability.

Why it fails: Ignoring reality undermines transparency and will lead to missed commitments and loss of trust. The ART's predictability depends on honest communication and adaptation. The Product Owner must address the deviation, not hide it, to allow the ART to make informed decisions about scope and priorities.

Ask the team to work overtime to ensure all features are finished as originally committed.

Why it fails: Mandating overtime negatively impacts sustainable pace and team morale, leading to burnout and decreased quality. SAFe emphasizes a sustainable pace, and forcing extra hours contradicts the principle of built-in quality. The PO should instead collaborate to adjust the plan based on reality rather than forcing unrealistic expectations on the team.

Increase the story points for all remaining items to make the velocity look better.

Why it fails: Artificially inflating story points obscures the true team velocity and creates technical debt. This practice provides a false sense of security to stakeholders and makes future planning impossible. The PO and team must use accurate velocity data to make informed decisions about scope reduction instead of manipulating the underlying metrics.

Instruct the team to stop updating the Kanban board so the progress appears complete.

Why it fails: Hiding progress data prevents transparency and prevents the PO from making informed decisions. Effective PI execution requires visibility into work-in-progress to identify bottlenecks and address impediments promptly. Obfuscating board updates undermines the core inspect-and-adapt cycle essential for continuous improvement and successful delivery of committed program increments.

Rewrite all user stories for the next PI during the current sprint.

Why it fails: Rewriting all stories for the next PI during active execution distracts the PO from the current sprint's goals. While backlog grooming is ongoing, the focus should remain on current PI delivery. Massive rewrites are better handled during the specific preparation phases leading up to the next Planning event for that PI.

Directly manage the daily stand-up and assign tasks to developers.

Why it fails: Assigning tasks is a command-and-control behavior that undermines the self-organizing nature of Agile teams. The team decides how to execute the work, while the PO focuses on the what and why. This distinction is critical for high-performing teams, as it empowers developers to take ownership of their development processes.

Decide the architectural runway for the entire Program Increment.

Why it fails: Architectural runway is primarily the responsibility of the System Architect and the Agile Release Train leadership. While the PO considers technical enablers, they do not dictate the architectural strategy for the entire train. This requires coordination with the architect and product management to ensure technical stability alongside business-focused feature delivery.

Wait until the next PI Planning to discuss this blocker with the other team.

Why it fails: Waiting for the next PI Planning session is too late and will cause significant delays in the current PI. Dependencies must be resolved in real-time during the execution phase to avoid stalling the team. Proactive communication is a core expectation for POs to ensure smooth delivery across the train.

Tell the developers to ignore the API and build a temporary mock service.

Why it fails: Building temporary mocks adds technical debt and can hide integration issues until too late in the development cycle. While sometimes necessary, this should be a team-agreed strategy after evaluating the impact of the blocker. The PO must collaborate with developers on the solution rather than unilaterally dictating the technical workaround.

Contact the Team Alpha PO directly to demand a fix.

Why it fails: Demanding a fix creates friction and damages the collaborative relationship required between teams. SAFe encourages transparency and shared responsibility for the train's success. Using the established ART synchronization processes is more professional and more likely to result in a sustainable solution that considers the needs of both teams involved.

Defend the original feature requirements as they were agreed upon at the start of the PI.

Why it fails: Defending outdated requirements ignores the reality of market shifts and customer needs. Agile is about responding to change over following a plan. The PM should value the feedback received during the demo as a critical insight, using it to adapt the product strategy rather than sticking stubbornly to the original plan.

Ignore the feedback because the team has already spent too much effort on the feature.

Why it fails: Ignoring feedback just because of sunk costs leads to building products that nobody wants. This is a classic trap that wastes time and resources. The PM must prioritize value over sunk effort, ensuring that the team stops working on low-value items and shifts focus to what the market actually needs.

Ask the stakeholders to wait until the final PI demo to see the completed feature.

Why it fails: Delaying the feedback loop defeats the purpose of frequent system demos. The goal of the demo is to get real-time feedback so the product can be adjusted early. Telling stakeholders to wait until the end prevents the team from making necessary pivots, likely resulting in a failed, irrelevant product delivery.

To review individual team progress and hold them accountable for their velocity.

Why it fails: The System Demo is about the integrated solution, not individual team performance. Focusing on individual velocity during the demo creates a competitive environment that discourages collaboration. The focus should be on the collective progress of the train toward achieving the program objectives and delivering value to the end customer.

To approve the final release of the software to the production environment.

Why it fails: The System Demo is not a formal release gate for production deployment. Release processes are handled through the DevOps pipeline and release management procedures. The demo is for feedback and alignment, not for the technical sign-off required to move code into a production environment for customer access.

To celebrate the team's accomplishments and provide recognition to developers.

Why it fails: While celebrating is good, it is not the primary purpose of the System Demo. The demo is a formal synchronization point for the Agile Release Train to evaluate product progress. Recognition should happen in retrospectives or team meetings rather than occupying the time intended for stakeholder feedback on the solution.

Reduce the scope of the remaining PI features.

Why it fails: Scope reduction is a potential outcome, but it should not be the first step. The PO must first understand why the velocity is low. If the cause is a fixable impediment, reducing scope might be premature. The PO should analyze the data first before making decisions that impact the committed goals.

Report the team to leadership for not meeting their commitments.

Why it fails: Reporting the team to leadership is counterproductive and damages trust. It creates a culture of fear rather than one of learning and improvement. The PO's job is to support the team in their delivery, which involves removing obstacles and helping them succeed, not acting as a disciplinary authority figure.

Increase the team's capacity by hiring more developers.

Why it fails: Adding more people to a project that is already struggling often adds complexity and communication overhead, leading to further delays. This is a common fallacy in management. The team should focus on optimizing their existing capacity and removing bottlenecks before considering adding new team members to the project.