Email iconarrow-down-circleGroup 8Path 3arrow-rightGroup 4Combined Shapearrow-rightGroup 4Combined ShapeUntitled 2Untitled 2Path 3ozFill 166crosscupcake-icondribbble iconGroupPage 1GitHamburgerPage 1Page 1LinkedInOval 1Page 1Email iconphone iconPodcast ctaPodcast ctaPodcastpushpinblog icon copy 2 + Bitmap Copy 2Fill 1medal copy 3Group 7twitter icontwitter iconPage 1

Quick links

Introduction

There’s always a bit of chatter about burn-up Vs burn-down charts and which is preferable. In a burn-down chart there’s only one line, tracking work remaining against a timeline which is why some say it’s simpler to understand. However, start adding scope to a project which is underway and a burn-down chart can become confusing. A burn-up chart on the other hand tracks scope and progress on separate lines.

Before I begin rambling, here’s an annotated visual of a burn-up chart from a completed project:

Why burn-down charts can be confusing

Why? For me, because burn-down charts don’t clearly show the impact adding scope has on project delivery and because I’ve never seen a project where scope doesn’t change and it’s so vital that everyone (from the production team to the client) understands the consequences of scope change. In a burn-down chart the impact of scope change is not entirely obvious, for instance, if 4 points are added in sprint 3 and 4 points are delivered in sprint 3 the line on a burn-down chart remains horizontal. As we need to review our progress and also to make future planning decisions (eg: increase/decrease timeframes or reduce scope) the fact that scope change is tracked on the same line can be confusing and potentially demoralising for the team ‘But we nailed it last sprint, how come we look like we’re treading water?!!’

Burn-up charts work for our internal team

I know you might be questioning my last point about demoralising the team but bear with me because splitting scope change from progress made can have a positive impact:

  • The production team can clearly see that the project management tools we use are recognising their good work (as opposed to wiping all sense of progress during a sprint where scope is added)
  • The production team know that everyone else (including the client) is fully aware of the impact of scope change

The second point is important because if you talk to a lot of teams, one of the main concerns or problems they have is ever-increasing scope without recognition of what affect it has on the project, other than people telling them to work harder and longer.

Burn-up charts help us to work with our clients to keep things on track

You’re living in cloud cuckoo land if you think scope will never change during the design and build of a web application, product or piece of software (and by change I generally mean increase as you discover more abut what you’re doing). We’re in the business of product development and the whole point about product development is taking an initial idea and turning it into a working piece of software, with everything in-between focussed on discovering the best way to do this. This is where Agile kicks Waterfall’s butt because it embraces the very fact that along the journey things will always change and that it’s impossible to make every RIGHT decision upfront.

Back to my point about burn-up charts and clients/product owners: understanding scope change (and what affect it has) is so vitally important to the planning and decision making process throughout project development, having a transparent way of communicating the impact scope change has, helps me to work with clients to make the right decisions at the right time. For example:

  • Scope added but budget and deadline not changed: reduce scope elsewhere
  • Scope added, budget increased but deadline not changed: increase productivity (not as easy as it sounds but possible through adding members, paying overtime etc)
  • Scope added, budget increased and deadline movable: move the deadline to accommodate new scope

Now I know all these sound pretty logical but being able to communicate the affect scope change has on the project is not always as easy as it sounds without being backed up by solid data and a simple way of visualising it. By helping clients to understand the consequences of scope change you’re empowering them to help make the decisions necessary to meet budget, deadline or both.

Why I use burn-up instead of burn-down charts

Well, if you want to kill two birds with one stone (having a simple way of tracking and communicating progress internally and helping your clients – and everyone else for that matter – to understand how scope change affects project delivery) then a burn-up chart is the way to go. And whilst I appreciate burn-down charts are useful and simple, I don’t believe they communicate the scope change point particularly well and I don’t want to start using 2 charts when one does both jobs well!

Our burn-up chart template for you to download

OK, so maybe you ended up here because you searched the web for ‘burn-up chart download’ or ‘burn-up chart template’ or ‘burn-up chart example’ and you don’t care about my ramblings above. If so, here’s the UVD Burn-up Chart for you to download  you lucky thing you.

Share: