Hard Difficulty Questions

Act as an active mediator during every Daily Scrum to immediately shut down arguments and assign tasks to individual contributors.

Why it fails: Stepping in as a permanent mediator creates unhealthy dependency and shifts the team away from true self-organization toward command-and-control management. The Scrum Master should coach the team to resolve their own interpersonal friction rather than taking over their communication channels.

Escalate the behavioral issues directly to the functional engineering managers to implement formal performance improvement plans.

Why it fails: Escalating to functional managers imposes external performance management, which removes ownership from the team and contradicts Scrum's self-management principle. This stance would suit persistent misconduct requiring HR or disciplinary process, not routine conflict the Scrum Master should coach the team to resolve.

Suspend the Daily Scrum event indefinitely until the developers complete mandatory corporate conflict resolution training sessions.

Why it fails: Suspending a foundational Scrum event removes the primary inspection and adaptation mechanism needed to address the impediment. The Scrum Master must maintain the integrity of Scrum events while helping the team adapt their communication norms within the framework.

Cancel the refinement session immediately and rewrite all oversized backlog items personally to save valuable time for the team.

Why it fails: Rewriting items personally undermines the Product Owner's accountability for backlog management and robs them of essential skill development. The Scrum Master must act as a coach rather than taking over the Product Owner's core responsibilities during refinement sessions.

Allow the Development Team to break down the items arbitrarily during Sprint Planning without the Product Owner's direct involvement or input.

Why it fails: Excluding the Product Owner from item breakdown risks losing vital business context and functional intent during refinement. Collaboration between the Product Owner and the team is essential to ensure that decomposed items still deliver the intended customer value.

Force the Product Owner to adopt a strict mandatory template for every user story before scheduling any future refinement events.

Why it fails: Imposing a rigid mandatory template removes the Product Owner's ownership of backlog content and does not split oversized items. Templates suit teams needing consistency, but refinement calls for coaching on slicing and acceptance criteria instead.

Allowing external quality auditors and invited stakeholders to attend and provide direct feedback to the Scrum Team.

Why it fails: Scrum explicitly welcomes invited stakeholders and others whose feedback helps inspect the Increment; external auditors attending is permitted, not a violation. It tempts because audit involvement feels intrusive, yet the Sprint Review is an open working session, not a closed ceremony.

Allocating a 4-hour maximum timebox for a standard one-month Sprint duration as defined in the configuration.

Why it fails: Scrum prescribes a four-hour timebox for a one-month Sprint Review, so this allocation complies rather than violates. It tempts because long meetings seem excessive, but the timebox is a defined Scrum rule, and shortening it would breach the framework.

Requiring the presence of both the Product Owner and the Developers alongside stakeholders during the review session.

Why it fails: Scrum mandates that the Product Owner and Developers attend the Sprint Review alongside stakeholders; their presence is required, not a violation. This option is tempting because stakeholder-only reviews are common in traditional gate meetings, but excluding the team contradicts Scrum's inspect-and-adapt purpose.

Enforce a rigid, standardized definition of Done dictated by the PMO across all teams without allowing localized team adaptations.

Why it fails: Enforcing a top-down definition of Done strips teams of their autonomy and violates Scrum principles regarding team self-management and local context adaptation. Quality standards must be agreed upon collaboratively rather than imposed unilaterally by external administrative bodies.

Take full personal accountability for auditing every completed product backlog item to guarantee absolute adherence to the definition of Done.

Why it fails: A ScrumMaster serves the organisation by coaching teams and stakeholders to own and improve the definition of Done, not by personally auditing every item, which removes accountability from the Developers. It tempts as quality assurance, yet that command-and-control auditing contradicts Scrum's self-managing teams.

Advocate for the elimination of all quality checks so teams can focus exclusively on maximizing velocity and delivering features faster.

Why it fails: Eliminating quality checks compromises the integrity of the product increment and directly violates the foundational Scrum principle of transparency through inspection and adaptation. High velocity means nothing if the delivered increments are broken or non-compliant.

Ordering the backlog items to suit the Developers' preferences.

Why it fails: The Product Owner is responsible for ordering the backlog based on value, not the Developers' preferences. While the Developers should be consulted for technical dependencies, the final order is a business decision. The Scrum Master should ensure the Product Owner is making these decisions based on value, not team convenience.

Managing the Product Backlog on behalf of the Product Owner at all times.

Why it fails: The Product Owner is accountable for the backlog. If the Scrum Master manages it, the Product Owner is not fulfilling their role. The Scrum Master should facilitate the environment and provide coaching, but the Product Owner must own the content and the ordering of the items to ensure they stay accountable.

Deciding which features are included in the Sprint based on team budget.

Why it fails: Budgeting is an organizational responsibility, not a team-level decision for the Scrum Master to make. Deciding features based on budget alone is a poor practice that ignores the Product Owner's role and the need to maximize value delivery. The Scrum Master should not be making these kinds of decisions.

Help management refine the formula used to calculate velocity so that team comparisons become mathematically fair and statistically accurate.

Why it fails: Velocity is a forecasting aid for one team, not a productivity metric; ranking teams on it drives point inflation and hides real impediments. Refining the formula cannot make cross-team comparison valid, since estimation baselines differ. The ScrumMaster should instead coach management to drop the ranking and use velocity only for the team's own sprint planning.

Instruct all development teams to artificially inflate their story point estimates so that every single team ties for the top ranking every month.

Why it fails: Instructing teams to inflate estimates corrupts the data and breaches Scrum values of openness and honesty, leaving the underlying misuse of velocity unaddressed. Inflating estimates is defensible only where teams genuinely re-estimate after learning, never as a coordinated tactic against management.

Publicly publish the salaries and individual performance reviews of the management team to create parity and force them to abandon their stack-ranking practice.

Why it fails: Publishing management salaries and reviews retaliates against leadership rather than addressing the metric misuse, damaging trust and your own credibility. Transparency of this kind belongs in governance or pay-equity initiatives, not in response to velocity being used as a performance ranking.

Instruct the teams to ignore the training because it violates Scrum principles.

Why it fails: Ignoring a mandatory organizational policy is not appropriate. The Scrum Master serves the organization and the teams, and should not encourage defiance. Instead, the Scrum Master should work with HR and leadership to find a way to satisfy the requirement without unnecessarily disrupting Sprints, such as scheduling training during a Sprint break or using flexible delivery.

Escalate the issue to the CEO and demand that the training be cancelled for all Scrum Teams.

Why it fails: Escalating to the CEO and demanding cancellation is confrontational and unlikely to succeed. The Scrum Master should first seek to understand HR's constraints and collaborate on a solution. Demanding cancellation ignores the legitimate need for compliance training and may damage relationships, making it harder to serve the organization effectively.

Accept the disruption and coach the teams to extend the Sprint by two days to compensate for lost time.

Why it fails: Extending the Sprint violates the Scrum rule that Sprints are timeboxed and should not be extended. The Scrum Master should protect the Sprint timebox and help the organization understand why. This action would undermine the team's ability to forecast and could set a precedent for further disruptions, rather than addressing the root cause.

Ensure all teams prioritize coverage above new features.

Why it fails: Mandating a focus on a single metric at the expense of product value misrepresents the Scrum approach. The Scrum Master should encourage teams to balance quality with delivery. Prioritizing coverage over all else might lead to testing trivial code while leaving critical business logic untested and vulnerable to failure.

Publish the coverage results to create healthy competition.

Why it fails: Creating competition between teams is rarely healthy in an agile environment. It fosters silos and discourages the teams from sharing knowledge or helping one another. The Scrum Master should promote a culture of collaboration where teams learn from each other to improve quality across the whole organization.

Ask the Developers to stop tracking coverage for HR.

Why it fails: Simply stopping the tracking doesn't solve the underlying pressure from leadership. The Scrum Master needs to engage in a conversation about the purpose of the metric. By addressing the root cause of the pressure, the Scrum Master helps the organization align on better ways to measure improvement.

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.

Assign a team lead to ensure that everyone follows the Scrum process.

Why it fails: Scrum does not have a 'team lead' role. Assigning one creates a hierarchical structure that discourages self-management and shared accountability. The team is responsible for following the process; the Scrum Master helps them understand how to do that, not by appointing a surrogate manager within the team structure itself.

Ensure that every team member has a clear and distinct role defined by management.

Why it fails: Management-defined roles are often rigid and prevent cross-functional collaboration. Scrum focuses on accountabilities, not job titles. The team should self-organize to cover the work, not be restricted by external role definitions that limit their ability to jump in where needed to meet the common Sprint Goal of the team.

Fixing all impediments personally so the team stays focused on their tasks.

Why it fails: Taking on all the work personally makes the team dependent and prevents them from learning how to navigate organizational obstacles. A Scrum Master’s role is to facilitate and coach, not to act as a permanent fixer. This behavior creates a single point of failure and does not scale as the organization grows or changes.

Escalating every single issue immediately to the CTO to ensure it is fixed.

Why it fails: Escalating everything to the CTO is an over-reaction that will quickly lose management's attention and trust. It demonstrates a lack of ability to resolve issues at the appropriate level. This action is not a service to the organization; it is a sign of poor judgment and an inability to manage organizational relationships and escalation paths.

Force the team to dedicate 50% of every Sprint exclusively to technical debt.

Why it fails: Scrum Masters do not dictate specific percentages of work to the team; the Developers are self-managing and decide how to achieve the Sprint Goal. Mandating arbitrary work splits undermines self-management and fails to address the underlying root cause of why the technical debt was accrued in the first place.

Ask the Product Owner to remove items from the Product Backlog to save time.

Why it fails: Removing items does not solve the issue of existing technical debt or the processes that created it. The focus should be on improving the team's engineering practices and ensuring the Definition of Done is strictly followed. Managing the backlog is the Product Owner's concern, not the primary fix.

Request that management hire additional developers to handle the technical debt.

Why it fails: Adding more resources often complicates communication and does not solve process-related technical debt. The team should look to optimize their own practices and collaboration first. The Scrum Master's role is to help the existing team become more effective, not to immediately seek external personnel solutions for internal issues.

Approve the email report format temporarily, provided the stakeholders reply with their written feedback within forty-eight hours.

Why it fails: Sprint Reviews exist to inspect the Increment and adapt the Product Backlog through direct stakeholder collaboration; a written report removes that empiricism and the Developers' accountability for a usable Increment. It tempts because asynchronous updates suit distributed stakeholders, but the Scrum Master should address attendance causes instead.

Escalate the stakeholder absence to senior management and mandate their attendance at all future Sprint Reviews through company policy.

Why it fails: Mandating attendance through policy replaces self-management and stakeholder engagement with command-and-control, which contradicts Scrum's empirical approach; the Scrum Master should coach the team to understand why attendance dropped. Escalation tempts as a quick fix when stakeholders genuinely lack authority or sponsorship, but that is a stakeholder-engagement problem, not a policy one.

Agree to cancel the Sprint Review and allocate those four hours directly to the Developers for additional refactoring and technical debt reduction.

Why it fails: Canceling the Sprint Review to gain coding time destroys the mandatory inspection loop required to validate product direction. Technical debt management belongs in Sprint Planning and daily execution, not as a direct trade-off against vital stakeholder alignment events.

The event is strictly a 15-minute timeboxed status report delivered by the Developers to the Scrum Master and Product Owner.

Why it fails: The Daily Scrum is not a status report for management or the Scrum Master. It is an internal synchronization planning meeting exclusively for the Developers to inspect progress toward the Sprint Goal and adapt their daily plan.

Management must attend to track individual task completion rates and update enterprise project management tools in real time.

Why it fails: Management and external stakeholders do not have a mandatory presence at the Daily Scrum. Inviting outside observers often inhibits transparent technical discussions and transforms the collaborative planning session into an uncomfortable status interrogation.

Developers are strictly required to answer the three legacy questions regarding yesterday, today, and impediments every single day.

Why it fails: The traditional three questions were removed from the Scrum Guide to emphasize outcome over rigid ritual. Developers are now encouraged to use any format that suits their specific needs for synchronization and daily adaptation.

Prohibit senior leadership from attending future Sprint Reviews to shield the team from uncomfortable questioning.

Why it fails: Excluding stakeholders breaks transparency and prevents the team from receiving crucial market and user feedback required for empirical adaptation. The Scrum Master must coach stakeholders rather than locking them out of vital collaborative feedback loops.

Cancel all future Sprint Reviews and replace them with private status presentations delivered by the Scrum Master directly to the executives.

Why it fails: Cancelling Sprint Reviews removes the inspect-and-adapt event that surfaces the team's work, and private executive briefings hide information from the Scrum Team, worsening the micromanagement problem. It is tempting as a way to shield the team from leadership pressure, but the Scrum Master should instead coach leadership on Review purpose and facilitate transparent collaboration.

Advise the developers to ignore stakeholder feedback entirely if they disagree with the tone or direction of the executive commentary.

Why it fails: Advising the team to ignore feedback dismisses the core empirical intent of gathering market intelligence from stakeholders. The team must learn to separate constructive product feedback from unhelpful delivery pressure without shutting out stakeholder perspectives.

Ensuring the Product Owner is available for every Daily Scrum.

Why it fails: The Daily Scrum is for the Developers. While the Product Owner may attend, they are not required to be present. The Scrum Master should not mandate their attendance, as it might turn the event into a status reporting session rather than a planning session for Developers.

Approving the Product Backlog items before the Sprint.

Why it fails: The Scrum Master does not have approval authority over backlog content. The Product Owner owns the backlog, and the Developers contribute to refinement. Giving the Scrum Master approval power creates an unnecessary gatekeeper role that violates the autonomy and direct accountability of the Product Owner.

Performing all product research for the Product Owner.

Why it fails: The Product Owner is responsible for the product and should lead research efforts, often involving the Developers. The Scrum Master should not take over these tasks. Doing so creates a dependency on the Scrum Master and prevents the Product Owner from fully owning their domain.

Writing the technical implementation details for the Product Owner.

Why it fails: The Developers are responsible for the technical implementation details, not the Product Owner or the Scrum Master. Forcing this responsibility elsewhere is a violation of the Scrum team's self-organization and leads to a lack of ownership by the people who are actually building the product and managing the technical debt.

Assigning specific story points to every backlog item.

Why it fails: Developers, not the Scrum Master, are responsible for estimating work. If the Scrum Master assigns points, they are removing the Developers' role in understanding the work. This destroys the team's commitment to the estimates and ignores the fact that estimation is a collaborative effort meant to increase common understanding.

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.

Enforce these policies strictly to maintain organizational compliance.

Why it fails: Enforcing counter-productive policies creates 'Zombie Scrum' where teams follow rituals without the underlying values. The Scrum Master's role is to challenge impediments to agility. Maintaining policies that prioritize control over delivery prevents the team from effectively using empirical process control to improve their product outcomes.

Ask the team to ignore the policies while continuing their work.

Why it fails: Ignoring corporate policy creates unnecessary risk and potential conflict for the development team. The Scrum Master must handle organizational impediments at the systemic level rather than encouraging developers to break rules. Sustainable change requires changing the policies themselves through leadership engagement, not through quiet defiance by the team.

Advise the PMO to attend the Sprint Review to gain transparency.

Why it fails: While the Sprint Review is an appropriate venue for stakeholders, the policy itself mandates a separate reporting structure that fragments the team's focus. Simply adding another meeting does not address the underlying, inefficient reporting requirements. The focus should be on eliminating the waste caused by redundant reporting structures.

Immediately send the escalation to upper management to clear the path.

Why it fails: Escalation should be a last resort. The Scrum Master should first attempt to facilitate collaboration between the teams to resolve the dependency. Bypassing direct communication undermines the professional relationship between teams and may create unnecessary friction or defensive behavior from the other team involved in the dependency issue.

Document the delay in the Sprint backlog and adjust the Sprint Goal accordingly.

Why it fails: Adjusting the goal without trying to solve the problem is premature. The Scrum Master must act as an advocate for the team to remove impediments. Simply documenting the failure ignores the active service required from a Scrum Master to help the team achieve their goals in the face of obstacles.

Tell the Product Owner that the current Sprint is now a failure and should be cancelled.

Why it fails: Canceling a Sprint is a drastic measure and should only be done if the Sprint Goal becomes obsolete. A single dependency is rarely a reason to scrap an entire Sprint. The Scrum Master's duty is to help the team overcome obstacles, not to prematurely call for a Sprint cancellation.