Loading ...
Sorry, an error occurred while loading the content.
 

Re: [scrumdevelopment] Tracking critical path with Scrum

Expand Messages
  • Paul Momola
    I agree with Ilja, the trick is all in the backlog. For trade reasons, I have encountered situations where dependencies were either necessary or just too time
    Message 1 of 37 , Dec 11, 2007
      I agree with Ilja, the trick is all in the backlog.  For trade reasons, I have encountered situations where dependencies were either necessary or just too time consuming to avoid.  In cases such as that, we have relied on the priority of an item to aid in the definition of dependencies, along with a note attached saying that story x requires the completion of story y.  I still try to push my teams to define things as independently as possible,  but this is not always possible.

      Given that, our critical path has morphed into the highest priority backlog items above an imaginary line  (The items below the line are nice to have, the ones above are must have).  The overall goal is to deliver the highest business value to the customer, which should be accomplished by delivering the items in the backlog in order of priority.  To me critical path assumes you need to deliver something that exists down the road, which has many things that must be done first in order to accomplish that goal.    If the backlog is prioritized accordingly, it should be a good indicator of how you are doing.  Burndowns against the backlog can then provide "big picture" statuses.

      ----- Original Message ----
      From: Ilja Preuss <it@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Monday, December 10, 2007 2:03:28 PM
      Subject: Re: [scrumdevelopment] Tracking critical path with Scrum

      Allen Bierbaum wrote:

      > My second thought was that maybe backlog items should include dependency
      > information that relates them to other backlog items that must be
      > completed first. Then when breaking down a multi-month project the team
      > could identify the critical paths ahead of time in the backlog and use
      > rough estimates to layout (possibly Gantt chart style) the order/timing
      > of when backlog items need to be handled and thus what iterations thus
      > must be completed within to meet the goals.

      In my experience, the trick in fact is to formulate the backlog items so
      that they are independent of each other. I haven't yet seen a (software)
      project where that wasn't possible to a degree that the remaining
      "critical path" was totally obvious and trivial to handle.

      Cheers, Ilja




      Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
    • Paul Momola
      I agree with Ilja, the trick is all in the backlog. For trade reasons, I have encountered situations where dependencies were either necessary or just too time
      Message 37 of 37 , Dec 11, 2007
        I agree with Ilja, the trick is all in the backlog.  For trade reasons, I have encountered situations where dependencies were either necessary or just too time consuming to avoid.  In cases such as that, we have relied on the priority of an item to aid in the definition of dependencies, along with a note attached saying that story x requires the completion of story y.  I still try to push my teams to define things as independently as possible,  but this is not always possible.

        Given that, our critical path has morphed into the highest priority backlog items above an imaginary line  (The items below the line are nice to have, the ones above are must have).  The overall goal is to deliver the highest business value to the customer, which should be accomplished by delivering the items in the backlog in order of priority.  To me critical path assumes you need to deliver something that exists down the road, which has many things that must be done first in order to accomplish that goal.    If the backlog is prioritized accordingly, it should be a good indicator of how you are doing.  Burndowns against the backlog can then provide "big picture" statuses.

        ----- Original Message ----
        From: Ilja Preuss <it@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Monday, December 10, 2007 2:03:28 PM
        Subject: Re: [scrumdevelopment] Tracking critical path with Scrum

        Allen Bierbaum wrote:

        > My second thought was that maybe backlog items should include dependency
        > information that relates them to other backlog items that must be
        > completed first. Then when breaking down a multi-month project the team
        > could identify the critical paths ahead of time in the backlog and use
        > rough estimates to layout (possibly Gantt chart style) the order/timing
        > of when backlog items need to be handled and thus what iterations thus
        > must be completed within to meet the goals.

        In my experience, the trick in fact is to formulate the backlog items so
        that they are independent of each other. I haven't yet seen a (software)
        project where that wasn't possible to a degree that the remaining
        "critical path" was totally obvious and trivial to handle.

        Cheers, Ilja




        Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
      Your message has been successfully submitted and would be delivered to recipients shortly.