Scrum Master vs Project Manager: 7 Key Differences

When organisations move to Scrum, one of the first questions is: what happens to the Project Manager? The Scrum Master vs Project Manager comparison trips up a lot of people because both roles involve coordination, communication, and keeping work on track. But they operate on fundamentally different assumptions about how teams deliver value. Here are 7 concrete differences.

The 7 Differences

1. Accountability Without Authority

A traditional Project Manager typically holds formal authority — they can direct team members, approve decisions, and sign off on deliverables. The Scrum Master has no authority over the Scrum Team. None.

The Scrum Guide 2020 defines the Scrum Master as accountable for the Scrum Team's effectiveness, but that accountability is fulfilled through service, coaching, and facilitation — not through issuing instructions or making decisions on behalf of the team. If a Sprint is failing, the Scrum Master cannot order the Developers to work overtime or reassign tasks. That distinction is fundamental.

2. Servant Leadership vs Command-and-Control

Project management frameworks often place the PM at the top of a decision hierarchy. The Scrum Master operates from an entirely different model: servant leadership.

Servant leadership means the Scrum Master serves the Scrum Team, the Product Owner, and the broader organisation. In practice this looks like: removing obstacles the team encounters, facilitating events so they are productive and time-boxed, coaching the team on self-management, and helping the organisation understand Scrum. The Scrum Master leads by enabling others — not by directing them.

3. No Project Plan — Empirical Planning Sprint by Sprint

Project Managers typically own a project plan: a detailed roadmap with milestones, dependencies, and a delivery date. Scrum does not use a project plan. Instead, it relies on empiricism — transparency, inspection, and adaptation.

Planning in Scrum happens at multiple levels: the Product Backlog represents everything currently known about the product, the Sprint Backlog represents the plan for the current Sprint, and the Sprint Goal provides focus. That plan is re-examined and adapted at least every Sprint. The Scrum Master does not produce or maintain a project plan — that would undermine the empirical nature of Scrum.

4. No Resource Management

One of the core Project Manager responsibilities is resource management: allocating people to tasks, tracking utilisation, and ensuring the right skills are available at the right time. The Scrum Master does none of this.

The Scrum Guide 2020 is explicit that Developers within the Scrum Team are responsible for creating a plan for the Sprint — the Sprint Backlog — and for self-managing their own work. No one outside the Developers tells them how to turn Product Backlog items into Increments. The Scrum Master does not assign tasks, manage capacity spreadsheets, or tell anyone what to work on.

5. Different Definitions of Success

A Project Manager's success is traditionally measured by the iron triangle: on time, on budget, and within scope. A project is successful if it ships by the deadline without overspending.

The Scrum Master's success looks completely different. According to the Scrum Guide 2020, the Scrum Master is accountable for the Scrum Team's effectiveness. That means: Is the team improving? Are impediments being removed? Is Scrum being understood and applied well? Is the organisation getting value from empirical product development? A team that ships on time but never improves is not a success story for a Scrum Master.

6. Impediment Removal vs Escalation

Project Managers often manage risk through escalation paths — if something blocks progress, it gets escalated up the management chain for resolution. The Scrum Master takes a different approach: proactive impediment removal.

When Developers identify something blocking their work during the Daily Scrum or at any other point, the Scrum Master works to remove that impediment — whether that means having a direct conversation with another team, changing a process, or coaching someone. The focus is on keeping the team's flow intact rather than routing problems through hierarchy.

7. Inside the Team vs Outside the Team

Perhaps the most structural difference: the Scrum Master is a member of the Scrum Team. The Scrum Guide 2020 defines the Scrum Team as consisting of one Scrum Master, one Product Owner, and Developers. The Scrum Master is not a supervisor sitting above the team — they are part of it.

Project Managers are typically positioned externally — they manage the team rather than belong to it. This shapes everything about how decisions are made, how trust is built, and how accountability flows.

Can Both Roles Coexist?

If your organisation is moving to Scrum, both a Scrum Master and a Project Manager may exist during the transition — and that is fine. Many organisations run Scrum for product delivery while project managers handle external stakeholder reporting, budget tracking, or portfolio coordination.

What the Scrum Master cannot be is the Project Manager. Combining both roles in one person creates an immediate conflict: the PM role requires authority, task assignment, and plan ownership — all of which directly contradict how the Scrum Master role is defined in the Scrum Guide. If someone is acting as both, they are almost certainly not doing one of the jobs properly.

Understanding this distinction is not just theory — it is one of the most commonly tested areas on the PSM I exam.