Troubleshooting Scenario Questions

Instruct the Product Owner to stop adding Stories to the Iteration Backlog until the current work is finished.

Why it fails: Directing the Product Owner to stop work ignores the collaborative nature of the team and fails to address the root cause of poor estimation. It creates a siloed environment where the Scrum Master acts as a gatekeeper rather than a facilitator of team flow and shared understanding.

Reduce the team's available capacity for the next three Iterations to ensure they have enough buffer time.

Why it fails: Arbitrarily reducing capacity without team consensus avoids the core issue of poor estimation and lack of clarity. While buffers can be useful, they do not solve the underlying problem of taking on unrefined work, which will continue to impact quality and flow regardless of capacity.

Assign the most complex Stories to the most senior developers to ensure they are completed on time.

Why it fails: Assigning tasks to specific individuals undermines the principle of self-organization and team accountability. The Scrum Master's role is to facilitate the team in deciding how to distribute work, ensuring that knowledge is shared and that the team grows collectively rather than relying on silos.

Instruct the team to ignore production support requests during the Iteration and focus solely on planned stories to meet the Iteration Goal.

Why it fails: Ignoring production support is unrealistic and can harm the product and stakeholders. The Scrum Master should not direct the team to disregard operational needs. Instead, they should help the team and Product Owner find a balance. This action could lead to customer dissatisfaction and increased technical debt.

Recommend that the team extend their Iteration by a few days to complete the unplanned work, and adjust the next Iteration accordingly.

Why it fails: Extending the Iteration violates the principle of timeboxing and can disrupt the ART's cadence. In SAFe, Iterations are fixed-length to maintain rhythm and synchronization. The Scrum Master should not advocate for changing the timebox; rather, they should help the team plan for unplanned work within the fixed cadence.

Ask the Release Train Engineer to assign a separate team to handle all production support so the team can focus on planned work.

Why it fails: While a separate support team might be an option in some contexts, it is not the first action for the Scrum Master / Team Coach. This decision involves broader organizational considerations and may not be feasible. The Scrum Master should first help the team manage the work within their current constraints.

The team is not conducting daily stand-ups effectively, leading to poor coordination.

Why it fails: Ineffective stand-ups would typically affect iteration execution and goal completion. Since the team meets iteration goals, daily coordination is probably sufficient. The predictability drop is at the PI level, pointing to planning and commitment issues rather than daily execution.

The team is not using the Program Board to track dependencies, causing integration delays.

Why it fails: While dependency tracking is important, the symptom of meeting iteration goals but missing PI Objectives is more directly linked to overcommitment at the PI level. Integration delays would likely also impact iteration goals. The root cause is more likely in how PI Objectives are selected and sized.

The team is not breaking down features into stories small enough to fit within an iteration.

Why it fails: The team meets its iteration goals, so story sizing is likely adequate. The issue emerges at the PI level, where committed PI Objectives are not being met despite iteration success. This suggests a disconnect between iteration execution and PI planning commitments, not a story-sizing problem.

Accept the demo as valid because the team's own iteration goals were met and the feature works in their environment.

Why it fails: The System Demo is not a team-level iteration review; it exists to demonstrate the integrated solution across the ART. Accepting a stubbed demo hides a real integration risk and gives stakeholders a false signal. The Scrum Master must uphold the event's purpose rather than let individual team success substitute for ART-level integration, which is the whole point of the event.

Log a defect against the other team for failing to provide an integrated build to Team Delta before the demo.

Why it fails: Assigning blame to another team is not the Scrum Master's role and does not address why the presenter chose a stub. The issue is the demo's integrity, not a single team's delivery. The Scrum Master should facilitate a conversation about integration practices and dependencies, not file defects that damage trust and obscure the systemic cause.

Cancel the remainder of the System Demo and reschedule it for the next iteration once integration is complete.

Why it fails: Cancelling the entire demo is an overreaction and removes the opportunity for stakeholders to inspect and adapt on the other teams' work. The Scrum Master should correct the misrepresentation and continue with the rest of the agenda, then help the team plan the missed integration. Cancelling would also violate the cadence of the ART event and reduce transparency.

Ask the Product Owner to reduce the number of stories in each Iteration so the team has more time to figure out technical issues.

Why it fails: Reducing the workload does not address the underlying issue of the team's dependency on the Scrum Master for technical decisions. It may even mask the problem and lower the team's velocity. The Scrum Master should focus on building the team's autonomy, not on adjusting scope. While the Product Owner may adjust scope for other reasons, doing so here would not develop the team's problem-solving skills and could harm the team's growth and delivery predictability.

Continue making technical decisions to keep the team on schedule, since the Scrum Master has more experience.

Why it fails: Making technical decisions for the team undermines self-organization and prevents the team from developing its own problem-solving skills. While the Scrum Master may have experience, the role is to coach the team to make its own decisions. Over time, this dependency will slow the team down and reduce ownership. The Scrum Master should instead facilitate the team's decision-making process, not substitute for it, even if it means short-term delays.

Stop attending daily stand-ups so the team is forced to solve problems on its own.

Why it fails: Withdrawing from daily stand-ups entirely is an overcorrection that removes necessary facilitation and impediment removal. The Scrum Master should still be present to help the team identify and address blockers, but should shift from solving technical problems to coaching the team through them. Abandoning the event can leave the team without support for process issues and may reduce transparency. The goal is to change the nature of the Scrum Master's participation, not to disappear.