Wednesday 12 December 2012

Sprint Burn-up

I recently switched to using burn-up charts for the release plan on a project, it has the advantage of showing changes in scope as well as progress. It takes a short while to get used to seeing the graph 'up-side-down' and adds a little complexity but soon becomes as natural as the burn-down chart and everyone on the team + customer 'got it'.

Having seen the advantages I wondered if it was possible to use a burn-up for the individual sprints rather than burn-down. I found some blogs on the idea but they seemed to want to track 'work done' in the same way as the release burn-up and they concluded it didn't work.
As an aside, I mistakenly tracked 'work done' during sprints when first starting out with Scrum but quickly realised it wasn't very useful and often misleading as it doesn't show how much work is actually remaining at any day during the sprint. Estimates change constantly throughout the sprint (they are only estimates after all) and so it is far more valuable to know the current best-estimate for the remaining work at the start of each day (something that was estimated as 4 hours yesterday and was worked on all-day may still be 4 hours today if the estimate was bad or there were unforeseen problems!). This requires the team to keep the estimates and sprint backlog updated during the sprint (we update the estimates after the daily stand-up before drawing the burn chart).
I wanted to track the remaining work each day but also get the advantages of a burn-up chart's ability to show scope changes. The solution was to track the 'scope' and the 'scope - remaining work', which I call the "Progress", each day of the sprint. The initial 'scope' is the total hours estimated by the team during the sprint planning meeting (the point where a normal burn-down would start). A real example from the first sprint on one of our projects can be seen below (showing the normal over-commitment associated with the first sprint):


In this burn-up we can see that the team committed to just over 160 hours at the start of the sprint and by the end had dropped the scope to just under 120 hours, so over 40 hours of scope had been dropped from the sprint. Note also the convergence of the Scope and Progress lines by the last day of the sprint, this is the same as hitting 0 hours on the last day of a burn-down chart, if the lines don't converge then the team failed to adapt correctly during the sprint. Compare this to the equivalent burn-down chart (this is using the same data as the burn-up chart above):

.
Here it isn't obvious what happened, did the team make really good progress on day 7 and 8 or remove scope? I normally add annotations to the graphs to explain the events during the sprint but this doesn't offer the same at-a-glance obvious information that the burn-up shows.

One issue with the burn-up above is that the guideline (dotted grey line) gets less useful as the scope changes, to combat this I draw a new guideline (blue) whenever the scope changes, an example of this can be seen below on day 7 of a sprint and on day 10, where scope has been added as the team was ahead of the estimates:




Note that the Guide has change between day 7 and 10 to account for the new scope that was added, it is re-drawn whenever the scope changes.

We had a discussion within the team about what actually constitutes scope change during a sprint, and agreed these main points:

  • If a task in the sprint backlog takes longer than expected (or less time) this is not scope change, the original estimate was wrong and the "Progress" will reflect this by not tracking the Guide just like in a burn-down. 
  • If work is removed from the sprint backlog then this is a reduction in scope by the original estimate on the task. 
  • If new work is added to the sprint backlog then it is estimated by the team and constitutes an increase in scope. 
Some corner cases arose when adding and removing tasks from the sprint backlog and we agreed:
  • If a task is missed during sprint planning session but later found to be required to complete the story, it is estimated and added to the sprint backlog, we agreed this wasn't a scope change but was down to poor estimating (inability to identify all work required for the story during estimating).
  • If a task is removed from the sprint backlog because it turns out not to be needed (perhaps it was completed during other tasks without realising), we agreed this wasn't a scope change and was probably caused by poor estimating/work breakdown.

When written down in a post like this it probably sounds complicated and a lot of effort compared to a burndown but actually in practice it works well and doesn't take much effort, the team got used to it quickly and we have a good understanding of what constitutes scope changes and what doesn't without actually referring to any rules or formal process, it just becomes habit.

We reviewed the use of the burn-up chart for sprints during a number of sprint retrospective meetings and the team concluded that they found it more informative and gives clearer visibility both inside and outside the team (we draw it on a whiteboard in the team area) of what actually happens during the sprint, we agreed to continue to use the burn-up chart for sprints.

I have shared an Excel spreadsheet with an example of how to draw the burn-up charts for a sprint here: https://docs.google.com/open?id=0B4GRkkm75Sq6WHIyZ1NMV3VaYlE

P.S I had been meaning to write this post and Steven's post (http://itsadeliverything.com/correcting-overcommitment-during-a-sprint) gave me the final push to get it done, be sure to check out his blog.

Update 1 (15/12/2012):

Steven's comment to this post...
Nice idea. Like make changes to scope explicit. Given the Scope line is essentially a forecast you could project it out to the end of the sprint assuming the future scope is the same as the last known value. Your guideline would then always track to the end of this line making the diagram clearer - at least for me.
...suggests the great idea of extending the scope out as a prediction, I've created a modified version of the example spreadsheet with this change and an example graph can be seen below:


I swapped the "Baseline" and "Guide" line styles so that the Scope Prediction and Guide are both dashed lines as I think this is easier to understand.

You can download the updated spreadsheet here: https://docs.google.com/open?id=0B4GRkkm75Sq6X1NwNHJYRGM5TlE

Update 2 (17/12/2012):

I experimented a bit after Steven's comment and decided to add an Initial Scope line as well so that the final and original scope/guide could be seen together, like a shadow on the graph (note Baseline is now Initial Guide):


This graph is pretty busy, it make sense to me and I find it very informative but stakeholders may be overwhelmed by all the data, when reporting outside the team it may be better to delete some of the lines depending on the audience and the length of explanation you're prepared to do!

This version of the spreadsheet can be found here: https://docs.google.com/open?id=0B4GRkkm75Sq6SjhyVHl1bFpNdWc

3 comments:

  1. Nice idea. Like make changes to scope explicit. Given the Scope line is essentially a forecast you could project it out to the end of the sprint assuming the future scope is the same as the last known value. Your guideline would then always track to the end of this line making the diagram clearer - at least for me.

    ReplyDelete
    Replies
    1. Hi Steven, extending the scope line is a great idea, I've added an update to the post and an updated spreadsheet example to add the capability. I'll use this modified version for the next few sprints and get feedback during the retrospectives to see if the team prefer it (I think they will!) Chris

      Delete
    2. I've made another update to add the initial scope.

      Delete