There are alternatives to ubiquitous, but esoteric, earned value methods for reporting progress to a schedule. Not every task qualifies as a project, and the use of earned value outside of cohesive, related activities can be abstruse and counterproductive. Burn down charts and burn down bar charts offers an efficient and effective approach to monitor the progress over time for any task where a definition of completion can be defined and agreed.

The horizontal axis of a burn down chart represents the timeline, while the vertical axis shows the work backlog. The simple rules for maintaining a burn down bar chart are to:

  • lower the top of the bar when tasks are completed,
  • lower the bottom of the bar (below the baseline) when tasks are added to the initial set,
  • raise the bottom of the bar when tasks are removed from the original set,
  • raise or lower the top of the bar when the amount of work involved in a task changes.

While the agreement to add, or remove work because of changes can be problematic, in practice professionals quickly come to rational agreements on how to handle change. Before beginning the burn down bar method of tracking--have an agreed-upon procedure in place to reconcile the addition or removal of effort.

Empty the trash, reconfigure a server, plan for a vacation--these tasks have nothing in common; but even unrelated, unordered tasks can be effectively tracked, monitored, reported, and predicted using the burn down bar approach.


  1. Institute of Electrical and Electronic Engineers Standard 1490-1998. IEEE Guide: Adoption of PMI Standard - A Guide to the Project Management Body of Knowledge. New York: IEEE 1999.
  2.  F.K. Levy, G.L. Thompson, & J.D. Wiest. The ABCs of the Critical Path Method. The ABCs of the Critical Path Method. Harvard Business Review. September-October 1993, p.2.
  3.  Roger Pressman. Software Engineering: A Practitioner's Approach (6th ed.). New York: McGraw-Hill, 2005, p.841.
  4.  Walt Lipke, and Kym Henderson. Earned Schedule: An Emerging Enhancement to Earned Value Management. Crosstalk. 19, no. 11, 2006, pp. 26-29.
  5.  Edward Yourdon. Death March: Managing Mission Impossible Projects. Upper Saddle River, NJ: Prentice Hall, 1997.
  6.  Barry W. Boehm. A Spiral Model of Software Development and Enhancement, IEEE Computer, May 1998, pp. 61-72.
  7.  P Kruchten. The Rational Unified Process, An Introduction (2nd ed.). NJ: Addison Wesley, 2000, p. 7.
  8. Kent Beck. Extreme Programming Explained. Addison-Wesley, 2000.
  9.  Craig Larman, Victor R. Basili. Iterative and Incremental Development: A Brief History. IEEE Computer, June 2003, pp. 47-56.
  10.  Mike Cohn. Agile Estimating and Planning. NJ: Prentice Hall, 2006, p. 219.
  11.  T. DeMarco, and T. Lister. Waltzing with bears. NY: Dorset House. (2003), p.12.
  12. Mike Cohn. Agile Estimating and Planning. NJ: Prentice Hall, 2006, p. 223

Over the next several weeks, the tasks in the initial set are completed. However, the work on the task that was added to the initial set continues--as illustrated in the next figure. Since the intent in this example was to track only the initial set of four tasks over 30-days--a new burn down chart should be created (analogous to re-baselining in Earned Value Management Systems). The fresh burn down will include the next set of high priority, unfinished tasks--and the cycle repeats.

With only seven days to go in the 30-day target for completion of the tasks selected for tracking--a complication emerges. A senior executive has issued a directive that an essential software security update be installed immediately on all servers and workstations. Unfortunately, the same personnel resources working the tasks in the scenario will be needed to install the security update. The burn down bar chart illustrates this disruption with the addition of a task below the horizontal axis.

When tasks are added to the initial set, the bottom of the bar is lowered as shown in the next figure. The tasks continue to be monitored, reported and tracked as before, but the addition of work outside of the original plan is succinctly identified.

Note that in this simplistic example, one task equals one unit--but that doesn't have to be the case. It is easy to assign a relative weight to each task, based on a scale that is logical to the participants. For example, tasks could be classified as low, medium or high levels of effort. Then, a respective weighting scale of one, three, and five units could be assigned for tracking purpose. Weighting tasks allows for a burn down bar representation that more accurately aligns with the resources allocated to each task. Here, a one-to-one approach is illustrated for simplicity.

In this example the task monitoring is graduated on a weekly scale (the x-axis) to align with the weekly management meetings. The initial set of tasks is identified and the work assignments begin on the 4th of September. One week later, management meets to review the progress on the burn down bar chart, and sees that one task has been completed (task number three). This progress is illustrated on the following figure.

The following week, the burn down chart shows that two more tasks have been finished, leaving only the one task (task number one) unfinished. This progress is shown in the next figure. It's easy to envision how a trend line could be added to the burn down bar to predict completion dates.

The trend in this simple example indicates that the four tasks will be complete within four weeks, and that the rate of productivity is about one task per week. The addition of a trend line to the burn down bar chart is illustrated by the next figure.

One approach to handling changes to tasks is to state the rule:

  • Changes to the text of a task description will result in an analysis by the team to determine if the change is additional work, or a reduction in work. The team will vote the disposition with disputes and tie votes resolved by the next-level manager. 

This simple rule assumes the team will apply their expert judgment with the best interests of the business in mind. Of course, this is not foolproof and is a rule that could easily be circumvented.  Still, with the understanding of the rule at the outset, the project team will have a respect for the natural language task description, and how that description serves as a requirement. Changes to the text of the task description should be controlled with an audit trail. Organizations must have a high level of maturity to be able to apply the burn down bar approach effectively. If the staff will attempt mendacious machination to manipulate the burn down chart--use another approach (and consider new hiring guidelines!)

Task Tracking Example

A simple example will illustrate how to pragmatically apply the burn down bar approach for unordered task tracking. In this fictitious scenario, there are four tasks that must be finished within a 30-day period:

  1. The installation of additional memory in a server;
  2. Completion of a report concerning a potential software upgrade;
  3. End of year reviews for the technical team;
  4. New desks and chairs for the front office.These tasks have no relationships, sequence, and are unordered. Aside from the 30-day completion requirement--the tasks are independent. Still, they are high priority to management and progress must be measured, barriers assuaged, and completion ensured

Assigning one unit to each task in this scenario results in the initial set of four plotted on the burndown bar chart as shown in the following figure.

Representing the burn down chart in a bar format shows the amount of work at the start of the tracking period--the initial set. In this action item tracking example, 21 action items have been selected to track beginning on November 1st. The following week, several actions have been completed and the top of the bar moves down to reflect that progress (18 actions remain).

Additional progress is seen on November 15th; the top of the bar moves down to represent the completion of two more actions. However, three additional action items have been added to the tracking set--and those additions are represented below the horizontal axis at zero (the Added series in the figure).

On November 29th, one of the tasks that had been added was completed--and that is illustrated as the bar below the zero line is reduced. But, one of the tasks in the initial set has been changed. The amount of work involved in the task has increased, so that increase in effort is represented by adding to the top of the bar (refer to the Changed series in the figure). In the burn down bar chart approach, changing the amount of work from the initial set moves the top of the bars up or down, respective to additions or reductions in the amount of work.

The following week (refer to the 6-Dec bar on the figure) shows progress and task completion as reductions in the top and from the bottom of the bar. On December 13th, the stakeholders have decided that several of the action items placed in the initial set have been overcome by events; three of the original action items are no longer relevant. These action items are removed from the original set, and the removal is represented by raising the bottom of the burn down bar up from the zero line. That reduction in the set of work (the scope) is illustrated in by the right-most bar in the figure above.

Burndown Bar Charts Applied

Applying the burn down bar approach for unordered task tracking requires four simple rules12:

  • As tasks are completed, the top of the bar is lowered.
  • When tasks are added to the original set, the bottom of the bar is lowered.
  • When tasks are removed from the original set, the bottom of the bar is raised.
  • When the amount of work involved in a task changes, the top of the bar moves up or down.

To use a burn down bar chart to track action items, a set of tasks are selected as the prioritized task list and coined the initial set. Everything needs to be done, but it's impossible to do everything. A triage process must vet the to-do list down to something that is realistic within the time and cost constraints. For example, the highest priority tasks that must be complete within the next 30 or 60 days would be a good selection.

The number of tasks in the set is represented as the first bar on the burn down chart. The total number of tasks can also be used as the vertical (y-axis) upper limit. A timeline appropriate for the level of monitoring is selected and used as the horizontal axis (x-axis) of the chart. The horizontal axis timeline should be aligned with the chart monitoring, review, and update schedule. There is no point in using a daily increment if the team plans to review and update the chart on a weekly basis.

Monitoring the progress of completed tasks is straightforward and involves plotting the timeline and the number of completed tasks--removing completes from the top of the bar. Spreadsheet software or the proverbial do not erase whiteboard are well suited for charting. If tasks are added to the initial set (the initial baseline), an approval authority should be designated in advance so that adding work is not arbitrary or capricious. Adding tasks into the initial baseline is analogous to a change in scope of a contract--even though there will not typically be such a formal agreement. Developing an agreed upon process to approve additions to the task list beforehand will save angst about adding work without extending the timeline.

Changing the amount of work involved in a task can be a problem if the changes are not controlled. Explicit procedures for changes in the scope of a task must be defined in advance to be successful with the burn down bar methodology. Inevitably, discoveries will be made after beginning a task that result in unexpected, but necessary work. There must be a defined, consensus process for handling these events.

In the figure above, the horizontal axis illustrates the days of the week, while the vertical axis uses a point scale that is representative of the backlog of work. With iterative software development projects, the work is often represented by story points. Stories come from the legacy of storyboarding, and are analogous to the more academic term use cases. Use cases and stories are used to describe the work that is to be implemented on a software project in terms of functions of the software.

The burn down chart comes from agile software project management--so examples are expressed in the context of software projects. However, the burn down chart can be applied in many ways, with the measurement of the work to be performed (the vertical axis) in any practical unit: ideal days, team days, person days, function points, number of tasks, and so on. In the example above, the project began with 280 stories on the first day, then completed 25, burning down to 255 points on the second day. On the third day the queue was 215, and on the fourth day it was down to 180.

By placing a chart of this type in a prominent location, project managers can offer their teams real-time feedback on progress (or lack of progress), and productivity. No matter what type of work elements need to be tracked, the burn down chart can be a useful tool to visualize and monitor progress. With the addition of trend lines onto the progress markers over time, the burn down chart can serve as a predictor of a completion date.

The burn down chart does a good job of communicating what tasks have been completed, and by adding trend lines--when tasks are likely to be complete. Trending on a burn down chart will be accurate if all of the factors affecting the tasks remain unchanged. But things change. Today, organizations must operate in a climate described as a "tumultuous sea of change that will continue for some time"11. Managers need tools that can accommodate the sword of intrinsic change--or fall on it.

Burndown Bar Charts

The burn down chart in the following figure uses bars rather than lines. The bar representation uses regions to illustrate and represent tasks, and for a representation of inevitable changes from the original set; that is, changes in the amount of work involved in a defined task.

The familiar to-do list: repaint the dining room; service the car; clean-out the closet. At home, the size of a to-do list is a function of the homeowner's dalliance or drive. On the job, the to-do list takes the form of a task set that must be finished. For example, managers monitor many forms of the to-do list: issue logs, action items, change requests.

These important to-do lists are by definition, unordered, unrelated, and do not lend themselves to the same tools used for the interdependent, sequential activities of a beginning-to-end project. We have a plethora of tools and techniques to sequentially deliver a well-defined project, but not many focused on asynchronous, unstructured work. This paper will offer an approach for monitoring and reporting of these unordered, unrelated tasks. The reader will acquire a method for tracking a set of unordered tasks to completion, and for reporting progress graphically.


Since the 1960's, project tracking and management methods have become ubiquitous. Techniques and tools abound for activity estimating, sequencing, and for schedule development: the Critical Path Method; the Graphical Evaluation and Review Technique; the Program Evaluation and Review Technique (PERT); the bar (Gantt) chart1.
In order to successfully apply these common methods and tools, the activities that make up projects must exhibit specific characteristics2:

  • The project consists of a well-defined collection of activities which, when completed, mark the end of the project.
  • The activities are ordered; that is, they must be performed in a technological sequence.

The problem is that managers are faced with tracking activities that are unordered and unrelated. For example, after a house is built the Gannt chart disappears and the schedule inexorably announces completion. But there are always leftover tasks--in construction lingo: a punch list. In the software world, the to-do list becomes the never-ending maintenance phase.
Academically, a project is a temporary endeavor with a defined beginning and a definite end. But that doesn't change the fact that there is always work to manage after the delivery. In fact, maintenance of deployed software accounts for over 60% of all resources expended by software organizations3. Many organizations manage, track, and report lists of unrelated tasks; these are to-do lists with turgid names: action items, issue logs, change requests, prioritized tasks, get-well lists, re-engineering!

Regardless of the domain or nomenclature, the simple methods presented here can be applied into any situation where:

  • the scope of a task can be defined, and
  • a definition of task completion can be established.

Over the past four decades, project managers have accumulated a significant body of knowledge and system of controls for cost and schedule. Earned value management is widely accepted and practiced. Arguably, earned value management is better suited to cost control than schedule performance. Moreover, earned value management schedule indicators fail when projects extend beyond the planned completion date4. And more often than not, when software is involved--projects do run over5!

In response, new methods for project control emerged in the 1980's and 1990's. Breaking large, complex projects down into smaller spirals6 and iterations7 proved to offer indicators of success or failure earlier in the life cycle. Time to market became the dominating force during the Internet hyperbole of the late 1990's--and the extreme programming fad became popular8. This created a handshake agreement, wink-and-a-nod opportunity for agile and scrum to pile-on. While build and fix wizardry will likely become footnotes in the archives of software engineering--iterative life cycle models have proven to be successful9. And as this presentation demonstrates, the agile movement does offer pragmatic contributions to the program management body of knowledge.

Burndown Charts

One of the most valuable tools to emerge from fast-paced iterative-style software project monitoring is the burndown chart10. Burndown charts are used to track incremental progress. The horizontal axis of a burndown chart is an iteration timeline, while the vertical axis shows the work that is planned to be performed during that time (the backlog). The following figure is an example of a typical burndown chart used on an iterative software development project.

Copyright © Snyders.US. All rights reserved.

The agile movement offers pragmatic contributions to the program management body of knowledge.

Unordered Task Tracking

The Burndown Bar Approach

John R. Snyder, November 2007