RE: [scrumdevelopment] Release burndown/burnup for a sequence of short projects
- 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. :-)
CSM | CSP | http://richardsbraindump.blogspot.com | http://twitter.com/rbanks54
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of davidpeterjoyce
Sent: Tuesday, 2 December 2008 11:50 PM
Subject: [scrumdevelopment] Release burndown/burnup for a sequence of short projects
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.