The Product Owner Role delegated to the team!
In the Scrum Guide it states:
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
Clearly expressing Product Backlog items;
Ordering the items in the Product Backlog to best achieve goals and missions;
Optimizing the value of the work the Development Team performs;
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
Ensuring the Development Team understands items in the Product Backlog to the level needed.
The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.
So this last line concerns me. A layman might interpret this to mean if the PO is disengaged, can't be bothered, or is just not very good as a PO, then they can have the team do the work of the PO, albeit remaining accountable.
Does this not then make the role of the PO moot? The team look to the PO for backlog, for direction and alignment on the delivery of value through the achievement of Sprint Goals through the implementation of backlog. The backlog can change to achieve the Sprint Goal, but the PO role is the role accountable for value delivered through the implementation of backlog to achieve a Sprint Goal.
The PO role is responsible for working with the customers and stakeholders to understand their needs, and then to articulate this in such a way that the team understands what needs to be delivered. This is then further refined in backlog refinement.
None of this precludes the team talking to the 'real' customer, but the PO role is there for a reason, and if we give the PO carte blanche to delegate any or all of this role to the team, and simply make the PO accountable, then this sort of defeats the objective of the role in my view. Sort of like a manager that is accountable, but diets the team to do all the work... Not that that ever happens :-)
I invite PSTs to provide their thoughts on this topic. Dave/Ken if you're reading this then please add your wisdom.
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