What's the role of a Project Manager in Scrum?

I have heard that it is not advisable for the PM to be a SCRUM Master which I can see as making sense as the PM oversees the project whereas the SCRUM Master is more concerned with managing the work packages.

To my mind it would seem that having a PM as SCRUM Master goes against managin by exception, one of the principles of PRINCE2.

The PM should be more concerned with:

  • establishing the scope of the project, ensuring the business case for the project remains valid

  • planning the number of iterations

  • maintaining the overall project plan including software release dates

  • acquiring external resources needed by the Scrum team e.g. users for User Acceptance Testing

  • managing risks and issues which are escalated by the Scrum team

  • communicating with the executive including reporting progress

Could any PM's (or SCRUM Masters) experienced in managing agile projects using SCRUM give their experience/opinion on whether the two roles could/should be combined?


3 Answers 3


In Scrum, the traditional role of the PM is really divided into the roles of the Product Owner and the Scrum Master, with some responsibility also falling to everyone on the Scrum team.

The Product Owner is responsible for defining the project scope, prioritizing work by maintaining the product backlog, deciding if the effort should continue into future iterations, and being involved in risk management and mitigation strategies as a representative of the user and customer. In other words, the Product Owner deals with things that happen outside the team, with regards to the user and customer, and provides a single focal point for this information.

The Scrum Master is more process and team oriented. This person manages the resources, often takes point on risk management and mitigation strategies, and deals with the process and ensuring that the people who need information but aren't on the Scrum team have access to it and visibility on the work being done and any successes and failures of the team.

Some work is delegated to the team as a whole. For example, there is no single individual providing organization and instructions - the team as a whole works with the product backlog and previous data to determine how much work to take on in a sprint. Also, risk management is another activity that falls to the whole team, with the Scrum Master facilitating the process.

Finally, some concepts don't map well to Scrum at all.

There isn't an up-front idea of the total number of iterations needed. The idea is to set a timebox on iterations (often 2-4 weeks) and have a potentially shippable deliverable that adds value. The project ends when the backlog is empty or the needs of the customer change such that funding another iteration would cost more than the value added by the work that can be done. Of course, it's not a blind idea - you know by watching the backlog and working with the Product Owner when the project is approaching a termination state.

In addition, potentially releasable software is produces no less frequently than at the completion of every sprint. The idea is that there is a value-adding product at the end of every iteration. This product has been designed, implemented, tested internally, and undergone acceptance testing. All documentation and guides associated with the product are also up-to-date. In other words, if the customer wants it, they can get it. However, they might not want to go through the effort of deploying a product at the end of every sprint, but it's an option. Because you are responsive to change, you should be able to denote an actually-shipped product in your sprint planning meeting.

It's not advisable to combine the role of Product Owner and Scrum Master because they are concerned with different things. The Product Owner is working from the perspective of the end user and the customer - deliver the most value in the least amount of time possible and demand a high quality product. The Scrum Master is team centric and provides a counter balance to ensure that the team isn't overworked, has the resources they need to do the best job, and that they are generally happy and productive people. I, personally, think that someone who is skilled enough can probably play both roles. However, it does take a skilled manager and leader to do so. There's a great deal of information about this in a Project Management Stack Exchange question about combining the roles of Scrum Master and Product Owner.


I totally agree with @Thomas Owens's answer but I'm adding my own experience.

In typical Scrum project there is no PM. The PM role is divided into all participants of the project - PO, Scrum Master and team. When you scale a Scrum project or when you try to apply Scrum in corporate environment the additional person like a PM can be handy.

Scaling agile is generally hard task and usually demands some plan driven additions to make the scaling successful. PM can be on the top of the whole project and coordinate it with help of teams' Scrum Masters and Product owner.

We even don't need to work on scaling - it is enough if you have to integrate your work with another team which doesn't use agile methodology. In such case a lot of additional coordination is needed. You usually cannot put the burden of coordinating non agile team on Scrum Master or Product Owner but you can use traditional PM coordinating both teams and cooperating with Scrum Master and Product Owner.

The whole separate story is corporate / enterprise environment and bureaucracy. If the company itself didn't move to agile mindset you will simply need PM and he will most probably be "adapter" between your agile world and company's bureaucracy.


My perspective on this as a developer is that a Project Manager can be a good thing to have in Scrum, if you're in the kind of organization that has Project Managers. The role of this person in Scrum is to help the rest of the business understand Scrum, and act as someone that the Scrum Master and Product Owner can go to if they are running into problems reconciling Scrum with the typical software development process in the organization. As such, she needs to have a deep understanding both of Scrum and of the organization's typical process so that she can act as a buffer between the two.

As the business as a whole more fully embraces Scrum, I think the role becomes less and less important because fewer of these problems come up, to the point where Project Managers should probably concentrate on moving into a Product Owner, Scrum Master, or Agile Coach role.

Not the answer you're looking for? Browse other questions tagged or ask your own question.