Skip to main content
Back
X
Back

Scrum Forum

Question (dependencies)

Last post 11:45 am April 29, 2014
by Ian Mitchell
6 replies
Author
Messages
12:24 pm April 25, 2014

Software dependencies can influence how the product owner orders product backlog items

A. True
B. False

04:12 pm April 27, 2014

@Sunish Chabba: A (True)

I give a fictive simplified example to explain why :
lets assume that we have only following 4 PBI's in our Product Backlog with given business values:
PBI-1 (Business Value 10)
PBI-2 (Business Value 5)
PBI-3 (Business Value 5)
PBI-4 (Business Value 5)
On purpose I gave for items 2,3,4 the same Business Value.

That PBI-1, with highest business value must be placed on the top is clear.

Now lets say PBI-3 has software dependency with PBI-1 , for example both cause changes in the same component or changes in the same interface.

placing PBI-3 closer to PBI-1 would be better choice because, we will save efforts by integration test between components, or testing interface etc.
In this case the better ranking would be if we pull the item-3 before tiem2 and item4 and implement it with item-1 together in the same sprint:

PBI-1
PBI-3
PBI-2
PBI-4

Mehdi

08:24 am April 28, 2014

> placing PBI-3 closer to PBI-1 would be better choice because, we will save efforts
> by integration test between components, or testing interface etc.

That's true, but the greatest benefit is the ability to release a cohesive increment (such as a group of components behind an interface) more quickly.

Bear in mind that this is just one of many things to consider in product backlog ordering.

08:41 pm April 28, 2014

Posted By Ian Mitchell on 28 Apr 2014 08:24 AM
> placing PBI-3 closer to PBI-1 would be better choice because, we will save efforts
> by integration test between components, or testing interface etc.

That's true, but the greatest benefit is the ability to release a cohesive increment (such as a group of components behind an interface) more quickly.

Bear in mind that this is just one of many things to consider in product backlog ordering.

I agree on this but the language of the question says "Software dependencies" and not "Product Backlog Item dependencies". Dependencies between the items would influence the priority decisions but are these same as "Software dependencies". Or may be I'm reading too much in the question and trying to see if there is any trick over there :)

07:55 am April 29, 2014

@Sunish Chabba:

...question says "Software dependencies" and not "Product Backlog Item dependencies". ...

be aware that PBI dependency is something different than Software dependencies. The PO with Dev. Team together must try to get rid of dependencies between PB items during refinement meetings. for example with splitting or merging PBI .In the popular acronym "INVEST" the "I" is focusing on this point:

http://guide.agilealliance.org/guide/invest.html

The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story. If the story fails to meet one of these criteria, the team may want to reword it, or even consider a rewrite (which often translates into physically tearing up the old story card and writing a new one).

A good user story should be:

"I" ndependent (of all others)
"N" egotiable (not a specific contract for features)
"V" aluable (or vertical)
"E" stimable (to a good approximation)
"S" mall (so as to fit within an iteration)
"T" estable (in principle, even if there isn't a test for it yet)

08:30 am April 29, 2014

I agree with Mehdi - in his above example there is one line which I have highlighted below

Now lets say PBI-3 has software dependency with PBI-1 , for example both cause changes in the same component or changes in the same interface.

I think it is important to note that the dependency above is only for software (common code?) and does not mean that there is a product dependency.

11:45 am April 29, 2014

Product Backlog dependencies must address software dependencies, or the ability to make an incremental release will be compromised. There are other factors to consider, such as risk. Organizational politics and horse-trading can also play a part. Even so, it's the ability to release cohesive and valuable increments that is of prime concern. The ordering of the Product Backlog should reflect this.