3.6 Why Scrum Has No Project Manager
Key Takeaways
- CSM Learning Objective 3.9 asks candidates to discuss why Scrum does not have a project manager — the answer is that the accountability was distributed, not deleted.
- Scope and priority decisions moved to the Product Owner; how and how-much decisions moved to the self-managing Developers; process effectiveness and impediment removal moved to the Scrum Master.
- Scrum manages products continuously rather than projects with a defined end, so a temporary, plan-driven coordinating role no longer fits the structure.
- A person may keep the job title 'project manager' in an organization; what cannot exist is a fourth accountability inside the Scrum Team that assigns work or owns the plan.
- The Scrum Master is not a renamed project manager: they have no authority over scope, budget, staffing, or task assignment.
Quick Answer: Scrum has no project manager because the work that role performed was distributed across the three accountabilities, not abolished. The Product Owner took value, scope ordering, and stakeholder direction. The Developers took estimation, planning, and task allocation through self-management. The Scrum Master took process effectiveness and impediment removal. Nothing was left over to justify a fourth accountability inside the team.
CSM Learning Objective 3.9 asks you to discuss why scrum does not have a project manager. The examinable answer is structural, not ideological — and candidates who answer "because Agile doesn't believe in managers" lose the mark.
Where the Responsibilities Actually Went
| Traditional Project Manager Responsibility | Where It Lives in Scrum | Why It Moved There |
|---|---|---|
| Defining and prioritizing scope | Product Owner | Value decisions need a single accountable person the organization respects, close to stakeholders |
| Committing to a delivery date and scope | Nobody — replaced by empiricism | In complex work, forecasts come from observed Increments, not up-front commitment |
| Estimating effort | Developers | The Scrum Guide: "The Developers who will be doing the work are responsible for the sizing" |
| Allocating tasks to individuals | Developers, through self-management | The team internally decides who does what, when, and how |
| Producing the plan for the work | Developers | The Sprint Backlog is "a plan by and for the Developers" |
| Status reporting to management | The artifacts themselves | Transparency replaces reporting; the Increment and backlogs are the status |
| Escalating and removing blockers | Scrum Master | Causing the removal of impediments is an explicit Scrum Master accountability |
| Managing process and team effectiveness | Scrum Master | The Scrum Master is accountable for the Scrum Team's effectiveness |
| Quality assurance sign-off | Definition of Done | Quality becomes a standard the Developers conform to, not a gate a manager approves |
Read down that middle column and the argument makes itself: every responsibility landed somewhere with a clear accountability. A project manager inside the Scrum Team would necessarily take one of them back — and each one, taken back, breaks something specific.
The Two Deeper Reasons
1. Scrum manages products, not projects. A project is temporary and ends; a product is ongoing. Scrum's structure reflects this — the Product Goal is "the long-term objective for the Scrum Team," and a new Sprint starts immediately after the previous one concludes. There is no closure phase, so there is no need for a role whose remit is to shepherd a temporary endeavour from initiation to closure.
2. Self-management is not compatible with external task assignment. The Scrum Guide defines self-managing as the team "internally deciding who does what, when, and how," and says of Sprint Planning Topic Three: "No one else tells them how to turn Product Backlog items into Increments of value." A project manager who assigns tasks does not merely add overhead — they remove the property that makes the Developers able to adapt daily toward the Sprint Goal.
The Trap: "The Scrum Master Is Just a Project Manager"
This is the most frequently tested confusion in the entire accountability topic.
| Dimension | Traditional Project Manager | Scrum Master |
|---|---|---|
| Authority over scope | Yes — manages scope against a baseline | None — scope belongs to the Product Owner |
| Authority over people | Often line-manages or assigns tasks | None — Developers self-manage |
| Authority over budget | Typically yes | None |
| Primary output | Plans, schedules, status reports | An effective team and an environment where Scrum works |
| Mode of influence | Positional authority | Leadership through teaching, coaching, facilitation, and influence |
| Accountable for | Delivering to plan | Establishing Scrum and the Scrum Team's effectiveness |
The Scrum Master is described as a "true leader who serves the Scrum Team and the larger organization." Leadership without positional authority is the defining constraint, and it is the opposite of the project manager's core instrument.
What This Does Not Mean
Be careful with absolutes — the exam punishes them in both directions.
- Scrum does not forbid the job title of project manager from existing in an organization. Many people with that title work productively alongside Scrum Teams on procurement, vendor contracts, portfolio funding, or regulatory milestones.
- Scrum does not claim projects never exist. The Scrum Guide itself notes that "each Sprint may be considered a short project."
- What Scrum defines is that there are exactly three accountabilities within the Scrum Team. A fourth one that owns the plan or assigns the work is not part of the framework.
Real-World CSM Scenario
An organization adopting Scrum asks its experienced project managers to become Scrum Masters, and one of them begins maintaining a task-assignment spreadsheet, running the Daily Scrum by calling on each Developer in turn, and reporting individual completion percentages to a steering group.
Every one of those three behaviours contradicts a specific Scrum rule: task assignment contradicts self-management, running the Daily Scrum as a round contradicts an event held by and for the Developers, and individual-level reporting contradicts team-level transparency through artifacts. The coaching move is not to tell the person they are "doing it wrong" but to redirect their real strengths — stakeholder navigation, dependency management, organizational escalation — toward removing the organizational impediments the team cannot reach, which is exactly what the Scrum Master accountability calls for.
Why does the Scrum framework define no project manager accountability?
A newly appointed Scrum Master maintains a spreadsheet assigning each Sprint Backlog task to a named Developer and updates it daily. Which Scrum property does this most directly violate?
In Scrum, who is responsible for sizing Product Backlog items?
Which statement about project managers and Scrum is accurate?