Scrum Master Core Competencies practice questions

Allow the changes to keep the stakeholder satisfied.

Why it fails: Accepting ad-hoc changes mid-Sprint creates instability and prevents the team from meeting their commitment. Continuous interruptions diminish throughput and violate the foundational principle of Sprint stability, which is intended to protect the Developers from external influence and ensure the integrity of the work items currently in progress.

Facilitate a discussion with the team and stakeholder regarding the impact of these interruptions.

Why it fails: This approach addresses the root cause by fostering transparency and understanding. By surfacing the impact on the Sprint Goal, the Scrum Master helps stakeholders recognize the cost of context switching. This collaborative problem-solving approach empowers the team to set boundaries while maintaining a positive relationship with the stakeholder group.

Ask the Developers to ignore the stakeholder.

Why it fails: Ignoring a stakeholder is unprofessional and damages organizational relationships. Scrum promotes transparency and collaboration, not isolation. The Scrum Master should act as a bridge between the team and stakeholders, providing coaching to ensure that communication channels are effective without disrupting the team's focus on the Sprint Goal.

Ignore the log; it is just a routine error.

Why it fails: Ignoring negative feedback loops or team friction is a failure of the Scrum Master's role. Proactive engagement is necessary to ensure the team learns from their interactions. If the Scrum Master stays passive, the team will continue to operate in a silo, missing critical opportunities to pivot the product's direction.

Instruct the team to accept all future feedback.

Why it fails: Not all feedback is actionable or aligned with the product vision. The team needs to evaluate feedback, not blindly accept it. The Scrum Master should help the team develop the skills to assess and prioritize input effectively, ensuring the product roadmap remains coherent and aligned with the overarching strategic goals.

Replace the stakeholder with a more compliant one.

Why it fails: Removing stakeholders because they provide difficult feedback is unprofessional and counter-productive. The goal is to collaborate with all relevant parties, not to build an echo chamber. The Scrum Master's role is to bridge gaps and mediate conflict, not to manipulate the stakeholder group for the sake of convenience.

Ask each Developer directly, in turn, to state one thing that went wrong during the Sprint.

Why it fails: Directly asking each person to state what went wrong can increase pressure and may lead to defensive or superficial answers. It can also feel like a blame exercise. The Retrospective should be a collaborative and safe environment. Forcing participation in this way may backfire and reduce openness, especially if the team is already hesitant to speak.

Share your own observations about the team's performance to get the conversation started.

Why it fails: While sharing observations can sometimes prompt discussion, it risks the Scrum Master dominating the conversation and steering the team's reflection. The Retrospective is for the team to inspect itself. The Scrum Master should facilitate, not lead with their own judgments. This action could inhibit the team's ownership and may not address the underlying safety issue.

Cancel the Retrospective and reschedule it for a time when the team is more comfortable.

Why it fails: Cancelling the Retrospective is never appropriate because it is a required Scrum event. The Retrospective provides a dedicated opportunity to inspect and adapt. Postponing it does not solve the underlying issue of hesitancy and may signal that the event is optional. The Scrum Master should work to improve the current session rather than cancel it.

Write the Definition of Done for the team.

Why it fails: The team must own their process and quality standards to ensure commitment and adherence. If the Scrum Master imposes the definition, the team lacks the necessary buy-in and understanding of the technical requirements needed to sustain high-quality output throughout the development life cycle and future iterations.

Force the team to meet daily until they agree on criteria.

Why it fails: Forcing meetings is coercive and counter-productive to the Scrum values of respect and openness. Effective Scrum Masters foster psychological safety and team autonomy. A collaborative approach, rather than a punitive one, ensures the team feels empowered to define standards they can actually maintain during the development cycle.

Wait for the Product Owner to define the criteria.

Why it fails: While the Product Owner is a stakeholder, the Definition of Done is a team-wide responsibility. Waiting for a single person to dictate quality standards ignores the expertise of the Developers who perform the work, potentially leading to unrealistic expectations or standards that do not reflect the reality of development.

Update the policy to include Refinement.

Why it fails: Adding refinement to the Sprint Review conflates two distinct Scrum events. Refinement is an ongoing activity to prepare items for future Sprints, whereas the Sprint Review is an inspection of the current increment. Misaligning these events leads to fragmented focus and prevents effective stakeholder engagement during the review.

Allow the session to continue as it is.

Why it fails: Allowing an incorrect implementation of Scrum rituals leads to process decay and poor team performance. If the Sprint Review is treated as a refinement session, the team loses the opportunity to gather critical stakeholder feedback on the work produced, which is the cornerstone of empirical product development.

Host a separate session for Backlog Refinement.

Why it fails: While refinement is necessary, this does not fix the misunderstanding of the Sprint Review. The Scrum Master must address the conceptual error directly so that the stakeholders understand the difference between inspecting a completed increment and the ongoing collaborative work of preparing future items for the team.

Mandate a lower WIP limit for the next Sprint.

Why it fails: Directly mandating a change violates the self-organizing principle of Scrum teams. The team needs to reach this conclusion through their own inspection of the data. When the Scrum Master enforces rules, the team loses ownership of their process, which can lead to decreased motivation and less effective process improvement.

Ask the Product Owner to provide fewer items.

Why it fails: While the Product Owner influences the backlog, the team is responsible for managing their own WIP. Blaming the Product Owner ignores the team's capacity management and their ability to push back on scope. The Scrum Master must coach the team to take accountability for their own capacity and focus.

Increase the Sprint length to finish more work.

Why it fails: Increasing Sprint length is a common anti-pattern that masks the underlying issues of poor focus and ineffective work management. It does not solve the root cause of high WIP. The team will likely continue to struggle with finishing work, regardless of how long the Sprint is extended to accommodate them.

Assigning specific tasks to team members.

Why it fails: Assigning tasks is a command-and-control practice that undermines team self-organization. Servant-leaders trust the team to distribute work based on their own capacity and expertise. By directing work, the Scrum Master becomes a bottleneck and prevents the team from developing the skills needed for true collective ownership and accountability.

Judging the team's performance based on velocity.

Why it fails: Using velocity as a performance metric is an anti-pattern that encourages gaming the system. A servant-leader focuses on team health, value delivery, and continuous learning. Judging the team on metrics alone diminishes psychological safety and distracts the team from the primary goal of creating high-quality, customer-focused product increments.

Start asking each member specific questions.

Why it fails: Asking questions maintains the status-update dynamic. The Scrum Master should step back to let the team take charge of their communication. When the Scrum Master drives the conversation, the team remains dependent on them, which stunts their growth as a self-organizing unit and prevents the emergence of true peer-coordination.

Cancel the Daily Scrum until they can do it properly.

Why it fails: Canceling the event removes the opportunity for inspection and adaptation. The Scrum Master should facilitate growth through coaching, not by withholding essential rituals. This action would disrupt the team's rhythm and further erode their ability to coordinate effectively, causing more harm than good to the overall development effort.

Report the lack of engagement to management.

Why it fails: Reporting the team to management violates the trust and privacy of the team. The Scrum Master should work with the team privately to improve their dynamics. External intervention undermines the psychological safety required for the team to be honest about their challenges and learn from their mistakes in a safe environment.

Accept the feature if the team has capacity.

Why it fails: Adding features mid-Sprint disrupts the focus and violates the Sprint commitment. Even if capacity exists, it undermines the planning process. The Scrum Master should ensure that the team focuses on the current Sprint Goal to ensure predictability, which is a key benefit of the Scrum framework for stakeholders.

Add the feature but remove an equal amount of work.

Why it fails: Swapping items during a Sprint is a common anti-pattern that creates churn and confusion. It complicates the team's commitment and makes progress tracking difficult. The Scrum Master should guide stakeholders to understand that the Sprint is a fixed-duration commitment that should not be changed without a significant reason.

Ask the team to vote on the new request.

Why it fails: Voting on scope changes does not respect the Product Owner's authority over the backlog. It also distracts the team from their current work. The Scrum Master should focus on coaching the stakeholders on the Scrum process, ensuring that requests are handled through the appropriate, defined channels during future planning.

Respect the team's decision to skip the meeting.

Why it fails: Skipping mandatory Scrum events is not an option for a professional team. The Scrum Master must ensure the Scrum framework is followed to protect the team's long-term effectiveness. Allowing the team to skip retrospectives leads to the normalization of deviance and the persistence of systemic bottlenecks that hinder performance.

Report the team to management for non-compliance.

Why it fails: Reporting the team destroys trust and violates the spirit of a safe, collaborative environment. The Scrum Master must handle this through coaching and internal facilitation, not through external punitive actions. Using management to enforce compliance creates a culture of fear that discourages honesty and prevents genuine, team-led process improvement.

Assign tasks to the best-suited team member.

Why it fails: Assigning tasks is a managerial behavior that prevents the team from learning to distribute work themselves. It creates a culture of dependency on the Scrum Master, ensuring that the team will never learn to organize effectively without external intervention, which limits the overall potential of the group to perform.

Attend all meetings to ensure they remain focused.

Why it fails: The Scrum Master should not be a constant supervisor. Being present at every meeting can lead to the team looking to the Scrum Master for guidance rather than solving problems amongst themselves. The Scrum Master should eventually be able to step back, allowing the team to facilitate their own events.

Define the team's workflow and metrics.

Why it fails: Defining the workflow for the team robs them of the opportunity to develop their own processes. A self-managing team must define their own way of working to ensure it fits their specific context and technical reality, otherwise, the process will be seen as an external imposition rather than a tool.

Choose the Sprint Goal for them.

Why it fails: The team must define the goal, as they are the ones who must commit to achieving it. Imposing a goal leads to lack of ownership and potential failure. The Scrum Master should act as a facilitator, not a dictator, guiding the team toward a goal they believe in and can achieve.

Cancel the Sprint Planning session.

Why it fails: Canceling the session is an extreme measure that delays work without solving the root cause of the disagreement. The Scrum Master should work through the conflict using facilitation techniques to help the team reach a consensus. Avoiding the hard work of building consensus stunts the team's collaborative maturity and growth.

Suggest that the Product Owner dictates the goal.

Why it fails: While the Product Owner provides the 'what', the Sprint Goal is a result of the team's collaborative planning. Simply letting the Product Owner dictate it ignores the team's capacity and reality. The Scrum Master must ensure the goal is a negotiated agreement that reflects both product strategy and technical feasibility.

Address the behavior in the next group meeting.

Why it fails: Publicly confronting someone can be perceived as an attack and damages psychological safety. The Scrum Master should handle interpersonal conflicts in private, using coaching to explore the root cause of the negativity. Public shaming discourages open participation and creates a culture of fear that is detrimental to team performance.

Ask the team to vote on removing the member.

Why it fails: Voting to remove a team member is highly divisive and unprofessional. It creates a toxic environment of exclusion. The Scrum Master should focus on coaching and mediation rather than encouraging team conflict. Building a high-performing team involves working through interpersonal challenges, not just discarding people who cause temporary friction.

Ignore the negativity if the team's velocity is high.

Why it fails: Negativity impacts team health and morale, which will eventually degrade velocity and quality. Ignoring the issue is a failure to protect the team's long-term sustainability. A Scrum Master must prioritize the human aspect of the team, as sustainable performance is impossible in an environment where individuals feel demoralized or unsupported.

Create the report to maintain good relations.

Why it fails: Creating custom reports reinforces the idea that Scrum is not transparent enough. It encourages stakeholders to look at manual documents rather than the actual product progress. The Scrum Master should coach stakeholders to look at the Sprint Backlog or the increment itself to gain a true understanding of progress.

Ask the developers to include more detail in tasks.

Why it fails: Asking developers to increase task detail for reporting purposes is a waste of effort. It distracts them from delivering value and adds no benefit to the product development process. The Scrum Master should focus on helping the stakeholders understand existing Scrum artifacts rather than adding overhead to the developers.

Tell the stakeholder they are not allowed access.

Why it fails: Transparency is a pillar of Scrum, and stakeholders should have visibility into the process. Refusing access creates unnecessary friction and suspicion. The Scrum Master should provide visibility in a way that respects the Scrum framework, guiding stakeholders toward the appropriate events and artifacts for meaningful information.

Force the team to fix debt before any new work.

Why it fails: Forcing the team to stop new work is a command-and-control approach that ignores business priorities. The team must work with the Product Owner to balance new features and debt reduction. A sustainable balance ensures the product remains valuable while still being maintainable, which is the desired outcome for any Scrum team.

Tell the Product Owner to stop adding new features.

Why it fails: The Scrum Master does not have the authority to halt feature development. The Product Owner is responsible for the backlog prioritization. The Scrum Master's role is to facilitate the conversation so the Product Owner understands the risks, ensuring that business decisions are based on a full picture of the product's health.

Ask the developers to work extra hours to fix it.

Why it fails: Asking for overtime is a short-term, unsustainable solution that leads to burnout. It does not solve the structural problems that cause technical debt. The Scrum Master must advocate for a sustainable pace, ensuring that the team works within their capacity to address debt as part of their regular development cycle.

Direct the Product Owner to immediately reduce the scope to match exact historical velocity to prevent team burnout.

Why it fails: Directing the Product Owner to cut scope to exact historical velocity removes the team's own forecasting from Sprint Planning and treats velocity as a cap rather than a planning input. The Scrum Master should surface the concern and let the team and Product Owner negotiate a Sprint Goal together. Velocity-based scope limits apply when the team itself chooses them.

Advise the development team to accept all requested stories and figure out how to work overtime to meet the sprint goal.

Why it fails: Overtime masks the velocity mismatch rather than resolving it; the Scrum Master should let the team negotiate scope with the Product Owner based on historical data. Directing overtime contradicts Scrum's sustainable pace principle, though it would suit a command-and-control environment where utilisation targets override empirical planning.

Take over Sprint Planning by selecting the user stories yourself based on your independent assessment of team capability.

Why it fails: Selecting stories unilaterally removes the Developers' authority to determine how much work they can complete, which Sprint Planning reserves to them. The Scrum Master facilitates the conversation between Product Owner and Developers rather than deciding scope. Self-selection by the Scrum Master would be appropriate only if the team were absent or unable to participate.

Add the feature to the current Sprint to satisfy the stakeholder.

Why it fails: Adding unplanned work mid-Sprint disrupts the Developers' flow and jeopardizes the Sprint Goal. The Scrum Master should prevent this behavior, as it undermines the team's commitment and planning process. Consistent scope creep leads to unpredictable velocity and reduces the overall quality of the delivered increment within the timeboxed iteration.

Ask the Product Owner to decide if the team should perform the work.

Why it fails: While the Product Owner manages the Product Backlog, they should not dictate mid-Sprint changes that alter the Sprint Backlog. The Scrum Master must intervene to educate the Product Owner on the importance of Sprint stability. The Developers own the Sprint Backlog and must be protected from external task injection.

Direct the Developers to work on the feature if they have extra capacity.

Why it fails: Instructing the team to add work based on perceived capacity ignores the Sprint Goal. The Scrum Master should facilitate a culture where any spare capacity is used for refining backlog items or improving technical practices, not for unplanned feature development. This prevents the team from becoming a reactive service department.

Facilitate the Daily Scrum personally to ensure it stays on track.

Why it fails: The Scrum Master should not facilitate the Daily Scrum; it is an event for the Developers. Taking control creates dependency on the Scrum Master and prevents the team from taking ownership of their synchronization. The goal is self-management, which is undermined when the Scrum Master runs the meeting.

Require every team member to provide a detailed status report to the Scrum Master.

Why it fails: The Daily Scrum is for the Developers, not for reporting status to the Scrum Master. This approach shifts the focus from team collaboration to command-and-control reporting, which is contrary to Scrum values. It creates a hierarchical dynamic that stifles the transparency and self-organization necessary for an agile team.

Extend the Daily Scrum to 45 minutes to allow for full technical discussions.

Why it fails: Extending the timebox is a direct violation of Scrum guidelines and fails to address the underlying issue of poor meeting hygiene. Longer meetings usually lead to lower energy and reduced engagement. The focus must be on keeping the meeting concise, not on making it a venue for everything.

Create a detailed project plan to track individual tasks.

Why it fails: Detailed individual task plans are a command-and-control practice that discourages self-management. Scrum teams should focus on the collective goal and shared progress. A project plan often becomes a static document that fails to capture the dynamic reality of development, thus working against the needed transparency and team autonomy.

Ask the Product Owner to provide daily status updates to stakeholders.

Why it fails: Daily status updates to stakeholders create an unnecessary layer of reporting that distracts the Product Owner. Transparency should be inherent in the process itself, such as through the Increment or the Sprint Backlog, rather than through external reports. This approach keeps the focus on delivery instead of administrative overhead.

Assign a lead developer to monitor everyone's progress.

Why it fails: Assigning a lead to monitor progress undermines self-management and team cohesion. Scrum teams are cross-functional and self-managing, meaning they should collectively take responsibility for their progress. This hierarchical structure creates dependency and reduces the psychological safety required for the team to be honest about their challenges and blockers.

Change the team members to improve performance.

Why it fails: Changing team members is a drastic measure that rarely addresses systemic process issues. It disrupts team dynamics and ignores the potential that current problems are caused by external factors or organizational impediments. The Scrum Master should focus on improving the team environment and process before considering personnel changes.

Report the failure to the team's functional manager.

Why it fails: Reporting to a functional manager is an escalation that undermines the team's self-management and psychological safety. It suggests the team cannot solve their own problems. The Scrum Master's role is to support the team internally, not to act as a whistleblower or disciplinary agent for the functional leadership.

Reduce the team's velocity for the next Sprint.

Why it fails: Arbitrarily reducing velocity ignores the underlying issues that are causing the failure. While it might lead to 'meeting' the Sprint Goal, it doesn't solve the root cause. The team needs to analyze their process constraints, not just adjust their capacity expectations to fit an broken system.