The band of uncertainty – A burn up chart story.

The problem
With most agile projects, change is one of the few constants, its this paradox that makes traditional project management forecasting tools obsolete (if they ever actually worked in the first place). Gantt charts react poorly to change if it happens every day, chucking hissy fits and requiring far too much time to maintain. There is still a need however to be able to track project progress towards a goal, especially projects of many sprint lengths.
I have started using Burn up charts as part of my end of sprint reports which are sent out to all the interested parties on a project including team members and other stakeholders.

Setting up the chart
There are some tools that have come into vogue for measuring agile project progress, of which the burn up chart is one of these. I first came into contact with burn up charts a few years ago. We had a very basic chart introduced towards the end of a large project by the amazing Angela Ferguson of Thoughtworks. This stuck with me and I have over the years refined the chart to that which I describe later in this post.

The more simple burn up chart Angela used was essentially just two lines, the “total known scope” and the “completed scope” lines. 1 measured all stories needed to get to ‘Production candidate’ as decided by the Product Owner, the other was the stories signed off (over time). The illustration below shows this type of chart (Thanks to Nik Silver, saved me drawing one):














Illustration stolen from: http://niksilver.com/2008/01/19/burn-up-and-burn-down-charts/)

To gather the data needed for a burn up chart, we needed first to have a reasonably complete ‘backlog’ at least at minimum feature set (or Epic) level. This gives us our first cut of ‘total scope’. Don’t worry, we expect this to change over time, that’s the point.

We than try to break down the epics to the story level and use ‘total’ stories as our ‘target’ line, and completed stories as our progress line. We do this by ‘estimating’ average stories within epics. How you choose to estimate is up to the individual project, historical averages etc etc. If you need more accuracy, doing more upfront planning may be required, but this of course is a tradeoff, more planning = less doing for example.
Nik Silver describes his burn up chart thus:” A burn-up chart tracks how much work is done’. … ‘it also has a line showing how much work is in the project as whole (the scope as workload), and this can change..”

As the total known scope of a particular goal (project/initiative) can change over time. A simple burn up chart like this is a really effective way of;
- Showing how much work is in a project
- How far away we believe we are from nearing completion
- How much scope varies over the life of an agile project (a great learning for first time project Managers and Product owners)

A more advanced chart – with Banded estimates and end dates.

Problem
The simple chart didn’t adequately illustrate the grey zone of variations in epic size and how that would impact our ability to forecast project completion. So, I started to look at how we could illustrate the gap between least knowledge (all features are only at Epic level) and greatest knowledge (all features are broken down to story level).
I created what I’ve called a banded estimate chart. It tracks progress, trend and three variations of total scope. I provide this key under the chart on my reports:

The chart tracks stories in the current backlog (not the points in those stories). It includes an ongoing burn up line towards our known total scope for Beta launch. The known scope lines at the top are broken down into 3 categories:

- Known worst case scenario – This line assumes all remaining epics are at the project high scale of 10 stories per epic.

- Known + Epics – this line assumes all remaining epics are at the project average of 5 stories per epic.

- Known scope – This line is the total number of stories already broken down from epics







So, using the 3 sets of measures, we can do some estimating on project completion date from a reasonably early point in the project. As you can see from the chart above, the band is between ‘most certainty’ (stories) and least certainty ‘Epics – worst case scenario’ (with average epics in the middle) from this we can establish a band when the project may be completed by. In the example above we can project with a high degree of certainty that the project will finish somewhere between Sprint 7 and Sprint 13. The diagram below shows how this ‘band’ can be reduced.

Visualising this band of ‘unplanned’ epics helps us understand what we are compromising on. By not doing lots of ‘upfront’ planning to reduce our featuresets/epics down to easily understood ‘stories’ increases the ‘width’ in the end date predictions. (In the example above it is 6 sprints).





As the project nears completion so the number of Epics/Featuresets remaining unplanned should also reduce. This should bring the ‘band’ between the values closer together and thus reduce the ‘variance’ in project end date predictions. Essentially as you get further through the project your ability to predict the project end date gets tighter and tighter (much like the band!)

Comments

  1. I am pertified that when I re-read this it'll make little or no sense to me, so I aint gonna.

    ReplyDelete

Post a Comment

Popular posts from this blog

A survey on release processes with organisations that 'sef-identify' as folowing agile practises.

Using an agile storyboard as a scale of certainty

An idea for a release Retro