Division of the Tradional Project Manager in SCRUM roles

Hi Thiago,

Most company starts to transform only considering to give the PO role to PM with no doubt. The reason for that PM is a business oriented like PO. If the Agile mindset is realized by the organization purely, they already knows about each role has different responsibilities from each other independently even PM had no such tasks.Therefore, PM should think about SM is the solely person knows the new way and  there is no push a task more. There is a pulling by dev team.

Regards,

Ali Pala

there is no push a task more. There is a pulling by dev team.

That isn't entirely accurate, Ali.   The Product Owner does indeed "push" items to the Development Team during Sprint Planning, by priority, and according to the PO's belief in what the Dev Team is capable of for that sprint.   The Dev Team then assesses the PO "offer", and determines whether all or a portion of that offer is achievable based on guidance metrics like capacity and velocity.   Sometimes, there is a negotiation between the PO and the Dev Team around the final accepted PBI's for the sprint.

Regarding Thiago's original question, "power" is a very interesting term to use.   In my opinion, the responsibility of a traditional PM is shared among the 3 Scrum roles, but the Development Team is ultimately in control of how the work is estimated, accepted, and completed.

The Product Owner does indeed "push" items to the Development Team during Sprint Planning, by priority, and according to the PO's belief in what the Dev Team is capable of for that sprint.   The Dev Team then assesses the PO "offer", and determines whether all or a portion of that offer is achievable based on guidance metrics like capacity and velocity.   Sometimes, there is a negotiation between the PO and the Dev Team around the final accepted PBI's for the sprint.

This is incorrect in several ways.

What you are describing as "push" is not "push". In a true push model, there is no discussion or offer. Push means that work (and often deadlines for completing that work) is forced upon the team doing the work. Scrum is a pull-in-batches model, where the batch is the Sprint Backlog that is agreed upon by both the Development Team and the Product Owner during Sprint Planning.

The Product Backlog is not ordered by priority. It is simply ordered. The word priority appears twice in the Scrum Guide - once to talk about changing the priority of a Backlog Item and once to talk about including "high priority process improvement" goals in the Sprint Goal. Although priority is one input, technical dependencies should also be considered as well as how much refinement has been done to the work.

I don't doubt that some organizations may run Sprint Planning in the way you describe, I would not recommend it. The Sprint Planning shouldn't be a negotiation, but a collaboration between the Product Owner and the Development Team.

I think it's safe to say that the product backlog is ordered by priority, meaning: what is most important to develop first. And yes several factors play a part in prioritizing.

The scrum guide actually uses the term negotiation in sprint planning, but it is indeed most important that it is a collaborating effort. The dev team should also feel responsible for the added value and the po shouldn't try to push unrealistic forecasts to the team. I also prefer the term pulling over pushing, fwiw.

I just don't agree with this analogy. 

The nature of the tradional project management and the scrum are very different. I have the job to teach people in my organization. 

One director heard that the PM responsability (great input Timothy) are divided by the SCRUM roles, and people asked me to put this information on the educational material, and to corroborate with this line of thought. 

I just don't think that's the right way to teach, so I wanted you guys opinion if it's ok or not

Why did/does a project manager role exist in the organisation? Perhaps it's helpful to perform something like "5 whys" on that.

Once that is understood, maybe it is helpful to establish whether there is anything in Scrum that delivers any of the same outcomes, and what (not necessarily who) is essential for that to happen.

If you don't believe something is true, you probably shouldn't teach it, but you could facilitate for others to investigate and come to their own conclusions