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

RE: [scrumdevelopment] Release burndown/burnup for a sequence of short projects

Expand Messages
  • 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 1 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.