Despite Scrum having taken center stag for over 20 years, the Scrum Master is one of the most misunderstood roles in modern software engineering. Let’s bring some order into the most common misconceptions and myths about the Scrum Master role.
Not misunderstood in the way that people think it is hard; on the contrary, it is. Not misunderstood in the sense that its value is doubted; it is, way too often. It is misunderstood in a more fundamental way: the role is regularly redefined by the organization it is placed in, bent into whatever shape happens to be most convenient at the time, and the people doing the bending rarely notice they are doing it.
That convenience almost always comes at the team’s expense.
The 2020 Scrum Guide is precise: the Scrum Master is accountable for the Scrum Team’s effectiveness. Lets repeat this; Not velocity. Not happiness. Not compliance. Effectiveness. Yet in practice, the role routinely gets reduced to a calendar manager, a status reporter, or a glorified project coordinator with a shiny certification on the wall. None of that is the Scrum Master’s job.
Here are five misconceptions that persist across organizations large and small, and why each one matters more than it might seem.
1. The Scrum Master is the team’s project manager
This is the most damaging misconception, and also the most common.
The thinking usually goes like this: someone needs to be accountable for what the team delivers, and keep the team deliverables in sync with other teams’ deliverables. The Scrum Master is the most visible role. Therefore, the Scrum Master is accountable for delivery. Hand them the roadmap and the stakeholder calls, and move on.
That logic is seductive, and it is also wrong. The Scrum Master does not own the Sprint.
The Scrum Master does not assign tasks, negotiate deadlines, or represent the team’s output to senior management.
That is the Product Owner’s domain; and even then, the accountability is for the value delivered, not the schedule maintained. The Product Owner can, and should, work with the Scrum Master and the team in order to understand the capacity of the Team, so the Team is given the preconditions needed for a potential success.
But the moment a Scrum Master starts telling engineers what to work on or accepting delivery commitments on the team’s behalf, the self-managing nature of the Scrum Team collapses. The team learns to wait for instruction rather than exercise judgment. After a few sprints the product deteriorates, and everyone blames agile.
The Scrum Master is a servant leader. The goal is to create the conditions under which a team can make its own best decisions, not to make those decisions for them.
2. The Scrum Master runs the Daily Scrum
The Daily Scrum is a Scrum ceremony. The Scrum Master is the expert in how to run Scrum. Who else would run it?
The Developers, that’s who; and that matters more than most organizations realize.
The 2020 Scrum Guide is unambiguous on this: the Daily Scrum is owned and conducted by the Developers. The Scrum Master may ensure it happens, may coach the team on how to make it useful, and may protect it from being hijacked into a status meeting for management, but the SM does not facilitate it as a default.
When the Scrum Master consistently leads the Daily Scrum, the team stops learning to self-organize. They show up, answer three questions in the direction of the SM, and leave. The event becomes a reporting ritual rather than a planning tool.
A mature Scrum Master recognizes that the best indicator of their own effectiveness is not how well they run the ceremonies; it is how well the team runs them without needing the SM in the room.
Self-organization is a skill, and like any skill, it atrophies without regular practice under real conditions.
3. Removing impediments means fixing everything
There is a version of the Scrum Master role that looks like this: the team hits a wall, the SM appears, and the wall disappears. Repeat indefinitely. The SM’s worth is measured by the number of walls removed.
This is a misreading of what removing impediments actually means in practice.
Some impediments the Scrum Master can and should address directly, such as organizational blockers, tooling failures, or external team dependencies that are stalling progress. But the Scrum Master is not a universal problem-solver. The role is not to remove every friction the team encounters, but to distinguish between impediments that genuinely block the team and challenges the team should solve themselves as part of growing their competence.
A team that never solves its own problems never grows. And a Scrum Master who solves everything becomes a single point of failure.
The harder part of this misconception is the organizational one. In many companies, persistent impediments are symptoms of structural dysfunction: poor inter-team coordination, unclear product ownership, insufficient investment in technical quality, or the cost of running several projects in parallell. The Scrum Master’s job is to surface these dysfunctions and drive change, not paper over them indefinitely with heroic individual effort.
That requires courage, not just facilitation skill for the Scrum Master himself, but for the organization as a whole, and few job descriptions for the role acknowledge that honestly.
4. A certified Scrum Master is a qualified Scrum Master
The Scrum certification industry is enormous, and growing. A two-day course and a multiple-choice exam will earn most participants a credential with “Certified” in the title.
That credential certifies one thing: the holder completed a course and passed a test. It says nothing about whether they can coach a struggling team through a difficult Sprint Review, help a Product Owner refine a bloated backlog, or navigate the politics of an organization that does not actually want to change.
The Scrum Guide can be read in under an hour. Understanding it well enough to apply it in a real team, under real pressure, with real people; that takes years.
None of this is an argument against certification. In some cultures, certification is more or less mandatory in order to bump to a higher pay-grade. But it is an argument against confusing the starting point for the destination. A newly certified Scrum Master has a vocabulary and a framework. What they build from there depends entirely on experience, reflection, and the willingness to be wrong.
Hiring managers who screen exclusively for certifications, and Scrum Masters who stop learning after receiving theirs, both make the same mistake: treating a certificate as evidence of mastery rather than as a statement of intent.
5. A great Scrum Master makes themselves indispensable
This one is subtle, and worth sitting with for a moment.
It is natural, and human, to want to be needed. An organization that could not function without you is an organization that values you. The instinct to become indispensable is not cynical; it is in some sense survival instinct dressed up in professional clothes.
But for a Scrum Master, indispensability is a failure mode, not a career achievement.
The goal of the Scrum Master is not to become the team’s permanent crutch; it is to build a team capable of outgrowing the need for the crutch.
A Scrum Master who is still just as necessary two years in as they were on day one has not improved the team. They have simply made themselves comfortable.
The Scrum Guide describes Scrum as a framework for developing, delivering, and sustaining complex products. A Scrum Master who genuinely serves that goal is constantly working toward a version of the team that needs less coaching, less facilitation, and less protection from organizational dysfunction, because the team has internalized those capabilities.
That is uncomfortable work. It means coaching people past the point where they still feel like they need to be coached, and it means solving organizational problems that make your own daily intervention unnecessary. It means, ultimately, building something that does not depend on you to survive.
That is the mark of a great Scrum Master; someone who made themselves progressively less necessary, and did it on purpose.
6. The Scrum Master is only needed during early team formation
Many organizations treat the Scrum Master role as temporary scaffolding: useful while the team is learning Scrum, redundant once the basics are established. This is a misunderstanding of what the Scrum Master actually does over the life of a team.
Team dynamics are not static. A team that has been together for two years still faces new organizational pressures, personnel changes, accumulating technical debt, and shifts in product direction. Coaching needs evolve — they do not disappear. If anything, a mature team has subtler problems that require deeper coaching than the early-stage “what is a Sprint Review?” conversation.
A Scrum Master who has been around long enough to understand the team’s history, its unspoken tensions, and its relationships with the wider organization is uniquely positioned to help the team keep improving.
Continuous improvement, which lies at the heart of Scrum, requires a continuous commitment to coaching. There is no graduation point after which the team no longer benefits from someone specifically accountable for their effectiveness. Replacing that presence with nothing — or with a rotating series of new Scrum Masters who must re-earn trust each time — solves nothing.
7. The Scrum Master is responsible for the team’s velocity
Velocity is a planning tool, not a performance metric. It measures how much work a team completes in a Sprint in order to help that team forecast future Sprints. It was never intended as a measure of how hard or how well a team is working.
When management asks the Scrum Master to “improve velocity,” several problems occur simultaneously. The Scrum Master is being held accountable for an output metric that belongs to the Developers. The Developers, sensing the pressure, begin gaming the metric: inflating story point estimates, breaking work into smaller chunks to show higher throughput, or avoiding complex problems that might slow the Sprint down.
The irony is that none of this actually improves the team. It improves the number. And the Scrum Master who accepts this framing is quietly allowing the organization to redefine their role as a productivity driver rather than a team coach.
A Scrum Master who genuinely improves the team will often see velocity become more reliable and eventually higher — but only as a byproduct of real improvement, not as a goal in itself. Chasing the metric directly produces the opposite: a team that looks faster on paper while growing slower and more fragile in practice.
8. One Scrum Master can easily handle multiple teams
The “one Scrum Master for several teams” model is common, particularly in organizations trying to reduce overhead costs while still claiming adherence to Scrum. It is also a reliable way to ensure that none of those teams receives meaningful coaching.
The Scrum Master’s value depends on presence, trust, and deep understanding of a team’s specific dynamics. These cannot be split cleanly across four calendars. A Scrum Master stretched across three or four teams will attend the ceremonies — just barely — but will rarely have the bandwidth to notice the subtle signs of dysfunction before they become crises: the retrospective that always ends without actionable outcomes, the impediment that keeps reappearing, the growing tension between two developers that nobody is naming.
In most cases, the “SM per several teams” model is cost optimization dressed up as an organizational design choice, and the teams bear the cost.
There are circumstances where a single experienced Scrum Master can effectively support two teams, particularly when both teams are mature and the SM’s role is more facilitative than corrective. But those are the exception, not the default. Organizations that treat this model as standard are not scaling agility — they are rationing it.
9. The Scrum Master and Product Owner roles can be combined
This combination surfaces regularly in small startups or in organizations trying to minimize role overhead. The logic is usually pragmatic: “We do not have the budget for both, and one person can handle both jobs.”
In practice, the two roles carry fundamentally different — and sometimes opposing — accountabilities. The Product Owner is accountable for maximizing the value of the product. That accountability creates a natural incentive toward pushing work into Sprints, accommodating stakeholder requests, and keeping delivery moving. The Scrum Master is accountable for the team’s effectiveness, which sometimes means slowing down to address process debt, protecting the team from scope creep, or pushing back on unrealistic commitments.
When the same person holds both accountabilities, one of them will consistently lose. In most cases, it is the Scrum Master accountability that gets sacrificed — because the Product Owner’s pressures are louder, more immediate, and more visible to senior leadership.
The team ends up without a genuine advocate for their process, and the quality of their working environment quietly degrades. Small organizations can sometimes make this work temporarily, but it requires exceptional self-awareness and should be recognized as a conscious compromise, not a sustainable design.
10. The Scrum Master’s job is to enforce Scrum strictly
Perhaps no misconception does more day-to-day damage than the idea that the Scrum Master is a Scrum enforcer: the person who calls out deviations from the framework, insists that ceremonies run for exactly the right duration, and escalates when the team does not follow the process.
The Scrum Guide is a framework, not a rulebook. Its purpose is to make complex adaptive work manageable, not to impose ritual compliance on teams. A Scrum Master who enforces rules generates compliance. What Scrum actually needs is commitment — and commitment comes from teams that understand why the framework exists, not from teams that follow it because someone is watching.
When a team wants to skip a retrospective because “we have nothing to say,” the right response is not to mandate attendance. It is to understand why retrospectives have stopped feeling valuable, and to address that through coaching, not enforcement.
This distinction matters especially in organizations that are resistant to Agile adoption. A Scrum Master who leads with enforcement will generate resistance and confirm every cynical suspicion about Agile being bureaucracy in disguise. A Scrum Master who leads with curiosity and coaching has a genuine chance of helping people understand why Scrum works when it works. For a broader look at how Scrum principles get misrepresented across organizations, see The 10 most common myths about Scrum.
Frequently Asked Questions
No. The Scrum Master is not a project manager. The role does not assign tasks, negotiate deadlines, or own the delivery schedule. The Scrum Master is a servant leader accountable for the team’s effectiveness, not its output. Delivery accountability belongs to the Product Owner and the Developers themselves.
The Developers run the Daily Scrum. The 2020 Scrum Guide is explicit on this point. The Scrum Master may ensure the event happens and coach the team on making it useful, but does not facilitate it by default. When the Scrum Master consistently leads the Daily Scrum, the team stops practicing self-organization.
Not all of them. The Scrum Master removes organizational blockers and systemic impediments, but is not a universal problem-solver. Challenges the team can solve themselves should remain with the team — solving everything for them creates dependency and prevents growth. The Scrum Master’s job is to distinguish between genuine blockers and growth opportunities.
A certification shows that someone completed a course and passed a test. It does not demonstrate the ability to coach a struggling team, navigate organizational resistance, or apply the Scrum framework under real pressure. Certification is a starting point, not evidence of mastery. The practical skills required take years of experience and reflection to develop.
No — indispensability is a failure mode for a Scrum Master, not an achievement. The goal is to build a team that progressively needs less coaching, less facilitation, and less protection from dysfunction, because the team has internalized those capabilities. A Scrum Master still just as necessary after two years has not improved the team; they have made themselves comfortable.
No. Coaching needs evolve throughout a team’s life — they do not disappear once the basics are established. Mature teams face changing organizational pressures, personnel changes, and technical challenges that require ongoing coaching. Continuous improvement, which lies at the heart of Scrum, requires a continuous commitment to someone accountable for the team’s effectiveness.
No. Velocity is a planning metric owned by the Developers, used to forecast Sprints — not a performance target. Holding the Scrum Master accountable for velocity causes teams to game the metric through story point inflation and task fragmentation, producing higher numbers without real improvement. Improved velocity should be a byproduct of genuine team growth, not a direct goal.
Rarely. A Scrum Master’s effectiveness depends on presence, trust, and deep knowledge of each team’s specific dynamics. These cannot be split across many teams without losing depth. A Scrum Master stretched across three or four teams attends ceremonies but lacks the bandwidth to detect dysfunction early. One SM for two mature teams can work as an exception; it should not be the organizational default.
It is not recommended. The two roles carry conflicting accountabilities: the Product Owner maximizes value by pushing work forward, while the Scrum Master protects team effectiveness by sometimes slowing down. When one person holds both roles, the Scrum Master accountability almost always loses to the louder, more immediate pressures of product delivery. The team ends up without a genuine advocate for their process health.
No. The Scrum Master is a coach, not a compliance officer. Strict enforcement generates compliance, but Scrum needs commitment — which comes from teams that understand why the framework exists. When a team struggles with a ceremony, the Scrum Master’s job is to understand why and address it through coaching and curiosity, not mandates. Leading with enforcement breeds resistance and reinforces the perception that Agile is just bureaucracy with a new name.
Most of these misconceptions share a common root: they redefine the Scrum Master’s role in ways that are easier for the surrounding organization to absorb. A project manager in an agile costume is still a project manager. A meeting organizer with a new title is still an administrative role. A problem-solver who never teaches the team to solve its own problems is building dependency, not capability.
The Scrum Master role is genuinely difficult precisely because it asks someone to lead without authority, to coach without directing, and to measure success in outcomes that are slow to materialize and easy to attribute elsewhere. That difficulty is not a design flaw — it is the point.
Choosing the wrong definition of the role, at the wrong time in the team’s growth, causes more harm than running without one.
Take a moment to reflect on your own organization. How is the Scrum Master role actually used in practice? Does that match what the team and the organization genuinely need right now?