What is a Scrum Master?

A Scrum Master is one of the accountabilities defined within Scrum, with a role focused on helping the Scrum Team and the organization understand and apply the framework effectively.

The Scrum Master should not be the team's boss, should not assign work like a traditional manager, and should definitely not become some kind of Daily Scrum police officer. The role is much more about helping the team use Scrum effectively, supporting self-management, helping remove impediments, and improving the overall effectiveness of the Scrum Team.

This distinction matters because I have seen the same situation happen repeatedly: a company adopts Scrum, removes the Project Manager from the structure, and a few weeks later starts asking the Scrum Master about budget, schedule, risks, dependencies, vendors, stakeholders, capacity, delivery forecasts, and executive reporting.

In other words, we removed the Project Manager but apparently forgot to remove all the problems that person used to manage.

What does a Scrum Master do?

When someone asks what does a Scrum Master do, the answer seems relatively straightforward until we start looking at what actually happens inside companies.

Within Scrum, the role is focused on helping the team become more effective. That includes supporting self-management, helping remove impediments, ensuring Scrum events are productive and purposeful, and working with the Product Owner, Developers, and the broader organization to improve how Scrum is understood and applied.

The problem begins when “removing impediments” becomes a universal category for every issue that nobody knows where else to put.

A vendor is late? Someone calls the Scrum Master. There is a dependency on another team? The Scrum Master starts chasing it. A stakeholder is applying pressure? The Scrum Master is expected to help resolve it. The Sprint is in trouble? Someone asks what the Scrum Master is going to do. An executive wants to know when the initiative will be finished? It would not be unusual for the Scrum Master to end up helping prepare the answer.

Little by little, “help the team use Scrum effectively” starts quietly turning into “take care of everything that is preventing delivery.”

And that begins to look suspiciously similar to another profession we have known for decades.

What are the responsibilities of a Scrum Master?

The responsibilities of a Scrum Master are primarily related to Scrum and the effectiveness of the Scrum Team. In practical terms, a large part of the role can be summarized through activities such as:

• Helping the team understand and apply Scrum.
• Supporting self-management and cross-functionality.
• Helping remove impediments that affect progress.
• Supporting the Product Owner and Developers in using the framework effectively.
• Helping ensure Scrum events are useful, productive, and purposeful.
• Working with the organization to improve Scrum adoption.
• Helping the Scrum Team continuously improve its effectiveness.

Now look at what does not naturally appear in that definition: managing the overall project budget, controlling contracts, managing vendors, consolidating corporate risks, maintaining a master schedule, being accountable for financial margin, or producing executive reporting for a board.

That does not mean those activities disappeared.

It simply means Scrum did not formally assign them to the Scrum Master.

And that small difference creates a surprising number of organizational problems.

Is a Scrum Master a Project Manager?

No. At least not according to Scrum.

This distinction needs to be clear because simply saying that a Scrum Master and a Project Manager are the same role would be technically incorrect. A Scrum Master focuses on Scrum and on helping the Scrum Team become more effective. A Project Manager, depending on the organization and delivery model, may have much broader responsibility for budget, schedule, risks, communication, vendors, scope, stakeholders, governance, dependencies, and the overall project outcome.

But this is where things become much more interesting: just because the roles are different on paper does not mean they remain different once they enter the real world.

I have seen Scrum Masters managing risks, preparing executive reports, negotiating dependencies between teams, coordinating vendors, following delivery schedules, tracking costs, answering stakeholder questions, and trying to predict when an initiative would be completed.

In other words, doing a fairly significant amount of work that, a few years earlier, would probably have belonged to a Project Manager.

Scrum Master vs Project Manager: what's the real difference?

The difference between a Scrum Master and a Project Manager becomes much clearer when we stop looking only at ceremonies and start looking at accountability for the outcome.

A Project Manager traditionally exists because somebody needs to look at the project as a complete system. There is a budget, a timeline, a scope, risks, people, vendors, dependencies, quality concerns, expectations, and multiple parts of the organization trying to push the initiative in different directions.

The Scrum Master, by contrast, is not defined by Scrum as the person responsible for managing that entire system. The focus is on helping the Scrum Team and the organization work effectively within the framework.

And that brings us to a question that, in my opinion, many Agile transformations never properly answered:

If we remove the Project Manager, who manages everything that did not disappear with them?

In some organizations, the answer may be a Program Manager. In others, a Delivery Manager, Engineering Manager, Product Manager, PMO, or some combination of those roles. I see nothing wrong with that.

The problem appears when the company assigns those responsibilities to nobody formally and quietly expects the Scrum Master to absorb them.

Scrum can remove the role, but it cannot remove management

This is probably the most provocative part of my view on the subject. For years, I have watched organizations debate whether Project Managers are still necessary in Agile environments as if removing a title from an org chart had some magical effect on the underlying problems of a business.

You can remove the Project Manager, but the project still costs money. Stakeholders still want to know when something will be delivered. Vendors still miss deadlines. Risks still materialize. Dependencies between teams still block work. And someone in Finance will still want to understand why 80% of the budget has been consumed while only 50% of the expected result has been delivered.

The role may disappear.

The need for management does not.

And then the Scrum Master starts becoming a Project Manager

This is where the provocation behind the original version of this article starts to make sense. I am not saying that a Scrum Master is a Project Manager. I am saying that some companies eliminate one function and then gradually move pieces of that function onto someone else.

First, the Scrum Master helps with an impediment. Then they start following an external dependency. Later, someone asks for a status update. Soon they are talking to stakeholders, maintaining a risk register, producing delivery forecasts, coordinating dependencies, and contributing to executive reporting.

Before long, the person who was supposed to help the team use Scrum is doing delivery coordination, risk management, schedule tracking, stakeholder management, and parts of project governance.

And they may be doing all of that without having received the appropriate training, the necessary authority, or formal recognition for the work.

At that point, saying “we are Agile, so we do not need Project Managers” starts looking less like organizational transformation and more like a quiet redistribution of work.

The problem is not asking more from a Scrum Master

I want to make one thing clear: I see nothing wrong with a Scrum Master developing project management, delivery, risk management, communication, or stakeholder management skills. In fact, many of those skills can make someone much more effective in a complex organization.

The problem is hiring someone for one role, explaining that their responsibilities will look one way, and then quietly expecting them to perform a completely different job.

If the company needs that person to manage schedules, budgets, risks, vendors, dependencies, and executive reporting, perhaps it is time to acknowledge that the role is no longer only Scrum Master.

It can be called Delivery Manager, Project Manager, Program Manager, or something else that fits the organizational model. The name is probably the least important part.

What matters is making it clear who has the responsibility, authority, and skills required to do the work.

Less authority, but the same expectations

There is another effect that I consider even more dangerous: holding someone accountable for an outcome when they do not have enough authority to influence it.

Imagine a Scrum Master being questioned about the delay of an initiative that depends on four external teams, two vendors, a budget controlled by another department, and priorities established by executives they cannot even access directly.

They can facilitate every Daily Scrum in the world. The problem will still be there.

When responsibility and authority do not move together, we create a role that is expected to negotiate almost everything while being allowed to decide almost nothing.

Then we call that accountability.

It is not.

It is simply a transfer of pressure.

Who manages cost, risk, schedule, and stakeholders?

To me, this is a much more important question than endlessly debating whether a Scrum Master replaces a Project Manager. I care much less about the title than about knowing who is watching the money, who is monitoring risks, who understands cross-team dependencies, who can recognize that a series of small delays will probably affect delivery three months from now, and who is talking to stakeholders when expectations start drifting away from reality.

If the answer is “nobody, because the team is self-managing,” then we have a problem.

Self-management is extremely important for determining how a team organizes and performs its work. But it does not make contracts, financial constraints, organizational dependencies, commercial commitments, risks, or executive expectations disappear.

A burndown chart does not manage a company

One of my problems with certain Agile implementations is the tendency to reduce management to a small collection of Sprint metrics. Velocity can be useful. A burndown chart can be useful. The Sprint Goal matters. Retrospectives matter.

But none of those things, by themselves, answer questions such as: how much has this project already cost? Which area is consuming more budget? Which activities are generating more rework? Which risks are increasing? Are we delivering results proportional to the money consumed? Which dependency could compromise our schedule? Is team productivity improving or declining?

Executives still need those answers regardless of whether the team uses Scrum, Kanban, SAFe, Waterfall, or any combination of them.

A delivery framework does not replace management intelligence.

This is where Saint Jude comes in

This visibility gap is one of the reasons we created Saint Jude Project Intelligence .

When a company uses Jira, Azure DevOps, Asana, monday.com, or ClickUp, a huge amount of execution data is already being generated every day. The problem is that this information usually remains scattered across boards, dashboards, spreadsheets, presentations, and different interpretations from different managers.

Saint Jude uses that data to create a project intelligence layer that can help analyze schedules, costs, productivity, performance, risks, estimates, task quality, Sprint behavior, and other signals that help PMOs and leaders understand what is actually happening.

The idea is not to turn the Scrum Master back into a Project Manager. In fact, it is the opposite. The more management information can be structured automatically from data that already exists, the less time someone needs to spend manually collecting information just to build reports that may already be outdated the next day.

So what is the Scrum Master's role, really?

The Scrum Master role makes sense when we allow it to be what it was meant to be: helping the Scrum Team and the organization work more effectively with Scrum.

The problem begins when we decide that the Project Manager has become obsolete, remove the function, and assume that every management responsibility disappeared with the title.

They did not disappear. Someone will still deal with them. It may be a PMO, Delivery Manager, Program Manager, Engineering Manager, or some combination of people, processes, data, and automation.

Or, without anyone saying it explicitly, the organization may quietly place a large part of that work on the Scrum Master's shoulders.

And that is where my original provocation still holds: in many companies, the Scrum Master did not officially become a Project Manager. They simply inherited more and more management responsibilities while everyone continued pretending that project management was no longer necessary.

The problem was never the Scrum Master. The problem is believing that changing job titles somehow makes costs, risks, deadlines, dependencies, stakeholders, and communication problems disappear.

It does not.

And what about your company? Does the Scrum Master mainly perform the responsibilities defined by Scrum, or have they gradually absorbed work that once belonged to project management?

See you soon!

Erik Scaranello