Burn-up Charts and MuSCoW

Every one knows about burn-down charts in Agile software development: They are a great metric for tracking progess on a project. Less well known, or perhaps I should say less well understood, is another type of highly useful metric: the burn-up chart.

Burn up charts are great for overall project planning and quickly assessing the impact of additional or changing requirements.

Once the release backlog has been estimated into story points, and you have a velocity (or estimated velocity) of how many story points you can get through per iteration, the next step is to make sure the backlog is ordered on the MuSCoW principle: ie. Must-have, Should-have, Could-have, Will-Not have (Yes it is a bit convoluted).

• Must Have– if these features aren’t in, the product cannot be released
• Should Have– important but success does not rely on it
• Could Have – nice to have in, but can be left out if necessary
• Will-Not Have – not this time

You then can map these out with the y-axis representing the story points int eh backlog (i.e. scope) and the x-axis is the number of iterations (i.e. time/schedule).

Its then pretty easy to plan how many iterations should be needed to complete all the “Must-haves”, the “Should haves” and “could haves”. The sponsor can then decide how much of the non-vital functionality they are prepared to pay for (in terms of time). Similarly, if you add story points by adding or changing requirements, the graph line shifts up, and the point where it meets the x-axis moves out: The number of iterations required to complete the new functionality increases.

Example below: