This is a rolling, daily enhanced burndown chart. Yes, you read that correctly. Normally, an enhanced burndown chart is used to expose feature creep and predict the delivery date over a series of iterations. However, as an alternative to a daily burn down tool directly in Mingle, we developed this Mingle chart to help measure our progress on a daily basis.

This is how it works. At the start of a project (or iteration) a certain amount of work will be known, and roughly estimated. This work is tracked in Effort Points in BLUE which begins with a certain amount of Effort on the Y axis. Each day (or so), some stories should deliver. The amount of Effort Points that deliver with each story are subtracted from the orginal total, and the value of remaining points will be lower for that day. This will cause the line to trend towards zero.

Meanwhile, as we all know, new work can be generated as part of a project. Sometimes this work must be also be done along with the planned work (It's required, or dependant). Work that's not required should be done in a future iteration or project. The required new work that has been 'discovered' since the project (or iteration) began is tracked in RED beginning at zero on the Y axis. As you burn through this work, it will show up as a continued downward trend off the original blue burndown. So, this red area indicates the rate of discovery of your new work. At some point, we hope the discovery will cease, and this red trend will flatline. 

This new work obviously will delay the end date of the project (Unless you are magically discovering new capacity). By drawing the trend line of the planned work burndown against the trend line of the rate of discovery, the point of intersection will fall below the X axis. A vertical line downward from the intersection point to the dateline labels will give you the roughly expected delivery date. This might not be super-precise, but it should be illuminating enough to cause a correction, i.e. cut features, burn down faster, or accept that the orginal date will probably not be met.

A couple important things to note about this setup:

• This chart needs the standard "Estimated On", and "Development Completed On" datestamps to be set correctly as items deliver, at a minimum.

• To cause the discovery burndown to begin at zero, specify a totally invalid date for which the estimated points would always be zero. (like 1/1/1000)

• The chart start date (2009-02-5 in the example below) should be the start date of your project, and use this value in the 'Estimated On' selection statements as well.

• If you are using this to track work within a traditional sprint iteration of large stories, you may need to be delivering something fairly often to get useful information. Assign effort points to tasks if you have to (GASP!), and deliver them. Or switch the whole contraption to use tasks as delivery items and burndown hours on this chart instead. Also, in a traditional sprint situation, you might not have the option of accepting a new iteration end date. But you can still make other adjustments. Re-scope some work, or add capacity (euphamism for 'work harder').

• This works best to track small rolling (overlapping) sprints that are done in support of a known goal they all contribute toward.

• You might need to adjust the trend lines manually to account for a particularly 'rocky' burndown. This could greatly affect the predicted end date. Use your trained eye to reflect the actual state of the burndown you are witnessing. Particularly, if your discovery trend flatlines early on. Then, only the burndown becomes important. Use the trend-scope parameter to make adjustments, if needed.

As you can see in the example chart, this team magically "added capacity" at the last moment to meet the milestone...in this case a movie production deadline represented by a vertical trend line drawn in grey :)