Forums

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. If you have left the first and last name fields blank on your member profile, your email address will be displayed instead.

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.

Question (dependencies)
Last Post 29 Apr 2014 06:45 AM by Ian Mitchell. 6 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
Sunish Chabba
New Member
New Member
Posts:10
Sunish Chabba

--
25 Apr 2014 07:24 AM
    Software dependencies can influence how the product owner orders product backlog items

    A. True
    B. False
    Mehdi Hafezi
    New Member
    New Member
    Posts:46
    Mehdi Hafezi

    --
    27 Apr 2014 11:12 AM
    @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




    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1556
    Ian Mitchell

    --
    28 Apr 2014 03: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.
    Sunish Chabba
    New Member
    New Member
    Posts:10
    Sunish Chabba

    --
    28 Apr 2014 03:41 PM

    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 :)
    Mehdi Hafezi
    New Member
    New Member
    Posts:46
    Mehdi Hafezi

    --
    29 Apr 2014 02:55 AM
    @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/guid...nvest.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)







    Himadri Bhattacharya
    New Member
    New Member
    Posts:18
    Himadri Bhattacharya

    --
    29 Apr 2014 03:30 AM
    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.
    Ian Mitchell
    Veteran Member
    Veteran Member
    Posts:1556
    Ian Mitchell

    --
    29 Apr 2014 06:45 AM
    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.
    You are not authorized to post a reply.


    Feedback