17 August 2016, by Helen Hosein
One of the most important aspects of Project Management is being able to answer the question, “How is the project going?” Is it on schedule? Is it on budget? A very popular tool for keeping track is a Burnup Chart.
Every burnup chart has the same basic anatomy:
- The x-axis denotes time. Usually it’s measured in sprints, but it can be weeks or even days depending on how much granularity you need for reporting (and how frequently you can measure your progress).
- The y-axis is a metric of progress. In this example, the metric is story points completed which is a common choice but can be somewhat subjective. Other possibilities include number of stories completed, or amount of budget used. You can choose any metric you like as long as it’s a good representation of progress.
- The scope line (shown in black, and labelled “Scope (points)” in this example). This represents everything that needs to get done. In this case, it’s the total story point estimate for the whole project. If you’re measuring story count, it’s the total number of stories. If you’re measuring budget, it’s the maximum budget for the project. In this example the scope line is nice and flat, but in some cases, scope can change over the course of a project, so the scope line will change accordingly. This is one reason why burnup charts might be preferable to burndown charts – it’s easier to represent changes in scope.
- The burn line (shown in blue, and labelled “Story points” in this example). This is a cumulative plot of work done, according to our chosen metric. In a project that’s running to schedule, we expect the burn line to meet the scope line around (or ideally just before) the end of the project. The gradient of the burn line indicates velocity, or how fast we’re burning through work. Velocity can help project a rough end date for your project and is another useful indicator of how things are going. If your velocity is much lower than expected, there’s a good chance your project will be late. Also, if your velocity changes unexpectedly, it may indicate that something has happened that is worth investigating. Your burn line should be relatively smooth if things are going well.
Here are two projects with similar scopes and schedules but different velocities. Adding a trendline to the burn line makes it clear which is likely to be delivered early, and which is in danger of being late.
Another way to visualise this is with a target line. Here’s a project that ran pretty much exactly on schedule.
It’s normal for the burn line to wobble above and below target (staying perfectly on target would be a bit spooky – and may be a sign that your team is gaming the system), so a small wobble usually isn’t cause for concern.
One way to be sure is to add multiple target lines – one for the worst case (shown in dashed red, labelled “Pessimistic”), one for the best case (shown in dashed green, labelled “Optimistic”) and one for the average case (shown in dashed grey, just labelled “Target”).
Now we can see that once the project gained momentum, it stayed within our expectations, so we know that the wobbles in progress were definitely ok.
This other project, however, has been below the red line for all 8 sprints so far. Work is being completed, but the burnup shows that it’s not happening at the rate we would expect in order for the project to be delivered on time.
It looks like things might be improving: the trendline shows that at our current velocity, we should just about finish before the worst case end date, but it’s a pretty narrow margin and it assumes nothing else will go wrong.
Because we can visualise the project’s progress so clearly, we have the opportunity to take action before it’s too late. This project’s PM was able to intervene and turn things around. In the end, it finished ahead of schedule!
It’s easy to see the point at which effective changes were made to the project because the gradient of the burn line (the velocity) changed sharply. Burnup charts are also a great way to check whether the changes you make as a PM are having the effect you want.
Another handy use for burnup charts is keeping track of Work in Progress (WiP). If you’re familiar with Lean or Kanban, you’ll know that too much Work in Progress slows your project down, so it’s useful to be able to visualise how much WiP you have. The way to do this on a burnup chart is to plot a second burn line for work that’s in development. Just as the usual burn line shows cumulative work completed (using your metric of choice), the “In dev” line shows cumulative work in development or further, using the same metric. The distance between the two lines is your Work in Progress at that moment in time.
In this example, we can see that we had a lot of WiP in Sprint 6 (20 points!) which might have been slowing us down a bit. In Sprint 7, we picked up fewer stories and pushed more of the in-progress stories through the pipeline, which helped get velocity back on track. Here’s that project’s burnup again with target lines added.
One final tale of caution – Burnup charts are an excellent tool for visualising progress, but they’re only as good as the metrics you choose and your interpretation of them. Here are two burnup charts of the same project, one plotting story count and one plotting story points.
What’s going on here? Is the project running early or running late? Should you be worried?
What these charts are telling us is that, in Sprints 6 and 7 in particular, we got through a lot of stories but not a lot of story points. A look at the backlog shows that we completed a lot of smaller stories then, which gave us some quick wins. Does that mean we’re now ahead of schedule? Or are the remaining, larger stories going to bite us in the end, meaning we’re actually behind schedule?
Looking at the work remaining after Sprint 8, there are 3 small stories, 7 medium stories and 9 large ones. Large stories carry a lot of risk, so the project is starting to look precarious. At this point, it’s critical to remove any blockers and progress those large stories. In this case, the story points chart is probably a truer picture of what’s going on because it captures the risk associated with the size of the stories, and that’s where the trouble with this particular project lies. If you report the story count chart to your stakeholders, they may get their hopes up that the project will be early, and will actually be disappointed if it’s late. They also may not understand the urgency of unblocking the large stories if it looks like everything’s fine.
How did it end? The large stories were unblocked after Sprint 8, and things got better. Here are what those charts looked like at the end of the project.
The story points chart shows an increase in velocity when the large stories were unblocked. Things stayed pretty much on target after that.
The story count chart shows how the team got as much done as they could while they were blocked, but then ate through that buffer as they finished off the large stories. It shows that the rate of story completion was not sustainable, because of all the large stories still to be done.
Make sure that you choose the right metrics for your project so that the shape of your burnup chart is a true representation of its status. Then, use your burnup chart as a tool to help you identify when investigation and action are needed. Finally, use your burnup chart to verify the results.