The Burn-Down Graph

The burn-down graph provides the team with visual feedback on the sprint progress. The process of setting up a realistic burn-down graph is imperative. In this post, I’ll get into why and how.

I have been eager to share more from our experiences with Scrum. Some might remember our Scrum-series from back in the days (autumn ’08). Scrum is currently obtaining the characteristics of a fine wine, it’s getting better with time, given the right love and care. I would proceed straight to sharing our sprint analysis, but first I must clarify the concept of burn-down graphs.

What is a Burn-Down Graph?

The image below represents an ideal burn-down.

The Y-axis (point 1) shows how many hours we’re investing in the sprint (150) and the X-axis (point 3) shows how many days into the sprint of the total 30. Ideally we progress towards the end with the same amount of work completed every day. This would yield the ideal graph-line depicted here (point 2). The only complex situation so far is calculating the right velocity.

Velocity is how many hours we’re working on tasks on the project during the sprint. You might think of velocity as “how fast the project will go” (Putting in one million hours every 30 days would yield a very fast-going project, hence the term; velocity).

How to Calculate Velocity

In Utopia you could calculate that every hour of bodily presence of a project member is an hour of being intellectually present and focused at work on actual tasks. This ideal never holds up, and hence the definition of ideal being some hypothetical optimum.

So how do we find the deviation from the ideal? Let’s ponder a little at this question.

Say you are showing up for 37.5 hours a week, as we do up here in the arctic Norway (time spent eating penguins, whales and seals for lunch not included). Let us simplify and assume there are a total of 20 workdays in a month. That leaves us with 150 hours per month per project member.

Now, is that velocity?

— No.

Velocity is : Hours of bodily presence – (your mind wanders off + making coffee + toilet visits + dusting off that old cowboy hat + getting distracted + having a bad day). In short, velocity is the sum of ideal development hours we are able to put in, and thus all other non-ideal activity should be deducted from hours of bodily presence.

Presume the project member, Jackie Trombona, has just joined our project. He is planning on one week of vacation during the sprint. The remaining three weeks he will be available for the project. He is a very focused and deeply engaged developer. He checks email only twice a day, and keeps communications short, simple and conclusive – which makes him spend a maximum of 30 minutes reading/deleting/writing emails daily. He is effective, but being honest with himself he has calculated that he is loosing another 45 minutes from the ideal to “miscellaneous” each day. This is mainly for when his mind wanders off, or he is making coffee or chatting by the water cooler with colleagues about his multi-billion philanthropic hobby efforts. Another 15 minutes is deducted for the daily scrum. In total he “loses” 90 minutes a day.

This leaves him with 6 ideal hours each day. 6*5=30 hours a week. This means he’s 0,8 into the ideal time-spending, which is really good.

For this project, however he’s only available for 3 weeks this sprint, so he has 3*30=90 ideal hours available for this sprint. 90 of 150 is 0,6 of the ideal.

0,6 is his Focus Factor (FF) for this sprint.

Total sprint velocity =  150 * ∑ (FF(member1), …, FF(memberN))

In English, to find total sprint velocity = Find and summarize the focus factor for all participants and multiply it with 150 hours.

What Do We Do Now With All This Velocity?

Notice the yellow dot on the bottom at the far left below (point 4). This is the sum of our added estimates, which still is zero. The power of knowing the velocity is that we can now add tasks in sprint planning until the “itsy bitsy teenie weenie yellow polka dot bikini” reaches the level of our velocity.

When we’ve added 150 hours worth of tasks, the yellow dot has risen to the top, and we’re ready to burn down through this graph during the next 30 days. Upon completion of one task, the yellow dot drops the equal of the estimate of the task completed.  We can now, through the visual feedback of this graph, easily track our progress towards the sprint goal. When every task is completed, we will be at zero. Our carefully crafted parameters: estimates and velocity (as discussed above) makes this a realistic challenge which we expect to achieve, and when the challenge becomes realistic, it gets interesting and we stay focused on our goals.

Here’s a real-world example from an actual and currently ongoing sprint, 10 days in. As you can easily see, it’s currently on track to reach it’s goals even with some margin.

In upcoming posts, I’ll be showing some more of these graphs, and I’ll be going into the details of their nature. Stay tuned for that and more (via RSS).


Velocity and estimates are powerful tools for realistic planning. Combined into the burn-down graph it provides a clear and persistent visual feedback to the team on current sprint progress. We love the burn-down graph. We love it so much we created our own Scrum-software to automate it’s creation and maintenance.

Edit 10th or March ’09 : Check out the article describing a few of our real life burn-down graphs.