Project Management

Burndown vs Burnup Chart

From the Scrumptious Blog
Scrum is the most popular framework used within an agile environment to convert complex problems into valuable products and services. In this blog, we will examine all things Scrum to shed light on this wonderful organizational tool that is sweeping the globe. There will be engaging articles, interviews with experts and Q&A's. Are you ready to take the red pill? Then please join me on a fascinating journey down the rabbit hole, and into the world of Scrum.

About this Blog


Recent Posts

The Agile Engine

Scrum at School

Why SAFe may not be safe

Scrum on Mars

Scrum vs Kanban


Agile, Agile Certified Practitioner, Agile Release Train, Agile Transformation, Burndown Chart, Burnup Chart, business transformation, Chief Project Officer, Development Team, Distributed Teams, Earned Value Management, Flexible Workforce, Information Radiators, Leadership, Lessons Learned, Mars, middle management, New Ways of Working, PMI-ACP, Product Owner, Product Roadmap, Release Train Engineer, Remote Teams, resisting change, RTE, SAFe, Scope Creep, Scrum, Scrum, Scrum Certification, Scrum in Academia, Scrum in School, Scrum Master, Scrum Team, Scrum Training, Scrumian, Stakeholder, Story Map, War Room


Burndown charts are a great visual way to track the remaining work on a Scrum project. You can track story points completed to get an indication of how your velocity is performing, or effort (in hours usually) to see how your expected completion date compares to your actual/probable one.

Burnup charts are used for a similar purpose, but they hold a key advantage over Burndown charts that not everyone new to Scrum/Agile is aware of. Personally, I love to use Burndown charts because my brain seems to be wired to see project work reduce over time, rather than see it start at zero and build up (with completed points) over time. Nevertheless, I have to concede that Burnup charts are a better tool and I will show you why.

Here's an example of a typical Burndown char:

You can see from the graph above that our project started with 100 story points, and that we expected (blue line) the project to be completed after 10 Sprints or iterations. Or in other words, around 10 points per Sprint. Our Velocity is therefore 10. The actual Velocity (red line) however tells a different story. We can see that is traveling slower than the expected target. In fact, the project completed after 12 Sprints.

Notice Sprint 7. The red line is almost flat. This can only mean that something happened during the Sprint to make the team slow down their Velocity. But what could it be? Did a team member go on holiday? Was someone sick? Did the Product Owner dump a bunch of work on the team which they accepted? Did the team come across a technology problem? Was the Scrum Master unable to remove an impediment to the team? Were there too many distractions from stakeholders? Was the estimation of stories not realistic? Perhaps the team just didn't fill in their completed stories yet?

This chart still tracks points and velocity, giving us the same information as the Burndown chart. However, notice the green line?  That is the scope (number of story points etc.) in our Scrum project. During Sprint 7, a further 10 story points were added to the project.

Remember that our Velocity was 10? Well, assuming that the team has done 10 points again during this Sprint (so on target with their Velocity), on a Burndown chart, this would have been displayed as a completely flat horizontal red line, even though the team did the same amount of work.

Both burndown and Burnup charts are great for the team to track their progress; burndowns more at the Sprint level, and burnups more at the Release level. However, Burnup charts are still great at the Sprint level.

We can see from the graph above that the team did very little for the first couple of days, and then picked up steam in the next few days to complete 38 story points worth of work. Notice the red scope line didn't change, but it could have, and we would have been able to see if very clearly. This information can be compared to existing Velocity and even placed on the Release burnup/burndown graph alongside points completed and other metrics.

So does all this mean throw away the Burndown chart and replace it with the Burnup chart? Well, not exactly. The Burndown chart has its place, and as long as you don't need to visually display if a slowdown in Velocity was due to an increase in scope, then a Burndown chart is fine. Yes there are Burndown charts that display histograms with bars that fall below the X axis. I personally can't stand these as I am old school; what is above the X axis and to the right of the Y axis stays there.

Given that OCD stipulation, the Burnup chart is in my view the best visual tool between the two.

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!
Sante Vergini Signature

Posted on: April 16, 2018 09:49 AM | Permalink

Comments (39)

Page: 1 2 next>

Please login or join to subscribe to this item
Good coverage of the essentials on burndown & burnup charts, Sante! You might want to add an addendum covering the use of burndowns for tracking progress within a sprint...

Informative article, Sante.
It looks like the Burnup chart information can be crucial in diagnosing and rectifying problems with a project.

I have to admit, I'm not a fan of having to create multiple charts when one can do the job (as long as it's not too busy), but I agree that burnup charts can be a good tool.

On my first read, I wondered why you couldn't just add the green line to the burndown chart? As I thought about it more, however, I wondered why the blue line (expected) doesn't change when the expectations (scope) change?

If you want to only maintain the burndown chart, and not both the burnup and burndown, changing the blue line to show that, in this case, you've changed from 10-11 sprints expected, will help create a more accurate picture.

Is there a reason to not change the blue line when the sprints change?

Great explanation. My concern with burn down charts is that I have seen project managers misinterpret them, not understand them or use them incorrectly. The burn up chart seems to be easier.

Thanks for sharing, very good article..

Thanks Kiron, I will add a paragraph on this.

Thanks Anish, it certainly helps.

Aaron, the two graphs shouldn't necessarily be compared, they are illustrations only. I had to cut and paste the other lines and flip them over to make the graphs similar in format. The two lines are not related. In reality the blue line would change when the scope changes, since this is a factor of scope and time. Either the blue line would rise higher within the same timeline (so need to increase velocity to complete the work in the same timeframe) or rise up and extend out to the right to meet a later date. I didn't have time to produce two graphs that directly relate to each other; the purpose of the blog entry is simply to highlight the use of a scope line (green) in burnup charts which wouldn't be used in a burndown chart. Why? Because in some circumstances your graph line will go up, not down, which kind of defeats the purpose of a burn"down" chart. It becomes a moving target. Unlike a burnup chart where the line will never go down, because it tracks work already completed. Yes it could go flat, but it wont go down. The burndown can go flat, up and down. People do sometimes use histograms showing lower (and higher) than the X axis to reflect changes in scope. I don't use it. I may do another blog about this feature in burndowns. In my view, burndowns (without the histogram included) are a good indicator of progress if the product backlog has been well defined and unlikely to change much, and burnups are good for progress trends and forecasting.

Thanks Paul. Can you give an example how project managers misinterpret the burndown chart? Sometimes complexity presents itself due to over simplification.

Thanks Eduin.

Great summary Sante, really good one.

Nice insight, Sante.

I would not be overly worried about an increase in scope misrepresenting the data in the chart, though. A change in scope hits the expected velocity curve which would, by itself, change.

Additionally, in an ideal scenario, addition to scope should not impact velocity by itself - it should just increase the 'distance' (as shown in the blue line in the burn-up chart example). This can be depicted in the burn-down chart as well.

Anyway, all of this is beside the point. I strongly agree with one key distinction in your post - that most of the population understand a burn-up chart more intuitively than they do a burn-down chart.

Thanks Rami, it was a little rushed, so plenty of room for improvement next time ;-)

Thanks Karan, true, normally an increase in scope shouldn't impact velocity and yes it should increase the distance, however, if it doesn't impact the distance (finish at the same time) it will impact velocity slightly since the increased scope the team may take on in one sprint will bump up the average velocity. But the blog wasn't so much about velocity as it was the identification of increased scope against work completed.

Sante, keep the im[roved version for somewhere else ;-)

You read my mind lol.

Thanks, Sante. In my last project, used burnup. I like to showcase the delivered value as the project progresses through the iterations. It also seems they better represent and are easier to read.

Would you say you prefer burnups? I actually prefer burndowns but in this application burnups have the advantage.

Tbh, I like to use both. They both have value, with each serving a purpose and/or audience.

Very informative with nice elaboration. Thanks a lot.

Sante, thanks for the clarification. An aspect of this that does not get explained well, in the explanations that I have seen, is that when you are adding scope/story points to the burndown chart, the only way to tell is to compare the two burndown charts from before and after the change. In your example, I'm assuming that the previous burndown chart would have reflected somewhere around 90 Story Points. Both red and blue lines would shift, in the new burndown chart that has 100 Story Points that you show.

It's important to note that the red line, and possibly the blue line, would also shift in the burnup chart. But, if the shift was not caused by scope change, the reason would be no less obvious than it would be in the burndown chart.

Nice explanation thanks for sharing

Aaron, I have seen many variations in the burndown chart to reflect scope changes, more uncommonly what you suggest as the raising of 90 to 100 points, because the graph has already started, but other things like extending the time line out, or leveling the blue line, but again the latter doesn't indicate scope change so clearly. Remember the purpose of a graph like this is to give a simple view that hopefully cannot be misinterpreted, which is why a scope line in the burnup chart is the most effective. Now even though I don't like the histogram bars on burndown charts, my brain definitely aligns with a burndown view of things, which is why I look for alternatives to the burnup chart that not only give the right information, but more importantly are very simple to understand.

Thanks Michael.

Page: 1 2 next>

Please Login/Register to leave a comment.