We currently have a team working on a solution for a customer with a very compressed timeframe. In the setup for the project there was a large number of product backlog items created and added to the team project (we use Team Foundation Server). You can see the rate at which effort was added to the backlog in the following graph:
However, one of the things that bit us from a reporting perspective was that a lot of the work items were added to the root iteration path. This means that in the initial release burn-down bars the scope simply wasn’t visible. As time progressed these PBIs were pulled into the release and as a result we got a “burn-up” chart:
To any customer this is going to look pretty shocking and instinctively we knew we were actually burning through the scope so some further analysis was required. What I did was produce the inverse of a standard burn-down graph by plotting work done and committed to by sprint:
That in its own right is an interesting graph because it means that either the sizing of the backlog is inconsistent or the team suddenly put the foot to the floor (or started working some long hours). Just to double check the graph is showing me what I expect, you can see that the first two sprints (completed) are pretty much all green (done), and the current sprint is pretty much all committed.
Finally – the remaining work for this particular release can be seen simply by extending this graph to include the root \Release 1 iteration path (the remaining story points after this sprint are highlighted):
Anyway – gotta go, my flight is boarding. I think the lessons learned from this are:
- To get a text-book graph you need to do some release planning and make sure work items are in the right bucket before the first sprint begins (accepting there is always changes in the requirements that impact the graph to a lesser extent).
- If you don’t get it right, its not the end of the world. The analysis cube gives you the information you need to figure out what is going on and provided you keep your sprint backlogs well managed it should be OK.