Friday, 11 June 2010

MoSCow and the Release Planning Burndown Chart


Just recently I have been the ScrumMaster on an interesting project to create a new tool for the agile and scrum development community.    More details of this will be published in the near future.  In the meantime I thought I would share a new take on the release burndown chart.

On this project we conducted a lot of release planning to determine the product owner’s priorities for the functionality.  When doing our release planning we came across a problem with the sheer size of our product backlog and projecting delivery dates.  The total story points was in excess of 700.  Our project sponsors asked numerous difficult and challenging questions about what we could deliver and when.  The simple response of it is the Product Owner’s responsibility to determine the priority and when we can ship just didn’t wash.  We needed a level of confidence about a ballpark timescale and the usability of the product.

To overcome this issue I proceeded to create a variation on the release burndown chart.  We had already invested a lot of time in establishing the MoSCoW priorities for the complete Product Backlog.  In doing so we had created a list of acceptable functionality that needed to be shipped as part of the first release of the tool.  These were our Must haves.  The revised burndown mapped the various MoSCoW totals onto the burndown.  This indicated to us in which sprint the product would be shippable with the level of functionality acceptable to the Product Owner.

We continued to use the burndown to track our progress to against the Must haves deliverable.  Reflecting increases and decreases in the total estimate, as estimates for the stories changed, new stories are added as the Product Owner’s vision changed.

The fundamental underpinning that made the information on the burndown valuable was to always address the Must haves above all other stories.  In our case this was simple as the top of the product backlog was populated with Must haves.

Here is an example of the burndown we used:


Post writing this blog I came across a similar approach detailed in Mike Cohn blog here.