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

Release burndown/burnup for a sequence of short projects

Expand Messages
  • davidpeterjoyce
    Hi, I have come across an interesting request for a release burndown/burnup (lets say predictability) for short projects, often that only take a couple of
    Message 1 of 2 , Dec 2, 2008
    • 0 Attachment
      Hi,

      I have come across an interesting request for a release burndown/burnup (lets say
      predictability) for short projects, often that only take a couple of sprints. From my experience
      it take a few sprints to settle down before release charts become meaningful, therefore is is
      really worth doing? Has anyone done this?

      Secondly these small projects form a larger programme of work. Most projects are unrelated
      but it has been suggested that each small backlog is combined into one and release charts
      are created from this, it is the same team working on these so I guess this kind of makes
      sense but can hide a lot of detail if project x went wrong.

      Has anyone had experience of these and/or any guidance.

      Thanks,
      David
    • Richard Banks
      Hi David, It sounds like you might be better suited to a kanban approach than a scrum approach. It sounds like you might be trying to fit what is essentially
      Message 2 of 2 , Dec 2, 2008
      • 0 Attachment
        Hi David,

        It sounds like you might be better suited to a kanban approach than a scrum approach. It sounds like you might be trying to fit what is essentially short term ad-hoc work into an approach better suited for medium/long term project work.

        Personally, I don't see a lot of value in a release burndown if you've only got a few iterations. A chart with a maximum of 2 or 3 data points isn't much good to anyone.

        If you're doing resource pooling across multiple small projects I suspect it will be unlikely that you'll have consistency of team size for the duration of a project which will make velocity calculations difficult. However, since you are doing the small projects as part of a larger program of work you might find your best approach is to bundle the small projects together, combine product backlogs, etc and see what the overall team velocity is. You should still be able to size consistently even if the projects are unrelated and thus get some sort of handle on when things might be finished (which I'm assuming is the goal in the first place).

        Try it for a few iterations and see how you go. If it isn't working - inspect and adapt. :-)


        Regards,
        Richard Banks
        CSM | CSP | http://richardsbraindump.blogspot.com | http://twitter.com/rbanks54

        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of davidpeterjoyce
        Sent: Tuesday, 2 December 2008 11:50 PM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Release burndown/burnup for a sequence of short projects

        Hi,

        I have come across an interesting request for a release burndown/burnup (lets say
        predictability) for short projects, often that only take a couple of sprints. From my experience
        it take a few sprints to settle down before release charts become meaningful, therefore is is
        really worth doing? Has anyone done this?

        Secondly these small projects form a larger programme of work. Most projects are unrelated
        but it has been suggested that each small backlog is combined into one and release charts
        are created from this, it is the same team working on these so I guess this kind of makes
        sense but can hide a lot of detail if project x went wrong.

        Has anyone had experience of these and/or any guidance.

        Thanks,
        David
      Your message has been successfully submitted and would be delivered to recipients shortly.