Burning Down or Burning Up?

Several weeks back, I posted an entry about how I track my tasks and how I am dividing my time. As some savvy (aka annoying) readers noticed, one of the questions that the post conveniently sidestepped was: when will you be done? Um, well, perhaps never...

One of the more simple and effective project management tools for tracking progress towards a goal is the daily Burn Down Chart. In its most elemental form, it tracks the trend in the number of tasks that remain open each day. As you complete (or "burn down") the open tasks, your trend line should head towards zero - ideally somewhere in the neighborhood of your projected due date! However, if you are adding new tasks faster than you are completing existing ones, then your burn down line starts careening upward. Until you stop doing that, your project is "burning up" and will not converge.

Whether you are burning down or burning up, it is critical to know where you stand on a daily basis. Constant visibility is key to dissipating delusional thinking and motivating tough decisions. This week, I finally augmented my homegrown task management system to automatically produce daily burn down charts. You can see today's chart above. The red line depicts the number of open tasks - what I am trying to burn down. To make myself feel better, I also like to throw in a line for the number of tasks completed so far - that's the green line.

Uh oh! As you can see, I'm aggressively burning up rather than down (the red line continues its steady climb), and there are more tasks outstanding than there are completed (the red line still lies above the green line). You can also see when our local schools let out for winter and spring vacations - just look for the flat spots.

Note that the burning up phenomenon is not always bad. In fact, it is quite natural and expected in the early phases of the project. After all, generating lists of new tasks is the expected outcome of planning and design sessions. Also, no matter how great you think you are, development is inevitably a process of discovery. Realistically, you can't help but discover unanticipated nuances in the problem space or better, more elegant approaches as you work through the design, implementation, and refactoring of a product.

That said, at some point, assuming you actually want to deliver something, you simply must transition from burning up to burning down. Working harder and adding resources aside, this is usually accomplished by some combination of staunching the flow of new incoming tasks, completing existing tasks, and deferring tasks that are not absolutely essential to the current iteration of the goal.

How can you tell if a project is scoped such that it will actually converage. Is it possible to model your work in such a way that the burnup vs. burndown inflection point is very steep? This would apply the notion that failing faster is preferable to failing slowly.

I find the discipline to "put a lid" on an iteration is difficult, at least for me. There is always one more little feature or enhancement that I want to squeeze in. The challenge is being objective enough to actually say "enough!" There is always the next iteration, and the one after that.