Hard Difficulty Questions

Create an improvement backlog item for the next PI immediately.

Why it fails: Creating a backlog item before brainstorming solutions is premature. The team needs to explore various ways to address the 'lack of automated testing'—such as training, tool selection, or process changes—to ensure that the resulting backlog item is the most effective way to solve the identified root cause.

Perform a fishbone analysis to find more potential root causes.

Why it fails: If the team has already identified the root cause as 'lack of automated testing,' repeating the fishbone analysis is redundant. The analysis is used to find the cause; once found, the process must move forward to the solution phase to maintain momentum and reach an actionable conclusion for the ART.

Update the Definition of Done to include mandatory automated tests.

Why it fails: Updating the Definition of Done is a potential outcome of the workshop, but it is not the next step in the facilitation process. The team must first agree on the feasibility and nature of the solutions before making formal changes to their working agreements or the standards for software delivery.

Establishing independent team financial budgets and standalone profit-and-loss statements.

Why it fails: Financial governance and budgets are managed at the Value Stream and Portfolio levels, not by individual Agile Teams. Teams focus on value delivery rather than managing standalone financial profit-and-loss statements.

Redefining corporate governance policies to bypass traditional HR performance reviews.

Why it fails: Corporate governance policies and HR structures are enterprise-level considerations outside the direct authority of a Scrum Master. Attempting to unilaterally redefine company-wide policies will disrupt organizational alignment during the transition.

Replacing the Product Owner with an enterprise portfolio manager for backlog prioritization.

Why it fails: Replacing the Product Owner violates core Scrum roles and removes localized customer representation from the team. Portfolio managers operate at a macro level and cannot replace the dedicated tactical backlog management of a Product Owner.

Recommend that the team reduce their Iteration commitment by 20% to account for unrefined stories and avoid overcommitment.

Why it fails: This is incorrect because reducing commitment does not address the underlying issue of taking on unrefined work. It may mask the problem temporarily but will not improve the team's ability to deliver value. The Scrum Master should focus on improving refinement practices rather than arbitrarily lowering capacity.

Facilitate a team discussion to estimate stories in story points and use velocity to cap the number of stories taken into the Iteration.

Why it fails: While estimation and velocity are useful, they do not ensure stories are refined. The team may still take on unrefined stories if they fit the velocity. The core issue is lack of refinement, not estimation accuracy. The Scrum Master should address refinement directly, not just capacity planning.

Ask the Product Owner to stop bringing new stories to Iteration Planning until all existing stories are fully refined.

Why it fails: This is too extreme and may hinder the flow of value. The Product Owner should continue to bring stories, but they must be refined. The Scrum Master should facilitate a collaborative solution, such as a Definition of Ready, rather than imposing a freeze on new work, which could disrupt stakeholder needs.

Updating the entire Program Board for all teams in the ART.

Why it fails: The Scrum Master is only responsible for their specific team's dependencies and contributions to the Program Board. Updating the entire board is the responsibility of the RTE or the ART as a collective group. Taking on responsibilities for other teams creates confusion and wastes the Scrum Master's time.

Delegating the management of dependencies to the Product Owner.

Why it fails: While the Product Owner handles the backlog, the Scrum Master facilitates the cross-team coordination needed to resolve dependencies. If the Scrum Master delegates this entirely, they miss the opportunity to coach the team on cross-team collaboration, which is a key responsibility for a servant leader in SAFe.

Removing the Program Board if it becomes too complex to manage.

Why it fails: The Program Board is a critical SAFe artifact that should not be removed. If it is complex, that is a sign that the ART needs to simplify their planning or improve their cross-team communication, not that the tool itself is the problem. Removing it would hide critical issues from view.

The Program Board

Why it fails: The Program Board is a planning and tracking tool used during PI Planning and execution. While it might help identify *where* a dependency failed, it is not a root cause analysis tool designed to uncover the underlying process or behavioral reasons why that failure occurred in the first place.

Pareto Analysis

Why it fails: Pareto Analysis is used to prioritize issues or root causes once they have been identified. It helps the team focus on the 20% of causes that are responsible for 80% of the problems, but it does not help in the initial discovery of what those causes actually are.

Confidence Voting

Why it fails: Confidence voting is used during PI Planning to gauge the team's belief in their plan. It is not an analytical tool for problem-solving or root cause analysis. While a low confidence vote might trigger a need for problem-solving, it is not a tool used within the workshop itself.

Allow the technical debate to continue so that all concerns are transparently addressed.

Why it fails: While transparency is valuable, the Iteration Review is intended to inspect the increment and gather feedback, not to debate technical design. Allowing an extended technical debate derails the event's purpose, consumes time needed for other stakeholders, and may prevent the team from receiving broader feedback. The Scrum Master should intervene to keep the event focused.

End the Iteration Review early and reschedule it for a time when only supportive stakeholders can attend.

Why it fails: Ending the review early penalizes all stakeholders and prevents the team from receiving feedback. The Scrum Master should manage the situation in the moment rather than avoid it. Rescheduling with a curated audience reduces transparency and contradicts the principle of frequent, open inspection. This is an overreaction to a manageable facilitation challenge.

Ask the Product Owner to answer the stakeholder's technical questions since they own the product vision.

Why it fails: The Product Owner may not have the technical depth to address design decisions, and doing so could undermine the team's ownership of technical choices. The Product Owner's role is to maximize value, not to defend technical design. This response fails to address the disruption and may put the Product Owner in an awkward position.

Assign the testing tasks to the most experienced developers immediately.

Why it fails: The Scrum Master does not assign tasks. Their role is to facilitate the process of improvement. Furthermore, simply assigning tasks doesn't address the systemic issue of missing automation; the improvement needs to be a planned effort that the whole team commits to during the next PI Planning.

Create a new Feature for 'Automated Testing' and add it to the Funnel.

Why it fails: While automation is important, improvements from the I&A are typically handled as stories or tasks in the Team Backlog or as part of the PI Objectives. Creating a high-level Feature might be too large and could get stuck in the funnel instead of being addressed immediately.

Escalate the issue to the System Architect to solve for the whole ART.

Why it fails: While the System Architect provides guidance, the purpose of the Problem-Solving Workshop is for teams to take ownership of their improvements. Escalating every issue prevents teams from developing their own problem-solving capabilities and may ignore the specific context of how the team's code is structured.

Prioritizing the team backlog and accepting completed stories into the baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline baseline

Why it fails: Prioritizing the team backlog and accepting stories is the explicit responsibility of the Product Owner, not the Scrum Master. The Scrum Master ensures the process is running smoothly but avoids making business value decisions on behalf of the Product Owner.

Defining the architectural runway and allocating system architect resources for technical debt.

Why it fails: Defining the architectural runway and managing technical design decisions are responsibilities belonging to System Architects and the Agile Release Train leadership. Scrum Masters support technical health indirectly through impediment removal, not architectural design.

Establishing enterprise portfolio budgets and approving strategic themes for the upcoming fiscal year.

Why it fails: Establishing portfolio budgets and setting strategic themes are executed by Lean Portfolio Management and executive leadership. Scrum Masters operate primarily at the team and program levels, far removed from enterprise-level budgetary approvals.

Calculating the final Business Value achieved for every team on the Agile Release Train.

Why it fails: Calculating achieved business value is a collaborative effort between the Business Owners and the individual teams, usually facilitated by the Release Train Engineer for the entire ART. The Scrum Master facilitates this for their own team but does not perform the calculation for the whole train.

Approving the final Solution Demo and signing off on the release of the software.

Why it fails: The Scrum Master does not have the authority to approve the solution or sign off on releases. This is the responsibility of Product Management, System Architects, and Business Owners. The Scrum Master's role is to facilitate the process that leads to these decisions, not to make them.

Taking ownership of the team's administrative tasks so they can focus entirely on coding.

Why it fails: While the Scrum Master helps, taking over all administrative tasks can create a dependency and prevent the team from learning how to manage their own environment. Servant leadership is about enabling the team to be self-sufficient, not becoming a personal assistant for the developers' logistics.

Making final decisions on which User Stories should be included in the Iteration during planning.

Why it fails: The decision on which stories to include is a collaborative effort between the Product Owner (who provides priority) and the Team (who provides capacity and commitment). The Scrum Master facilitates this negotiation but does not have the authority to make the final decision on content.

Setting individual performance goals for developers to ensure they meet the team's velocity expectations.

Why it fails: Setting individual goals and focusing solely on velocity can lead to toxic behaviors and reduced quality. A servant leader focuses on the health of the team and the quality of the output, rather than using individual metrics to drive performance, which often undermines collective accountability.

Require all team members to address their detailed status reports exclusively to the Product Owner.

Why it fails: Directing status reports to the Product Owner maintains the anti-pattern of upward reporting. The Daily Stand-up must remain a peer-to-peer synchronization meeting focused entirely on meeting the current iteration goals, rather than an administrative status briefing.

Replace the daily sync with an asynchronous chat channel to eliminate meetings entirely.

Why it fails: Replacing synchronous daily alignment with chat channels removes vital real-time collaboration. While asynchronous communication supports distributed teams, it cannot fully replicate the rapid problem-solving and high-bandwidth synchronization of a daily stand-up.

Attend the meeting silently only when invited, refusing to speak or facilitate under any circumstances.

Why it fails: Abandoning facilitation duties entirely leaves immature teams without guidance to fix broken processes. The Scrum Master must actively coach the team toward healthy collaboration patterns rather than completely withdrawing from the ceremony.

Reviewing and adjusting the Feature priorities in the Program Backlog

Why it fails: Feature prioritization and backlog refinement are the primary focuses of the PO Sync, not the Coach Sync. The PO Sync involves Product Management and Product Owners who make decisions about the 'what' and 'when' of the work, rather than the 'how' of the execution.

Demonstrating newly completed Features to the Business Owners

Why it fails: Feature demonstrations occur during the System Demo, which is a separate event intended for a broader audience including stakeholders. The Coach Sync is a tactical coordination meeting for the ART's internal leadership and is not intended for formal product demonstrations or stakeholder reviews.

Determining the Business Value for the team's PI Objectives

Why it fails: Business Value is assigned by Business Owners during the PI Planning event itself, specifically during the final plan review. It is not a topic for the Coach Sync, which happens during the execution phase of the PI to monitor the progress of those already-valued objectives.

The team achieved 100% predictability because they finished the uncommitted work

Why it fails: Predictability is not just about finishing work; it's about finishing the work you committed to. Because 'API Security' (a committed objective) was missed, the predictability score would be (10+0+5) / (10+8) = 83%, which is below a perfect score and indicates a missed commitment.

The uncommitted objective should have been given a Planned BV of zero

Why it fails: Uncommitted objectives still receive a Planned BV (to show their relative importance) and an Actual BV. However, for the calculation of the PI Predictability Measure, their Planned BV is excluded from the denominator to avoid penalizing the team if they do not reach those secondary goals.

Business Owners were incorrect to assign a 10 to Cloud Migration

Why it fails: The Scrum Master does not judge the Business Owners' value assignments. Instead, they use those values to measure how well the team delivered on the business's priorities. The focus remains on the team's execution and the accuracy of their planning rather than questioning the business's needs.

Accepted

Why it fails: Accepted risks are those that the train simply acknowledges and chooses to live with, often because the cost of mitigation is higher than the potential impact. If the RTE is actively working to find a solution, the risk is not merely being accepted; it is being actively managed.

Mitigated

Why it fails: A risk is mitigated when a plan is developed to reduce its impact or probability. While the RTE taking ownership is a step toward mitigation, 'Mitigated' usually implies that a specific technical or process-based countermeasure has already been identified and incorporated into the team's or train's plan.

Resolved

Why it fails: A risk is only resolved if it is completely eliminated or no longer poses a threat to the PI. Simply having an owner does not make the risk go away; it just means there is a clear line of accountability for dealing with it as the Program Increment progresses.

Scrum replaces all executive oversight with complete team autonomy, eliminating the need for any management reporting or governance.

Why it fails: Scrum does not eliminate governance or management reporting; instead, it replaces bureaucratic status reporting with transparency derived from working software and cadence. Leadership maintains visibility through Program Increment events and system demos.

Agile teams operate in complete isolation from program and portfolio layers, ensuring no outside interference alters their sprint backlogs.

Why it fails: Agile teams do not operate in isolation; they are synchronized to the Agile Release Train cadence and aligned with program objectives and strategic themes. Isolation destroys enterprise alignment and prevents coordinated solution delivery.

Scrum guarantees that every software release will be delivered with zero defects on the exact date predicted during portfolio budgeting.

Why it fails: Scrum and SAFe embrace empirical process control and continuous learning, recognizing that complex software development involves uncertainty. While predictability improves over time, guarantees of zero defects and exact milestone dates are unrealistic.

Instruct the team to mark the Feature as 'Blocked' and move it to the next PI's backlog.

Why it fails: Moving the Feature to the next PI without attempting to resolve the dependency is premature and undermines the planning process. The goal of PI Planning is to find ways to deliver the requested value. The Scrum Master should first facilitate a negotiation to see if the dependency can be accommodated.

Escalate the issue to the Release Train Engineer to have them force the other team to change.

Why it fails: While the RTE can facilitate, the Scrum Master should first encourage peer-to-peer collaboration and negotiation between the teams. Forcing changes through authority usually damages team morale and ignores the technical realities of the other team's capacity. Direct communication between the involved teams is always the preferred first step.

Record the risk on the ART Risk ROAMing board and proceed with the current team plan.

Why it fails: Recording the risk is necessary, but it does not solve the immediate planning conflict. Simply proceeding with a plan that is known to be unachievable is a failure of the planning process. The Scrum Master must help the team resolve the conflict so they can make a credible commitment.

Replace the Iteration Review with the System Demo so the team only participates in the ART-level event and avoids duplicating stakeholder time.

Why it fails: The System Demo shows integrated progress across teams but does not replace the team's own inspection of its Increment and backlog adaptation. Removing the Iteration Review would eliminate the team's opportunity to gather stakeholder feedback on its own work and to update the Team Backlog, which is a core Scrum accountability within SAFe.

Ask the Product Owner to present the team's completed stories at the System Demo instead, and cancel the Iteration Review until the team matures.

Why it fails: Cancelling the Iteration Review deprives the team of its regular inspect-and-adapt cycle and its direct stakeholder feedback loop. The Product Owner presenting at the System Demo addresses train-level transparency but does not substitute for the team inspecting its own Increment and adjusting the Team Backlog each Iteration.

Convert the Iteration Review into a status report delivered to the Release Train Engineer so the train has consistent metrics for the Inspect and Adapt workshop.

Why it fails: Turning the Iteration Review into a status report to the Release Train Engineer removes stakeholder inspection and backlog adaptation, reducing a Scrum event to reporting. Metrics for the Inspect and Adapt workshop come from the train's measurement system and the System Demo, not from replacing the team's review with a status update.

Facilitating the Scrum of Scrums to coordinate cross-team dependencies

Why it fails: The Scrum of Scrums is an ART-level event where representatives from teams coordinate dependencies and integration. It is facilitated at the train level, often by the RTE or a rotating representative, and is not one of the Scrum team's own events. The team sends a representative, but the event belongs to the ART.

Managing and updating the Program Board dependencies during PI Planning

Why it fails: The Program Board is an ART-level planning artifact used during PI Planning to visualize features, iterations, and cross-team dependencies. Managing it is a train-level activity involving all teams and the RTE, not one of the team's own Scrum events. The team contributes dependency information, but the board itself is not a team Scrum artifact.

Reviewing and adjusting the ART's PI Objectives during the Inspect and Adapt event

Why it fails: Reviewing and adjusting PI Objectives happens at the ART level during the Inspect and Adapt event, which involves all teams and stakeholders. It is not a team Scrum event. The team participates, but the activity belongs to the train-level cadence rather than the team's Iteration Planning, stand-up, review, or retrospective.

Establishing the ART's budget and approving the Lean Portfolio Management funding for the next PI.

Why it fails: Budgeting and funding decisions belong to Lean Portfolio Management, not to teams during PI Planning. Teams plan work within the funded capacity already provided to the ART. Involving teams in budget approval would confuse the roles and distract from their planning responsibilities, and it is not an activity performed in team breakouts.

Facilitating the management review and problem-solving session that follows the draft plan review.

Why it fails: The management review and problem-solving session is led by business owners and the Release Train Engineer, not by individual teams. Teams may be asked to adjust their plans based on its outcomes, but facilitating that session is not a team PI Planning responsibility. Assigning it to teams misplaces accountability and misunderstands the event's structure.

Negotiating the ART's top-level solution intent with enterprise architects outside the planning event.

Why it fails: Solution intent and high-level architectural direction are established by architects and product management, often before PI Planning, and are inputs to the event rather than team activities within it. Teams consume this guidance when planning their work. Negotiating solution intent outside the event is not a PI Planning responsibility and would remove teams from the collaborative planning the event requires.

Schedule a separate meeting with your team's Product Owner to rewrite all user stories with clearer acceptance criteria for the next PI.

Why it fails: This action focuses only on one team and does not leverage the ART-level improvement process established by the Inspect and Adapt event. The root cause was identified during a collaborative workshop, and addressing it should involve the broader ART. A team-specific meeting may help locally but misses the opportunity to create a systemic solution that benefits all teams.

Update the team's Definition of Done to include a mandatory review of acceptance criteria by the Product Owner before sprint planning.

Why it fails: While improving acceptance criteria is valuable, the problem-solving workshop is an ART-level event, and the root cause may affect multiple teams. Making a unilateral change to one team's Definition of Done does not address the systemic issue across the ART. The Scrum Master should first participate in the ART-level improvement planning to ensure a coordinated solution, rather than acting independently.

Escalate the issue to the Business Owners and request additional funding for a dedicated business analyst to write acceptance criteria.

Why it fails: Escalating to Business Owners for funding is premature and does not follow the ART's improvement process. The Inspect and Adapt event is designed to identify and prioritize improvements, which are then added to the ART backlog. Requesting external resources bypasses the collaborative problem-solving approach and may not address the root cause effectively across teams.