Select Two (Multi-Select) Questions

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.

Directing the Developers on technical design and architecture decisions during the Iteration.

Why it fails: Directing technical design and architecture is not a Scrum Master service and undermines team self-management. Developers own how they build the solution, and architects provide guidance at the ART level. A Scrum Master who dictates technical decisions removes ownership from the people closest to the work and conflicts with the coaching role SAFe expects.

Approving whether completed stories meet the Definition of Done before they are accepted.

Why it fails: Approving completed work against the Definition of Done is not a Scrum Master service. The team applies the Definition of Done, and the Product Owner accepts stories based on acceptance criteria. Turning the Scrum Master into an approver creates a gate that slows flow and contradicts the team's ownership of quality and the Product Owner's ownership of value.

Owning and prioritizing the Team Backlog to maximize the value delivered each Iteration.

Why it fails: Owning and prioritizing the Team Backlog is a Product Owner accountability, not a Scrum Master service. When a Scrum Master takes this on, the separation of accountabilities collapses, and the team loses a clear product direction owner. Backlog ordering requires product and customer insight that belongs with the Product Owner, so this is definitively not part of the Scrum Master role.

Document all team member complaints in detail and report them to the Release Train Engineer for resolution.

Why it fails: The Retrospective is not a complaint-logging exercise, and reporting individual complaints to the Release Train Engineer can erode trust and bypass the team's ownership of its improvements. The Scrum Master may help escalate systemic impediments, but only with the team's agreement and in a constructive manner. Documenting complaints for external reporting is not a core responsibility during this event.

Assign specific improvement actions to individual team members to ensure accountability for the next Iteration.

Why it fails: While accountability matters, the Scrum Master should not unilaterally assign actions. The team owns its improvement backlog and should decide collectively who will do what. Imposing assignments can reduce ownership and may not reflect the team's actual capacity or interests. The Scrum Master's role is to facilitate the team's decision-making, not to direct it.

Decide on the team's improvement backlog items yourself to save time and avoid prolonged discussion.

Why it fails: The team should own its improvement backlog. When the Scrum Master dictates the items, the team loses ownership and may not commit to the changes. The Retrospective is a team event, and the Scrum Master facilitates the team's self-discovery and decision-making. Saving time by deciding for them undermines the event's purpose and long-term effectiveness.

The Scrum Master defines the PI objectives for the team.

Why it fails: PI objectives are collaboratively defined by the team and the business owners. If the Scrum Master defines them, they are missing the opportunity to build team ownership and commitment. The team needs to be the one defining their objectives to ensure they truly understand and believe in them.

The Scrum Master is responsible for presenting the final PI objectives to the ART.

Why it fails: The team members usually present their own PI objectives to the ART. This builds transparency and confidence across the train. The Scrum Master may support them, but the team should lead the presentation to demonstrate their commitment and clear understanding of the goals they have signed up for.

The Scrum Master acts as the decision-maker for all feature prioritization.

Why it fails: Feature prioritization is the responsibility of the Product Owner, guided by the ART stakeholders. The Scrum Master must not interfere with this role, as their focus is on the process and the team's ability to execute, not on the business value prioritization which rests with the business owners.

Ensuring all team members are assigned to a specific Scrum team

Why it fails: Assigning people to teams is part of 'Organizational Readiness.' While essential for PI Planning to function, it focuses on the structure of the train rather than the work (content) that the train will be performing during the upcoming ten-week Program Increment cycle.

Setting up the physical or virtual Program Board

Why it fails: Setting up tools and boards is part of 'Facility Readiness.' This involves the infrastructure needed to support the event, rather than the strategic content or product vision that guides the actual planning decisions made by the teams during their breakout sessions.

Finalizing the iteration-by-iteration plan for each team

Why it fails: Teams finalize their iteration plans *during* the PI Planning event breakouts, not before it. Content readiness involves preparing the inputs (like the backlog) so that teams can effectively perform this planning during the event itself without being blocked by missing information.

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.

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.

Release Train Engineer

Why it fails: The Release Train Engineer facilitates the overall PI Planning event at the ART level but does not lead individual team breakouts. Their role is to manage the Scrum of Scrums and ensure that the train as a whole is progressing, rather than focusing on the specific tasks of one team.

System Architect

Why it fails: The System Architect provides technical guidance across the ART and may visit various teams during breakouts to answer specific questions. However, they are not responsible for facilitating the breakout session itself, as their focus is on the architectural runway and ensuring technical alignment across all teams.

Business Owner

Why it fails: Business Owners attend PI Planning to set the mission and assign business value to the objectives during the second day. While they interact with teams, they do not facilitate the breakout sessions, as their role is more about providing high-level business context and final approval of the plans.

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.

Writing and maintaining the Program Backlog.

Why it fails: The Program Backlog is managed by Product Management. The Scrum Master focuses on the team's internal processes and execution. While they provide feedback on the backlog, they are not responsible for its maintenance, prioritization, or definition, as their role is to facilitate the team's ability to execute against the defined plan.

Setting the vision and roadmap for the ART.

Why it fails: The vision and roadmap are the responsibility of Product Management, System Architects, and Business Owners. The Scrum Master's focus is inward on the team and outward to assist with coordination; they do not set the strategic direction or the product vision, as that is a high-level leadership responsibility.

Prioritize the product backlog items for the team.

Why it fails: Prioritizing the product backlog is the exclusive role of the Product Owner. The Scrum Master should not interfere with the PO's responsibility but rather support the team in understanding those priorities. This separation of concerns is vital for the health of the Agile team and the clarity of their mission.

Assign tasks to team members based on their specific technical skills.

Why it fails: Assigning tasks destroys team autonomy and the self-organizing culture of Agile. Team members should pull tasks based on their own judgment of their skills and the team's needs. The Scrum Master should encourage self-assignment, which fosters a sense of personal responsibility and team-wide ownership of the work being delivered.

Define the acceptance criteria for all user stories in the iteration.

Why it fails: Acceptance criteria are defined by the Product Owner in collaboration with the team, not the Scrum Master. The Scrum Master ensures that these criteria are clear and testable, but they should not be the one writing them. This keeps the roles clear and ensures the PO retains product focus.

Delay dependency mapping until after PI Planning to avoid disrupting the team's flow during the event.

Why it fails: Dependency mapping is a core activity during PI Planning. Delaying it would prevent the ART from addressing cross-team dependencies in real time, leading to integration issues later. The SM should facilitate dependency identification during the event, not postpone it.

Instruct the Product Owner to write the PI Objectives on behalf of the team to save time.

Why it fails: PI Objectives should be written by the team, not the PO. The team's ownership of objectives is crucial for commitment and alignment. The SM should coach the PO to collaborate with the team, not replace them. This action would undermine team self-management and fail to develop the team's planning skills.

Take over the team's planning session to ensure the PI Objectives are aligned with the portfolio strategy.

Why it fails: Taking over contradicts the Scrum Master / Team Coach's role as a facilitator and servant leader. The team must own their plan. The SM should guide, not dictate. Aligning with portfolio strategy is important, but the SM should help the team understand strategic themes and let them create their own objectives.

Assign clear tasks to each team member at the start of each Iteration to ensure work is distributed evenly.

Why it fails: Assigning tasks undermines self-management. The Scrum Master / Team Coach should help the team learn to pull work and self-organize around the Iteration goals. While even distribution may seem fair, it removes the team's ownership of how work gets done and reinforces dependence on the Scrum Master, which is the opposite of the desired outcome.

Make key decisions for the team during Iteration Planning to keep the event on schedule.

Why it fails: Making decisions for the team may speed up a single event, but it erodes self-management and teaches the team to defer to the Scrum Master. The goal is to build the team's capacity to decide together, even if it takes more time initially. Prioritizing schedule over team development reinforces the dependency the team is struggling with.

Direct the team to follow a strict task assignment process defined by the Scrum Master until they improve.

Why it fails: Imposing a process contradicts the principle of self-management. The Scrum Master / Team Coach should help the team discover and adapt their own way of working, not mandate a rigid process. This approach may yield short-term compliance but fails to develop the team's ability to self-organize, which is the core issue.

Publicly reprimand the individuals who blame others, to set an example of acceptable behavior.

Why it fails: Public reprimand increases fear and defensiveness, worsening the blame culture. It damages psychological safety and may cause individuals to withdraw further. The Scrum Master should model respectful behavior and coach privately, not punish publicly. This action contradicts the servant-leader role and is likely to erode trust even more, making open discussion less likely.

Recommend that the team skip retrospectives until they can interact without conflict, to avoid further tension.

Why it fails: Skipping retrospectives removes the team's primary inspect-and-adapt mechanism and avoids the very conversations needed to heal. It may temporarily reduce tension but will allow underlying issues to fester. The Scrum Master should instead create a safe structure for difficult conversations. This action fails to build the team's capacity for conflict resolution and undermines continuous improvement.

Ask the Release Train Engineer to reassign the most vocal team members to other teams to reduce friction.

Why it fails: Reassigning team members avoids the problem and disrupts team stability. It does not teach the team how to resolve conflict or build trust. The Scrum Master should help the team develop these skills, not remove individuals. This action may also be seen as punitive and could damage morale across the ART. It fails to address the root cause of low trust and poor conflict resolution.

Ask the Release Train Engineer to assign the team a mentor from another team to explain SAFe.

Why it fails: While mentoring can be helpful, assigning a mentor is not a primary action for the Scrum Master / Team Coach to connect the team with the ART. The coach should directly facilitate the team's engagement in ART events and practices. This option shifts responsibility to the RTE and does not actively build the team's understanding.

Instruct the team to focus solely on their own iteration goals and avoid distractions from other teams.

Why it fails: This contradicts SAFe's emphasis on collaboration and alignment across the ART. Teams must coordinate and manage dependencies with other teams. Isolating the team would harm program execution and prevent the team from understanding how their work contributes to the train's objectives.

Coach the team to establish and maintain their team board and information radiators for transparency.

Why it fails: While transparency is important, the team board primarily serves the team's internal coordination. It does not directly connect the team to the wider ART. The question asks about connecting with the ART, which involves events and collaboration across teams, not just local visibility.

Instruct the Product Owner to stop changing priorities and freeze the backlog for the entire Program Increment.

Why it fails: Freezing the backlog for an entire Program Increment is unrealistic and outside the Scrum Master / Team Coach's authority. Priorities can legitimately change as new information emerges, and the role is to coach collaboration, not issue directives to the Product Owner. This option confuses coaching with command-and-control and would damage the working relationship.

Escalate to the Release Train Engineer that the Product Owner is not performing and request a replacement.

Why it fails: Escalating for a replacement is a premature and punitive response to a collaboration gap. The Scrum Master / Team Coach should first coach the Product Owner and team on refinement and scope-change agreements. Escalation may be appropriate for persistent systemic issues, but it is not the first action and does not build the team's capability to resolve conflict.

Take over backlog refinement meetings and write the acceptance criteria for each story on behalf of the team.

Why it fails: Writing acceptance criteria and running refinement on the team's behalf removes ownership from both the Product Owner and the team. The Scrum Master / Team Coach facilitates and coaches; they do not become the backlog author or proxy Product Owner. This option would create dependency and blur accountabilities, making the underlying collaboration problem worse.

Rewrite the team's working agreements yourself with stricter rules and present them as non-negotiable so the team has clear boundaries.

Why it fails: Imposing stricter agreements removes the team's authorship of its own norms, and norms people did not help create are rarely followed. The Scrum Master / Team Coach facilitates agreement-making; the team owns the result. This approach also sidesteps the retrospective conversation that would reveal why members are disengaging, leaving the underlying cause unaddressed while adding rules the team may quietly ignore.

Document each missed agreement and submit the record to the team's functional manager so attendance expectations can be enforced through performance management.

Why it fails: Escalating attendance to functional managers converts a team working agreement into a managerial mandate and undermines the team's ownership of its own norms. It also risks damaging the psychological safety the coach needs to address deeper causes such as workload or unclear priorities. Performance management may occasionally be warranted, but using it as the first response to missed working agreements is inconsistent with the coaching role.

Suspend the team's refinement sessions until attendance improves, so the team experiences the consequences of skipping them.

Why it fails: Cancelling refinement as a punishment removes a practice the team needs to prepare Stories and improve flow, which would likely worsen the slipping Iteration Goals. Withholding a valuable event to force compliance is coercive and treats a symptom rather than the cause. The coach should instead help the team understand why refinement matters and how its absence affects their ability to meet goals.

Take ownership of updating the team's Iteration board daily so it stays accurate for ART-level reporting.

Why it fails: Owning the board makes the coach a workflow administrator and removes the team's responsibility for transparency. In SAFe, the team is accountable for keeping its own information visible so that ART-level reporting is trustworthy. A coach who maintains the board also becomes a bottleneck and can mask the team's real progress or struggles. Transparency is a team behavior, not a service the coach performs for them.

Assign each team member a specific role in every team event so responsibilities are always covered.

Why it fails: Assigning roles unilaterally shifts decision-making back to the coach and undercuts self-management. SAFe teams are expected to organize their own work and decide how to run their events. Fixed assignments also reduce flexibility when team composition or workload changes. Coaching is about growing capability, not about the Scrum Master / Team Coach allocating who does what inside the team's own ceremonies.

Decide which Stories the team should pull next based on the ART's highest-priority Features.

Why it fails: Prioritizing and selecting Stories is the Product Owner's domain with the team, not the Scrum Master / Team Coach's. When the coach starts assigning work, the team loses ownership of its commitments and stops practicing the trade-off thinking that self-management requires. The coach should help the team understand priorities and dependencies, but should never take over the selection decision itself.

Cancel the Retrospective and schedule a defect triage meeting instead, since the team's immediate priority is fixing defects.

Why it fails: Replacing the Retrospective with a defect triage meeting ignores the team's need to reflect on how they work and why defects occurred. While triaging defects may be necessary, it should not replace the Retrospective. The Scrum Master should help the team integrate defect analysis into the Retrospective, not abandon the event.

Shorten the Retrospective to 15 minutes and use the remaining time for defect fixing.

Why it fails: Shortening the Retrospective to 15 minutes severely limits the team's ability to have a meaningful discussion and identify improvements. The Retrospective is timeboxed, but it should not be arbitrarily cut short to do other work. The Scrum Master should protect the event's timebox and ensure sufficient time for reflection and action planning.

Allow the team to cancel the Retrospective this once, since fixing defects is more urgent and the team can retrospect later.

Why it fails: Cancelling the Retrospective undermines the Scrum framework and removes the team's dedicated time for process improvement. Skipping it may lead to recurring issues and missed opportunities to address systemic causes of defects. The Scrum Master should not permit the event to be skipped; instead, they should help the team see its value and facilitate effectively.