Skip to main content

Product Backlog - Dependences

Last post 12:21 am October 26, 2022 by Joseph Abayomi Ajayi
11 replies
10:38 pm August 1, 2016

Let's suppose that:

A Development Team is waiting for a specific software component that they need to integrate and use.
The backlog items with highest priorities depend this specific component to be implemented.

What does the Product Owner should do?

1) Re-order the Product Backlog to maximize utilization of the Development Team
2) Nothing. His primary concern is the flow of value reflected in the ordering of the Product Backlog. Timeline of the flow might be influenced by such dependencies but doesn't necessarily change the ordering.
3) Remove this dependents items from product backlog and create a new one for it.
4) Transfer this items to the integration team

I think the best option is number 2, because no matter what happens, the Product Backlog always must reflect the business value!

And you?

regards,

Carlos


03:50 pm August 2, 2016

Carlos,

How is the Product Owner determining business value in their backlog? Is allowing an impediment to prevent delivery of any work a "valuable" strategy?

On another note, it seems if the Development Team in question was fully cross-functional, they would not be dependent on another team. Most likely, the PBIs are designed incorrectly, since they reflect a component/specialization view, instead of an e-2-e view.

What effect do you think it would have if your team's Definition of Ready included a criterion stating that every story must be independent?


06:43 pm August 2, 2016

Timothy,

I got it what you told, but, I think we are talking about different stuff.

The team is cross-functional and the product backlog is based on features (end-to-end view, as you said).

BUT, let's suppose the PO have 4 items, ordered by business value:

Item A: Value: 500
Item C: Value: 400
Item D: Value: 300
Item B: Value: 200

However, the item C is dependent of external component, like a report generator (let's suppose that a business decision was made about buy rather than make the component). This component will be delivered just 3 months from now.

My question is: Should the Product Owner re-order the product backlog? Like this...
Item A: Value: 500
Item D: Value: 300
Item B: Value: 200
Item C: Value: 400

See, the business values keep the same! But the order was changed.

OR, should the PO keep the original product backlog's order?

regards,

Calors


07:54 pm August 2, 2016

The ordering of the Product Backlog is a key mechanism for reducing and eliminating dependencies.

Does this change your answer?


09:41 pm August 2, 2016

I got it.

Let's re-order the backlog! Thanks Ian and Timothy!


08:12 pm June 21, 2019

Was the above answer to re order the backlog to maximize  utilization correct? 


08:30 am June 23, 2019

Do you think it is? If yes, why? If not, why?


10:59 am December 8, 2019

Sometimes an impediment appears that cant be solved by the development team, like when an external supplier will be late for delivery. I think in this situation the re-ordering of the backlog is necessary to maximize the flow of value

The Answer (1): Re-order the Product Backlog to maximize utilization of the Development Team sound good to me up to the part that this should happen because of the utilization of the Development Team.

So the Answer (2): Nothing. His primary concern is the flow of value reflected in the ordering of the Product Backlog. Timeline of the flow might be influenced by such dependencies but doesn't necessarily change the ordering. Sound also good for me apart from the part that the backlog ordering is necessarily changed.

If i hadto choose i would go with answer 2, because it implies that an impediment can but doest doesn't necessarily have to change the ordering.

What are your thoughts about it?

 

 


02:05 pm June 7, 2020

The dependency could be external. E.g. the dev team wants to integrate its product to say, a 3rd party system and the integration is yet to be developed by the 3rd party. Obviously, the dev team won't work on creating the integration by themselves (think proprietary issues). In such cases, the PO would re-write, re-order the PB so the independent items can be worked upon while the 3rd party develops the integration. However, the PO would cite this dependency in the PB (maybe by creating an PB item just before the integration PB item).

The first option doesn't seem right to me as the goal is to optimize the value of the product and not the output of the dev team.


11:24 pm July 15, 2020

My view is that given that value maximization is key for the PO so keeping the Scrum value of Focus in context,  "2) Nothing. His primary concern is the flow of value reflected in the ordering of the Product Backlog. Timeline of the flow might be influenced by such dependencies but doesn't necessarily change the ordering." seems to be the right approach. The Dev team being cross-functional should resolve this impediment with the Scrum Master's support (if needed). 

Thoughts?


11:47 am October 21, 2022

Does dependency affect how PO reorders? Y or N 


12:21 am October 26, 2022

Does dependency affect how PO reorders? My view is a Yes.

The reordering of the Product Backlog can be influenced by dependencies. Scrum Guide says PO primary focus is maximizing value, however in my opinion, the PO should also consider re-ordering the Product Backlog to maximize the value delivered during each Sprint as work progresses and insights emerges.

The emerging insights cum impediments can lead to the PBI reordering irrespective of the value while every change to the ordering of the Product Backlog might automatically change how that value is perceived.


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.