Select Two (Multi-Select) Questions

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.

Cancel the Retrospective entirely when the team has no major complaints to maximize their time for software development.

Why it fails: Cancelling the Retrospective removes the team's only formal inspection-and-adaptation event, entrenching the complacency the Scrum Master should address. It tempts when teams report nothing new, yet the Scrum Guide mandates the event regardless of complaints, so skipping it violates Scrum.

Provide a pre-approved list of process changes that the team must implement during the upcoming Sprint.

Why it fails: Imposing pre-approved changes removes the team's ownership of the Retrospective, so the superficial feedback and avoidance of systemic issues persist because the Scrum Master has substituted direction for self-management. A pre-approved list suits a newly formed team needing guardrails, not a mature one diagnosing its own impediments.

Report the team's lack of engagement directly to the company executives to request mandatory attendance policies.

Why it fails: Escalating to executives imposes external mandates, contradicting Scrum's self-managing team principle and damaging the safety Retrospectives require. It tempts when engagement looks poor, but the Scrum Master should coach the team to own the event rather than escalate for attendance policies.

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.

The team relies on the Scrum Master to assign daily work.

Why it fails: This is the definition of a managed team, not a self-managing one. Relying on a Scrum Master for task assignment destroys the team's autonomy and creates a bottleneck, preventing them from developing the skills needed for true self-organization and shared accountability for their performance.

The team waits for the Product Owner to prioritize their daily tasks.

Why it fails: The Product Owner prioritizes the backlog, but the team organizes their own daily work based on the Sprint Backlog. Waiting for daily task prioritization from the Product Owner creates a bottleneck and misinterprets the role of the Product Owner as a task manager.

Prioritizing the Product Backlog to maximize value.

Why it fails: Prioritizing the Product Backlog is the Product Owner's accountability. If Developers prioritized it, they might focus too much on easy technical tasks rather than high-value business features. This separation of duties is key to ensuring that the product development remains aligned with the needs of the business and the customer.

Managing the team's budget and external vendor relationships.

Why it fails: Budgeting and vendor management are organizational functions, not the responsibility of the Developers. These activities are far outside the scope of building an Increment. Forcing the Developers to manage these would distract them from their core work and require skills that are not part of the Scrum Team's mandate.

Approving all changes requested by external stakeholders.

Why it fails: Developers do not have the authority to approve changes to product scope. That decision is strictly for the Product Owner, who must balance the request against the product goals. Developers should focus on the technical feasibility and impact, not on deciding the business value or priority of new work.

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.

Address each conflict by disciplining the team members involved.

Why it fails: The Scrum Master is not a manager and should not discipline team members. This approach is detrimental to psychological safety and destroys trust. Instead of policing behavior, the Scrum Master should coach the team on how to communicate effectively so they can resolve their own interpersonal issues and move forward.

Separate the conflicting individuals into different teams immediately.

Why it fails: Moving people is a reactive, short-term fix that fails to address the underlying behavioral problems. It teaches the team that they don't need to resolve differences. This prevents growth and limits the team's ability to handle challenges, ultimately leading to a fragile organizational culture that avoids necessary, difficult conversations.

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.

It is a mandatory event for the Product Owner to track task completion.

Why it fails: The Daily Scrum is for the Developers. While others may attend, the Product Owner does not use it as a task-tracking tool. If the Product Owner forces the team to report status to them, the event loses its primary purpose as an internal synchronization session for the actual team.

It is a forum for the Scrum Master to assign tasks to the Developers.

Why it fails: Task assignment is never done by the Scrum Master. The Scrum Master's role is to ensure the event happens and that it stays within the timebox. If the Scrum Master starts assigning tasks, it creates a dependency on them and removes the team's ability to self-manage their work effectively.

It is used to update the stakeholder on the team's velocity and burndown charts.

Why it fails: The Daily Scrum is an internal event for the Scrum Team. It is not intended for external reporting to stakeholders. Velocity and burndown charts are meant for the team's internal inspection. Sharing this data with stakeholders during the daily event distracts from the immediate, actionable planning the team needs.

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.

Assign specific tasks to individual team members to ensure accountability.

Why it fails: Individual task assignment creates silos and prevents collective ownership. In Scrum, the team as a whole is responsible for the Sprint Backlog. Assigning tasks limits the team's ability to self-organize and adapt based on their changing needs during the Sprint, effectively reverting them to a traditional project management structure.

Require the team to clear all decisions with the Scrum Master first.

Why it fails: This behavior turns the Scrum Master into a bottleneck and prevents the team from learning through their own choices. It creates a culture of dependency that is the opposite of self-management. The team should be encouraged to make their own decisions and learn from the consequences, whether positive or negative.

Create a rigid process that the team must follow for every Sprint.

Why it fails: A rigid, forced process prevents the team from adapting their work to their specific context. Scrum is empirical; teams must inspect and adapt their processes over time. A rigid process shuts down the team's ability to experiment with new techniques or improve their efficiency based on their unique current challenges.

Report the team's lack of trust to the department head to initiate performance management.

Why it fails: Escalating internal team dynamics to management outside the team violates the principle of team autonomy. This creates fear and destroys psychological safety. The Scrum Master should handle team issues internally through coaching and facilitation, ensuring the team feels safe to address their own problems without fear of external repercussions.

Conduct private interviews with each member and present the findings to the team.

Why it fails: Presenting private feedback publicly often causes defensiveness and undermines trust. While individual coaching is useful, the Scrum Master should encourage the team to communicate directly with each other. Facilitating direct, transparent communication is key to building a high-performing team that can resolve its own issues without intermediaries.

Facilitate the Retrospective by acting as the sole arbiter of which team member is right in a disagreement.

Why it fails: The Scrum Master is not a judge or decision-maker for the team. Taking on this role makes the team dependent on the Scrum Master and stifles their self-management. Instead, the Scrum Master should facilitate the discussion so the team can reach their own consensus on how to improve.

Take full ownership of maintaining, ordering, and refining the Product Backlog so the Product Owner can focus solely on external marketing.

Why it fails: Taking ownership of the Product Backlog strips the Product Owner of their core accountability and compromises product vision coherence. The Scrum Master must coach the Product Owner to embrace this responsibility rather than assuming it themselves.

Cancel all future refinement sessions and rely entirely on spontaneous discussions that occur ad-hoc during the execution of Sprints.

Why it fails: Abandoning refinement removes the Product Owner's main forum for ordering and clarifying backlog items, so value delivery suffers. It is tempting because ad-hoc discussions feel agile and low-ceremony, and that approach would be correct only for a mature team whose backlog is already refined and stable.

Report the Product Owner's lack of engagement to their functional line manager to request disciplinary action or a role replacement.

Why it fails: Escalating to line management violates the self-managing nature of Scrum and destroys trust between the Scrum Master and Product Owner. The Scrum Master's role is to coach and support through facilitation and training, not managerial policing.

Direct the team on exactly which process changes they must implement next.

Why it fails: The team must be self-managing and decide their own improvements. Telling them what to do undermines their autonomy and may not address their actual needs. Process changes are most effective when they are internally motivated by the team's desire to solve their own specific problems or performance bottlenecks.

Invite external stakeholders to witness the team's internal conflicts.

Why it fails: The Retrospective is a private event for the Scrum Team to foster a safe space for open, honest feedback. Inviting external stakeholders inhibits this safety and discourages transparency. The team needs the freedom to speak candidly about their processes without fear of judgment from those outside the team.

Assign the least performing team member to lead the next Retrospective.

Why it fails: Performance is a team matter, not an individual one, and targeting an individual is counter-productive to the team dynamic. The Scrum Master should facilitate, or teach the team to facilitate, in a way that is constructive. Punishing individuals through forced leadership will damage trust and hinder the team's progress.

Insist that the team focuses only on negative feedback to drive change.

Why it fails: Focusing only on negativity creates a toxic environment that discourages open communication. The Retrospective should also celebrate successes and identify what worked well so the team can repeat those positive behaviors. A balanced reflection is essential for fostering a healthy, constructive team culture that promotes long-term improvement.

Document the team's performance data to present at the next management review.

Why it fails: The Retrospective is a private event for the Scrum Team. Management should not be using data from it to evaluate performance. This would cause the team to hide their real issues, effectively destroying the Retrospective's purpose as a safe space for honest reflection and internal process improvement.

Managing the team's JIRA tickets to ensure perfect velocity.

Why it fails: Managing tool configurations is a task for the team or a tool administrator, not the Scrum Master. Focus on metrics like 'perfect velocity' often encourages gaming the system rather than improving product delivery. The Scrum Master should focus on removing systemic impediments rather than micromanaging administrative workflows.

Taking notes during every meeting to ensure reporting consistency.

Why it fails: Note-taking is a task that the team should manage if needed. The Scrum Master's time is better spent coaching and removing impediments. Constant reporting often signals that the organization still prizes status updates over actual progress, which is a symptom the Scrum Master should work to eliminate.

Directing the team on which technical practices to implement.

Why it fails: Technical practices should be chosen by the developers based on their expertise. Prescribing technical standards limits the team's ability to self-organize and take ownership of their craft. The Scrum Master should encourage the team to experiment with practices that improve quality, not mandate them from above.