Agile development is well suited to software projects for many reasons. It empowers developers to make decisions proactively and keep projects moving forward. On the down side, Agile projects are not known for their formal reporting practices, which can be disconcerting for customers more used to a traditional project management approach.

My traditional PMI training taught me how to use Earned Value Management. EVM is a set of formulas that give insight into the progress of a project. These formulas allow you to put a dollar value on each dollar spent; a value of less than 1 is bad, while a value greater than 1 is good. These techniques require a thorough upfront understanding of the project. While this can work well on waterfall projects, it is not going to be accurate on iterative projects, where a degree of uncertainty is the norm.

No matter how agile you are, you still need to know at any given time whether the project as a whole is on track. The most common tool for reporting progress on an Agile project is the burndown chart. The burndown chart shows if the project is on track for schedule, by showing how much scope has been completed at a given time.  It does not show if you're on track for budget or give a picture into quality. To fill those gaps, there are two other tools I like to use in addition to the burndown chart:

• The budget burn-up, which tells us how much have we spent against what we planned to spend, plotted over time.
• The bug count, which tells us how healthy the project is.

By using these three tools together, we get pretty much all the information that we'd get by using Earned Value. If we're on track for budget and scope, that's great, but if the bug count is high, the project is struggling and quality is suffering as a result. But just how accurate is the information we get from these tools?

Budget

Budget is straightforward. If billing at time and materials on a blended rate, the time spent working on the project multiplied by the rate is the cost. It is tracked and invoiced through the same tool.  You can plot this on a graph against the planned expendititure (like the baseline on a Waterfall project).

Budget Burnup Chart

The two dotted lines represent the original planned expenditure, and the budget amended with a scope change request.  If actual dollars spent is below the baseline or planned expenditure, the project is under budget.  When viewed independently, this chart tells us that we have spent more than planned, which in itself is not a good thing.  However, the project is also ahead of schedule so more work has been completed than was expected, this is a good thing.  This demonstrates how none of these visual aids can stand alone to give an accurate insight into project status.

Bug Count

Bug count is only useful if there is a rigorous QA process. Zero QA also means zero known bugs. In theory, an iteration should produce "production ready" code (we strive for "done, done, done"). In practice, there is usually a bug backlog after the iteration is complete. This can be shown as an exported table from the issue tracking system. (We use Jira, which allows you to select the most useful columns when exporting table data.)

Burndown Chart

I've used three types of burndown chart:

• Effort remaining (in hours) to complete work in a sprint. This produces the most subjective results, but arguably the most useful for a weekly status report.

• Stories completed during a sprint. Day to day, not much use, because a task could be 2 weeks long and 80% complete, and you don't see this on the chart.  In theory, if you break down stories into similar sized units of work and use a binary approach to tracking (done or not done), a "task complete" burndown chart would give you what you need. In reality, many stories don't break down into equal sized work packages.

• Stories completed during the entire project (iteration by iteration). This is a good way to look at velocity, but not useful for changing course mid-iteration when risks occur.

For status reporting week by week, the first chart is arguably the most useful. It is also the most challenging data to obtain because it relies on re-estimating work. Effort remaining is subjective; accuracy can vary depending on many factors.  But if you're in the middle of an 80 hour task, the only way to know if you're on track to deliver by the end of the iteration is by re-estimating the remaining work periodically. This could be in hours remaining, or percent complete, whatever works for the team.  It can be reported during a scrum or via a daily update to your task tracking software (we use Jira), or other tool such as an iteration tracking spreadsheet.

Feature Burndown by Iteration

A feature burndown, showing tasks completed per iteration tracked against the original plan. A binary burndown (done/not done) is a more accurate way of showing progress than the effort remaining burndown chart. It doesn't give visibility into the progress of a project mid-iteration, and therefore is not a good tool for monitoring progress on a weekly basis.  This chart shows the planned burndown against the actual.  At the end of Iteration 2, which is the current state, the actual is below the planned features completed on the burndown, so we are ahead of schedule with more scope completed than expected.

Effort Remaining Burndown Chart

An effort remaining burndown shows whether you're on track for schedule during an iteration.  This chart has hours remaining to complete the work, plotted against days.  This chart was generated using Excel, but Greenhopper is a Jira Plugin that will create this chart for you using data captured within each task, and assigned to an iteration, if this data is added and kept up to date at the task level.

The day to day reporting of time spent and effort remaining on a task allows the project manager to keep stakeholders informed of progress, and flag risks as they arise. The more accurate we are in reporting status (among the team and to our customers), the more the project's stakeholders will trust us. No project runs end to end without some bumps along the way, but if we can see them coming, we can respond proactively and ensure a smoother ride.