Ordering Product Backlog to minimize Dev Team dependencies

Hello, I am just studying the Scrum Guide, so might be off a bit in my understanding.
I believe the answer to your question is "Yes". It seems to be in line with the PO responsibility: "Optimizing the value of the work the Development Team performs", "The Scrum Guide, page 15". The value of the work done in the Sprint might suffer if a developer needs to work on multiple scrum teams during same Sprint.

I think you make a good point. However a Development Team should take care to only action work that has been negotiated into their Sprint Backlog. They should not be performing work that remains on the Product Backlog and which they have not yet agreed to do. By that reasoning, a PO would not be in a position to optimize the value of work being done by changing Product Backlog order.

I think it's reasonable to assert that the way Development Teams self-organize to deliver increments of value is entirely up to them, and is not something for Product Owners to decide.

However, PO's should take into account anything and everything that can affect the release of product value...including any *advice* given to them by Development Teams. This advice may well be shaped by constraints such as the team's ability to self-organize and deliver value with the resources they currently have at their disposal. So in this more restricted context of the PO taking into account a team's advice, I believe you are on the right track with your observation.

Hi Ian,

Interesting question!

I think the PO should not prioritize the PB in order to optimize Dev team interdependencies. If he would, that implies that the PB should be rearranged when Dev team membership changes. And then these changes must be communicated to the stakeholders. I think the practical approach would be to keep the PB ordered as the PO sees fit, and at the sprint planning be not completely strict about selecting the PBI’s in sequence. At the sprint planning, the Dev team knows team dependencies and the PO knows the capacity of other Dev teams to pick up the skipped PBI’s.

So in short: the well ordering can be established during the multiple sprint plannings the PO has with the Dev teams.

Hi Christiaan,

sorry, but I have to disagree.

The core of agile practices (of which Scrum is one) is to maintain the adaptability to change throughout the whole development process of a product. The Development Team is an important factor for the development process and in my opinion the change of Development Team membership can equally affect the Product Backlog as any environmental change (laws, stakeholders etc.) can. It can't be an agile goal to keep the Product Backlog stable.

Though, I think you have a good point with the Sprint Planning Meetings.

Hi Ian, thank you for the points brought up. You are great to learn from.

My thinking was in line of "A well-ordered Product Backlog can minimize and often eliminate Development Team members working on multiple Scrum Teams during a Sprint", which you agreed with.

So, apparently, if by well-ordering a Product Backlog a possibility of a developer to be working on multiple Scrum teams can be illuminated, which in its turn will raise the developer performance (no need to multitask) which should lead to a better product value, the PO can consider such opportunities of decoupling even before the backlog makes it to the developers. Where it can be still done by the developers during a Sprint Planning it might be not the right time since the "coupled" developer will be already committed to more than one Scrum team. Does it make sense?

Hi Anke,

Thanks for your response. Lets agree to disagree!

The question is raised by Ian as a part of the Scrum at Scale sample test. Since it is a sample test, I assume that we can have an open discussion and also disagree.

I understand your point about agility. And still, agility and scrum are a means to an end, which is for me creating maximum value for the customer with the available resources. Yes the Product Backlog can be rearranged due to events like you mentioned. But these are external changes all relating to product value.

As a Product Owner, I would be very unwilling to rearrange the Product Backlog due to Dev team membership / capabilities. As a product owner I do not have the expertise to judge all the technical details of how to build the product and exactly what skill sets are involved or interdependent.

When I read the question again I can see 1 situation where this would be an issue: a skill is so rare that we need to plan around it.

That might be a viable short term solution, but what happens if this skill gets sick or decides to work for a less demanding employer? Are we going to abandon the project and the product?

> ...the PO can consider such opportunities of
> decoupling even before the backlog makes it to the developers. 

The PO can consider these opportunities before the associated backlog items make it into Sprint Planning, but only on the basis of advice provided by the Development Team.

In other words, the PO cannot order the Product Backlog in an attempt to control how Development Teams will organize themselves. It is however reasonable for teams to explain the likely impact that a certain backlog order may have on their ability to deliver future increments, and for the PO to reprioritize after considering this information along with other factors such as business value and estimated size. This collaboration may occur during backlog refinement and be improved further in Sprint Retrospectives.