The Product Owner Role delegated to the team!

Typo in original post  - but diets the team to do all the work should read - but directs the team to do all the work...

Given that the Product Owner remains accountable, what incentive would they have to delegate in an irresponsible way?

The PO role is not a part time role, and consumes significant time in the sprint.  The items defined in the Scrum guide details this.

If the PO delegates this in its entirety to the team, it takes away capacity from the team to actually do the work.  It also starts to dilute and negate the value of the PO role, and therefore makes them just an approver.

When talking to Jeff (who I work for) this was not his intent when creating the PO role.

I am facing POs who are 'too busy' to be a PO, and have their 'other day job' to do, so are telling the team and/or SM to write the stories and figure out the next sprint.  Then they as PO simply give their no of approval.

Is this really acceptable as defined in the Scrum Guide?

Nod of approval even...

If the PO is maximizing the value of the product, as is also described in the Scrum Guide, then they can delegate in the way they consider to be most appropriate.

Are they really maximizing stakeholder value though, if they are "too busy" and exhibit the behaviors you mention?

So from a PST perspective you feel it is fine for the team to write 100% of all PBIs, prioritize the backlog, optimize their own work, and decide on the goals and missions.

I would ask: if the PO did that, would they be maximizing the value of the product and be able to account for it to stakeholders?

The Scrum Guide also says:

Development Teams are structured and empowered by the organization to organize and manage their own work. 

This could theoretically mean the Dev Team could wait until the last day of the Sprint and do all the work that day. Of course, if it was obvious the way they were managing their work was detrimental or at least, not creating the highest possible value, then you would expect the Scrum Team inspects itself and adapts accordingly.

While it seems that in most cases, it would not be beneficial for the PO to delegate 100% of its Product Backlog Management duties to the Development Team, there may be the odd occasion where there is evidence that it is beneficial and the PO is able to maximize the value of the product because of it.

Imagine how your PO can work at large scale, with Nexus or LeSS.

Even with a very big product, you have only one PO, responsible to maximize the value of the product, with a global view.

Do you think such a PO, even working 100% on this single product, is maximizing the value of the product when using its time on writing PBI ? Do you think he can prioritize the thin PBIs of a full Nexus without help from the Dev Teams, or should he focus on priorities on the epic level ?

The PO will probably be more valuable in delegating some ground-work to the dev teams and keeping time to work with customers and other key stakeholders.

And if they say yes, and their stakeholders seem ok, then is it the best use of the teams time?  

Less time to deliver features.  If the PO is fully engaged and doing the PO role, then the team can be fully focussed on delivery of value, and not context switching having to create work before they can do work.  Making the team the PO role in my view is not the intent of the authors, and only serves to slow down delivery.

Less time to deliver features.

Yes probably, but the goal is to deliver the best features (Value), not the more features (Velocity).

@Oliver totally agree.  The same logic applies though that if they have more capacity, they can deliver more value in a sprint.  

Also velocity (as we measure it) is not a measure of features delivered, it is a measure of value delivered for the PO.  The only value is a completed PBI.  

You can then do some useful extrapolation and look at value per point delivered.  It all depends on how you view points (work estimates of size), and there are varying schools of thought I know :-)

@Oliver and I recognize under the Nexus framework there is a single PO for 3-9 teams, similarly in LeSS where there is a single PO for 2-8 teams, but the other view is each team should have a PO, as per the Scrum Guide in single team Scrum.  Many practitioners call for a CPO, but each team retains it's own PO.  Of course we could argue the merits of one way vs the other, and we'd all have valid learning points, but from a single team perspective, which is the Scrum Guide, I am of the viewpoint that a PO must be full time, fully engaged, and doing the role of a PO, and not delegating that role to the Team, who are focussed on delivery of the value prioritized by the PO.

 I am of the viewpoint that a PO must be full time, fully engaged, and doing the role of a PO, and not delegating that role to the Team, who are focussed on delivery of the value prioritized by the PO.

@Nigel, I don't think there is any disagreement with this view.  The point is, there may be occasions when the PO finds it most valuable for a Development Team to conduct some of the Product Backlog management.  

If the Scrum Team and product can benefit from it, what harm is there?

We all agree that PO is an essential position and is to take seriously as a full time job.

For me, without being PST, the issue is to lock at the bottleneck and how do we handle it in order to optimize the flow from a global view, not a local view from the PO or the Dev Team.

For instance, if the PBI are easy to describe and to prioritize but difficult to implement, and the Dev Team is made of 3 junior Des, the bottleneck will probably be on the Dev side. It could be nice if the PO makes his best to have crystal-clear PBI and clear UAT in order to help the Dev Team.

If the PBI are very complexe to describe and the business model is also very hard to optimize, but easy to implement by a Dev Team of 9 rock-star Devs, the bottleneck will probably be on the PO side. Here, it could nice to have the Dev Team helps the PO.

@Olivier A systems thinking approach is essential, and your comments support the continuous improvement view of Inspect and Adapt based on Empirical Observations.  

I think the only view we could all probably live with (agree maybe) is, that the PO and Dev Team will work closely together to determine the best way to manage the various 'backlog management' activities.

The Product owner is responsible for the "what", and to ensure the team is working on what is most critical to the customers/business.   If this responsibility is delegated in any way to the Development Team (whose main responsibility should be the "how"), then this benefit of Scrum is simply lost, and I would question the value of having someone not engaging consistently with the team and only coming in at the end of each sprint to give a thumbs up/down.

@Alex No disagreement from me on that at all.  My concern is the sentence in the guide leaves the door open to abuse, and as the guide is meant to be the MVP of rules, then I think it leaves it too vague.  It just makes coaching and training divisive as it leaves room for a PO to argue that he/she is falling the guide.  Ask me how I know!

*following not falling

Tech debt in the forum.  No way to edit posts...

Just came across this discussion, and even I´m quite fine with the statement in the Guide (as it separates Responsible and Accountable), I think there is something interesting in your question. And you already discussed the central points, so I can´t/won´t add something valuable to it.

However, whenever I had teams coming up with this kind of topics, there was quite always some smell in the values often not lived resulting in a lack of trust. So, isn´t that concern coming from a lack of trust? E.g. the trust a PO won´t be a lazy one just letting the Developers do all their work?

What i realized after working for some time on large projects where teams are sometimes improving back-end jobs features to enhance systems, is that the Dev team in general some cases has better knowledge than PO of these components, and all subtilities. They are part of the system but not client-facing, although they produce value for these clients.

Although it serves some business functionality, PO is often only aware of the outcome of these processes.

When it is time to define the acceptance criteria, some members of Dev team (developers and especially testers) might be better positioned to write and validate them.

For these "backend" stories for sure PO might not be of too much help. Stories criteria’s might respect the INVEST rules and really delivers value to customers, even if you don't have any interface to interact with, on client side.

Some examples that I thinks about:

• Improving speed to produce some system reports
• Enhance system to be failure-resistant 
• Leverage existing systems connect to new micro-services offering new security
• Etc..

I am a product manager, and I give direction every sprint into what the development team should be working on. But I do it at a very high level, I do not create the stories from the backlog, but when we have the backlog refinement sessions I am there answering questions. I have had teams before where I created every single item in the backlog. I think the key here is looking at the maturity of your team and deciding what makes sense and how the whole scrum team can work at it's best to deliver more value. Hope that makes sense. 

In my case, we share the writing of the items with a UX professional on the team and technical detailing of these items at some point is done by an experienced Dev from the team. All of this being reviewed by the PO. It has worked well and brought satisfaction to the whole team.

[1] The accountability of the PO mention in the guide is generic to all the domains, all type of project, all type of business.

[2] It is also depends on situation where the PO is working with number of development team(s)

[3] But as mentioned by "Hector Morales", as a product manager he is accountable and delivering more values, part of backlog grooming sessions and providing clarifications.

[4] Even though the PO is not creating user stories, but he need to review and the PO is accountable. The PO will present during the sprint review (demo by the development team(s) and do the review) and check against the sprint goal.

I am unsure about the topics below which can be considered to be delegated by the Product Owner to DT. Because it is very true that PO should value maximiser. 

Attending the sprint retrospective,  Attending the sprint review, Ordering product backlog items,  Developing and communicating the product goal

The Scrum Guide says that certain responsibilities for Product Backlog management can be delegated. Which of the things you describe are to do with managing the Product Backlog?