Skip to main content

Ordering Product Backlog to minimize Dev Team dependencies

Last post 08:15 am December 4, 2014 by Ian Mitchell
8 replies
11:20 am November 24, 2014

The Scrum at Scale sample test lists the following as a correct assertion:

"A well-ordered Product Backlog can minimize and often eliminate Development Team members working on multiple Scrum Teams during a Sprint"

While this is indeed true, the statement seems to imply that this decoupling of Development Teams ought to be a consideration when organizing Product Backlogs.

Is the way Development Teams self-organize (either individually or at scale) a reasonable thing for a Product Owner to take into account when ordering a Product Backlog?


01:41 pm November 26, 2014

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.


03:29 pm November 26, 2014

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.


12:27 am December 2, 2014

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.


09:38 am December 2, 2014

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.


04:06 pm December 3, 2014

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?


03:08 am December 4, 2014

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.


03:33 am December 4, 2014

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?


08:15 am December 4, 2014

> ...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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.