Written By Derek 36 Comments

Scrum burndown chart

What is a scrum burndown chart and why is it so important in Scrum? Scrum teams hate unnecessary bureaucracy. They don’t like meetings, they don’t like endless paperwork. They just want to focus on getting the job done. However, one report they will happily produce is the scrum burndown chart. Which might make you think that the burndown chart must be a really good report, and you’d be right.

Why scrum burndown charts?

A scrum burndown chart is very simple. It plots time remaining against work remaining. The idea is to see, at a glance, when you’re likely to be complete. Using an example project that consists of 250 story points and 20 iterations, a likely burndown chart would look like this:

A basic scrum burdown chart — A basic scrum burndown chart

The vertical axis indicates work remaining (titled Story Points in this image) and the horizontal axis indicates time (titled Iterations in this image). If you drew an imaginary line between the start point and through the average of the plotted points, you’d get your projected end point. If you do that on the graph above, you’ll see that we won’t be completed by iteration 20. In fact, the end point doesn’t appear on the graph! As you can imagine, the perfect graph goes from top left to bottom right in a straight line. This assumes that top left is the start point and that bottom right is the end point. In this graph, top left is iteration 0 with 250 story points. Bottom right is iteration 20 with 0 story points. In the graph below, I’ve drawn the ideal line in blue.

A scrum burndown chart with ideal line — Scrum burndown chart with ideal line

It’s clear that, almost from the start, the team were missing their target. From iteration 8, they were really going off course. By iteration 12, things had got as bad as they could get but on iteration 13, a lot of work was completed. The beauty of the graph is that my narrative is unnecessary. The graph makes the true position totally transparent to anyone.

Scrum burndown chart = clarity

Creating and maintaining a burndown chart is simplicity itself. You’ll often see them hand drawn and stuck up on the wall in the daily scrum meeting place. It provides a wealth of information in a concise, transparent and easily understood way. No wonder scrum teams love them!

One final thought …

If there’s one thing that the basic scrum burndown chart doesn’t show well, it’s changes in requirements. Imagine the scenario: Your customer, flush with the success of your Scrum project, has decided to add in extra user stories. After iteration 8, when the development team had completed 10 user points, the customer added in some new user stories that also totalled 10 story points. Net effect on the burndown chart? No progress indicated, as shown above. It won’t surprise you to know that this is a common situation in Scrum projects and there’s a variation on the burndown chart that handles it. It’s called the burn-up chart.

Scrum training

Turbo-charge your Scrum implementation with any of our Agile or Scrum training courses. Choose from the Professional Scrum series from Scrum.org or independent agile and scrum training courses, chosen for their superb quality.

Comments

Chandra says

8 Jun 12 at 7:33 pm

Nice article…i am interested to know your thoughts on how the burn down chart handles the newly added story points.

Reply
- Derek says
  
  9 Jun 12 at 6:32 am
  
  Hi Chandra
  
  You’ve hit at the major problem of the simple burndown chart right there. There have been a number of attempts to improve the basic burndown chart but they suffer from two major issues. Firstly, Scrum isn’t concerned with how long something took, just how much work is remaining. Secondly, any adjustment to the burndown chart makes reporting more complicated.
  
  With that said, Mike Cohn at Mountain Goat software has written an article on alternative Burndown Charts. I’m rather partial to the first alternate he proposes.
  
  Reply
Govindaraj Anand says

20 Dec 12 at 3:23 pm

Hi Derek,

Good article… Thanks for sharing this. Looking for more detailed one with different assumptions.

Reply
- Derek says
  
  20 Dec 12 at 4:21 pm
  
  Hi Anand
  
  It’s been on my mind to add some more detail to this article. It was originally conceived to provide help to those wishing to sit the PSM I assessment. In that regard, it’s great. However, in terms of burndown charts themselves, it could certainly stand some extra detail.
  
  Reply
John Paul says

22 Sep 13 at 1:36 am

I thought Development Team does not estimate remaining ALL stories to assign points, and in practice not beyond 2 Sprint (immediate next sprint) and partial (following to next sprint) as complete clarity might not be available.

In that sense I do not think Burn Down Chart provides valuable information.

Should Development Team assign Estimation point as soon as user story hits Backlog to have a right burn down chart?

Reply
- admin says
  
  22 Sep 13 at 8:31 am
  
  Hi John Paul
  
  You’re right when you say that Development Teams usually produce fine-grained estimates for the next one to two sprints only. However, because relative size estimation is so easy, it’s not uncommon for Development Teams to estimate all of the items in a backlog so that the Product Owner can maintain a Release Burndown Chart or a Product Roadmap. That’s what this article refers to.
  
  For Sprints, the Development Team will probably maintain a Sprint Burndown Chart where they might plot remaining task hours versus remaining days.
  
  Burndown Charts exist only if the Scrum Team see value in them,
  
  Reply
  - Yan Simkin says
    
    29 Sep 19 at 12:52 am
    
    Hi Derek, John Paul,
    RE: “it’s not uncommon for Development Teams to estimate all of the items in a backlog ”
    So even to draw Burn Down chart it is necessary to estimate full backlog like in this article it is 250 at the first Sprint.
    Then why Scrum Guide never mention this step as it would be of utmost importance?
    I have not seen Dev team taking a task to estimate(user-point-groom) 20 sprints worth of PBI-s but only maybe up to 3 sprints and not sure this task would fit under limit of 10% of Dev team capacity .
    This seems as a lot of waste to refine and point that much since many PBI-s would be dropped or changed during 20-sprint period
    So is it really uncommon for Dev team to point ahead of time for 20 sprints?
    
    Reply
    - webgate says
      
      29 Sep 19 at 10:24 am
      
      Hello Yan
      
      You may be mixing a couple of ideas here.
      
      Firstly, Scrum says very little about estimating other than that it must be done by the team that will do the work. Story points, like relative size estimating, are a technique that you can choose to apply on top of Scrum. Hence why the Scrum Guide never mentions this.
      
      Secondly, estimating Product Backlog Items (PBIs) doesn’t require that all PBIs are fully described. You may just have a title on a card and, for now, give it the estimate ‘100’. A quick and simple technique albeit less accurate. Teams I work with do this all the time.
      
      I agree your assertion that only the next 2 to 3 Sprints worth of work should be broken down and suffuciently detailed to be taken into a Sprint.
      
      Reply
Kim Nguyen says

4 Jun 15 at 4:59 pm

Thank you Derek for the nice explanation of Burndown chart, but I believe that an iteration is equivalent to a sprint, and there is no Sprint named 0. Correct me if I am wrong.

Reply
- webgate says
  
  25 Jun 15 at 8:45 am
  
  Hello Kim
  
  The terms iteration and sprint are often used interchangeably. However, in scrum, we always talk about a sprint.
  
  Sprint 0 is often used to describe preparatory activities such as choosing the environment, infrastructure, architecture, etc.
  
  However, the purpose of a sprint is to produce a potentially releasable product increment. A sprint would never consist only of preparatory items of work. Hence why the term is often disliked.
  
  Reply
Venkataraman says

6 Aug 15 at 5:20 pm

hi,

I have a question – the article says that the burn down chart doesnt tell you about change in requirements. Lets say 10 story points are added then shouldnt the graph slope downward by equivalent of 10 story points as opposed to being flat. The team has anyway burned down 10 story poonts right?

Reply
- webgate says
  
  14 Aug 15 at 12:02 pm
  
  Hello
  
  In fact, the chart will slope upwards because you have added more work.
  
  When I say that the chart doesn’t tell you about a change in requirements, I mean that you cannot infer anything from the chart about whether work was added or removed. For example, if a chart is flat, it might indicate that no work was done or, that work equal to the amount done was also added. The chart won’t indicate which of those circumstances is true. It simply indicates the amount of work remaining.
  
  Reply
Nasser says

26 Sep 15 at 3:57 pm

Thank you , very nice article …so interested

Reply
Zail Singh says

28 Feb 17 at 1:49 am

Not sure of your last para title “One final thought …” in the article.

Shouldn’t adding an extra 10 story points to the product backlog also increase the Y axis length hence reflecting the true picture of progress in the new chart?

If 10 story points are existing to the total count in product backlog then adding it to an existing iteration will only show good progress made towards meeting the goal

Reply
- webgate says
  
  2 Mar 17 at 9:06 am
  
  Hi Zail
  
  You hit at the core of what a burndown chart is for. It simply shows the amount of work remaining at a given point in time. Used that way, it is useful to us in determining how likely we are to meet our goals. If we want to show things like ‘work added’ or ‘work removed’ then what we have is not a burndown chart but something else.
  
  A name I’ve heard used is an ‘adapted burndown chart’ or ‘alternative burndown chart’. Mike Cohn describes it rather well in his article on the alternative release burndown chart.
  
  Reply
Muhammad says

16 May 17 at 11:37 am

Excellent article Derek. Great answers to questions. Cheers.

Reply
Aaron says

18 Feb 18 at 10:18 pm

“… the customer added in some new user stories …”

This language/workflow does not follow scrum, only the product owner is to add user stories to the backlog.

Reply
- webgate says
  
  6 Sep 18 at 6:14 pm
  
  Interesting thought but consider that, while the Product Owner has the final say on content and ordering of the product backlog but they don’t have to create items and they don’t have to be a gate before others add items either.
  
  Reply
  - Sahil says
    
    12 Aug 19 at 3:23 pm
    
    Hi Derek,
    Thanks for the great insights on the burndown chart.
    Building upon the above comment,
    does it mean that the PO accepted and prioritized the ’10 points’ the customer added in some new user stories …for the next iteration?
    
    Reply
    - webgate says
      
      13 Aug 19 at 9:53 am
      
      Yes, that would be the most likely scenario.
      
      Reply