Sharing My Burndown and Burnup Excel Sheet

(Edit: 17 th august 2009 recap of this post) In this article, you’ll find links to download my burn down/up graphs as xls-sheets also containing formulas for analysis of a given iteration/sprint. It’s been developed in an agile matter, continuously adding new features and improvements as the feature requests and demands arrived.

Measuring performance is important. It helps you keep focus and improve. However, most such measurement methods of productivity, efficiency, story point delivery and so, are destroyed by the very same people requesting them. Say you’re breaking down user stories in to small deliverable tasks which you estimate in ideal hours. If you are measured directly by the numbers of hours you deliver, you’ll start increasing your estimates for each tasks, consciously or unconsciously. That is, the more you overestimate, the higher the reward. Ideally, you should be professional and don’t get affected by this, but that doesn’t fit in the real world. It’s plain and simple psychology.

Ask yourself

  • Why do we measure?
  • What are measurements good for?
  • What are my goals with the measurements?

To most, the number one reason is predictability! Having estimates on the size of the backlog and knowing the velocity of the teams eating away at the backlog is invaluable. It enables the product owner to plan and make better decisions.

Predictability stands tall as the reason to utilize a burn down and/or burn up. The other reasons are elements of agile engineering (AE) that are supported or enhanced by the information such measurements provide. Reflect and learn, improve and deliver!

I believe that all developers want to do they’re jobs as good as possible and be the best they can. If you’ve got waste in your process, such as dependencies to unstable legacy systems, this should be reflected in a bad factor (factor = hours worked / tasks delivered (in ideal hours) ). The worse thing you may do is to hide that waste in you’re estimates. However, you need processes to support this, to motivate the developers to continuously improve. Agile and it’s short feedback cycles with iterations and retrospectives is an excellent tool to support such improvements. In the retrospect every team member writes down what he or she feels went good or bad, what’s good practices and so on. Over time (several sprints) the sprint burn down will stabilize and predictability is achieved.

Right… Understand that you may do more harm than good if you’re adapting a technique without understanding the whys.

Finally, here’s examples of both a burn down and a burn up from a completed sprint. (Click twice on the images to view it full-screen)

Preview the xls sheet through the browser

To facilitate such smooth burn down graphs, these are keywords:

  • many user stories
    • able to scope in and out story
  • deliverable user stories
    • clearly defined DoD (definition of done)
  • deliverable tasks
    • good enough
  • tasks estimated in ideal hours
    • minimize the number of variables. Estimate the task only!
  • T-shirt sizing tasks(xs, s, m, l) or the “twice as big as” 1,2,4,8
  • color themes for tasks or something to visualize unplanned tasks
    • planned (those tasks created at sprint planning)
    • unplanned (unthoughtof tasks needed to complete a story)

The xls sheet you may find here at

Description of the data table to populate the graphs

  • First row, the sum of planned tasks.
  • Second row, accumulated unplanned tasks. Subtract scoped out or wrongly planned tasks.
  • Third row. Delivered tasks. Count them before the daily stand-up for discussion.
  • Forth row. Formula showing the remaining task hours to be delivered.

There’s a lot more to the xls sheets. I haven’t provided much explanations or descriptions. I hope to write more later. Ask me if you’ve got questions!

Personal note on the end of this generous post

A good manager, PL or scrum master steps back, encourages the team members to take point, come up with ideas and other initiatives. Sort of like a coach (in business terms). A coachs’ job isn’t come up with the solution, it’s to ask questions so that the client empirically comes to his own understanding. Reflect upon it!


About Ole Morten Amundsen

Developer, programmer, entrepreneur. Java, .Net, ruby, rails, agile, lean. Opinionated enthusiast!
This entry was posted in agile, personal and tagged , , , , . Bookmark the permalink.

5 Responses to Sharing My Burndown and Burnup Excel Sheet

  1. Neil Addison says:

    Very nice work. Look forward to more. My question: are the Cashed In SP(s) work that cannot be accomplished in this iteration and therefore moved out of the current scope of work?

    Thanks – Neil

    Program Management Office
    Brink’s Inc. USA

  2. Ole Morten says:

    Thanks. Yes, they are. At any time, you should be committed to user stories that’s on the scrum board, and stories should be taken out as soon as you know you can’t fulfill that commitment. Always hit zero remaining hours at the end of each sprint! The stories goes back into the back log and you make new priorities for the next sprint/iteration. Good luck!

  3. Einar D says:

    Thanks, Ole Morten! A perfect fit with my current needs.

  4. Pingback: Downloads of my burndown excel sheet have exceed 400 « Ole Morten Amundsen

  5. tulsid says:

    This is very useful, thank you for sharing the spreadsheet!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s