Softwire Blog

Visualising your project’s progress with Burnup Charts

17 August 2016, by

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.

Here’s a simple example:
A simple example of 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.
A burnup chart whose velocity indicates a likely early finishA burnup chart whose velocity indicates a likely late finish

Another way to visualise this is with a target line. Here’s a project that ran pretty much exactly on schedule.
A burnup chart of a project that progressed on target
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”).
A burnup chart of a project that progressed on target, indicating the expected best, worst, and average cases.
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.
A burnup chart showing a project that appears to be at risk
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!
A burnup chart of a project that was in trouble, but recovered after intervention, and ended up finishing early
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.
A burnup chart indicating Work in Progress
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.
A burnup showing a project that was kept on track by controlling Work in Progress

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.
A burnup of a project that seems to indicate it is going wellA burnup of the same project that seems to indicate it is going badly
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 final burnup of story points for the confusing 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 final burnup of story count for the confusing project
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.

Risk Log Zero: How to keep your risk log empty and your mind free of worry

17 April 2015, by

Today I’m going to share with you my Risk Log Zero strategy – an attempt to do for my risk log (and risk management) what Inbox Zero did for my inbox (and self-management)

What are risk logs really for?

Risk management can be defined as the stuff that PMs never quite find the time to do. You’re haring around doing the things that obviously need doing on your project, and it’s easy to ignore the nagging voice in the back of your head that says “what if this happens?” Risk logs are intended to make this voice harder to ignore. A good risk log will ask you every week “what are you worried about?”, and will remind you about the risk at the point when you can do something about it. I claim that your risk log does neither of these things.

A bad risk log

Let’s have a look at a risk log I wrote as a young and naive Project Manager, and pick holes in it:
An old risk log

Not a bad start – day 1 and I’ve identified 5 major risks on the project. However, the next Monday, I got a calendar pop-up telling me to update the risk log. So I looked at this table, and checked for the following:

  • Can I close any of the risks? No
  • Have any of these vague transition indicators definitely occurred (definitely enough that I can’t justify leaving it until next week)? No
  • Do I need to perform any of the mitigation actions? …No

This isn’t a very useful exercise. There are some major issues:

  • It’s easy not to take any actions, and just go back to the comfort of my more tangible (and very long) to-do list.
  • If I’m worrying about all these, then I’m not worrying about them enough (or alternatively, I’m living in a perpetual state of worry).
  • Most dangerously, because this exercise gives the illusion of risk management, and because I can see lots of pretty risks in my table, I don’t feel any imperative to think up any new, more relevant risks.

Risk Log Zero – the blank page

The principle behind Inbox Zero is that if your inbox is nearly empty, it means you’ve done something sensible with nearly all your emails, and you can now attend properly to the remaining ones. Applied to risk logs, my strategy has more emphasis on addressing risks immediately.

An empty risk log is a great reminder to ask the question “what’s worrying me about the project right now?” – much more incentive to fill it up, compared to the incentive to leave a full risk log as it is.
A blank risk log

Now I’m forced to ask myself what I’ve been worrying about this week:
A risk

Actions and checks

Here’s the important bit – the part that enables you to stare at a blank page again next week and identify the newest risks. We are essentially going to ask ourselves this questions for each risk: “what do I need to do right now so that I can stop worrying about this?”.

It turns out that the things you need to do will generally fall into three categories:

  • Something you can do right now
  • Something you can ask someone else to do
  • Something you should check on a certain date in the future.

The middle category can be converted into the other two (right now: ask someone to do something. Later: check they’ve done it.) So we just need to add spaces for Actions and Checks to our risk log:
Risks and actions

Emptying your risk log again

All I need to do now, to get back to an empty risk log, is to:

  • Add this risk log snapshot to my status email, so the customer / my boss knows what the major risks are.
  • Add the actions to my to-do list (or delegate them to others).
  • Delete the risk!

When I come back next Monday, I will need to very quickly check if any of the dates in the second table have passed, and answer the question if so. And then I can get on with staring at the blank first table and deciding what to worry about next.

What this doesn’t help you do

This is all very well, but remember it doesn’t help you do any of the following:

  • Knowing what you should be worried about. But it does remind you to ask the question! And you should get into the habit of asking everyone else too. Your team, your boss, your customer – everyone.
  • Knowing how to mitigate the risk. But I’ve found that if you publicise your risk log (again, to the team, your boss, your customer) then half the time they’ll sort it out for you anyway.
  • Actually carrying out the actions. Although it might shame you into doing so – especially if you make it public!

Please do let me know how you get on with Risk Log Zero.

Book Review: Thinking, Fast and Slow by Daniel Kahneman

29 January 2014, by

This is a book about how we think: how we assess probabilities, form opinions and make decisions. Its central theme is that there are a few specific ways in which we are a lot worse at this than we imagine, and there are some techniques we can use to counteract this. It’s an excellent and entertaining book which everyone should read.

On the face of it, it isn’t that relevant to software development, but since I started it a month or so ago I’ve already found a number of applications during the working day – particularly to project management. I’ll start with a typical experiment to give you a flavour of the book, and then give three findings that I think are applicable to our field.

Linda the bank teller

Linda is 31 years old, single, outspoken, and very bright. She majored in philosophy. As a student, she was deeply concerned with issues of discrimination and social justice, and also participated in anti-nuclear demonstrations.

Which is more probable?

  1. Linda is a bank teller.
  2. Linda is a bank teller and is active in the feminist movement.

In the initial experiment, 90% of those asked chose option 2. And even now option 2 feels more palatable to me; however, hopefully you can see on reflection that option 1 must be more probable, as it is a superset of option 2. This specific fallacy is called the conjunction fallacy and it has plenty of more practical, albeit less striking, consequences. Kahneman argues that it is caused by the representativeness heuristic, whereby we judge the probability of something being true by forming a picture of it in our minds and comparing it to reality. This works well a lot of the time but, as we can see, it sometimes gives the wrong answer.