agile Project Reporting

Agile KPI – Status Reporting

Agile recognizes that most effective software processes cannot be defined up front. It is a continuous process! And that’s the crux here. The PMO finds it difficult to measure agile projects, they need to adapt. What agile not really does address is the status reporting part. Obviously the daily stand-up is kind of a form of this, but what is with the stakeholders who are interested in the project but cannot take part at all stand-ups? People like this still rely heavily on a traditional project status report. However, these reports also have one problem: too many words, they are not clearly reduced to the facts.
In my point of view, the following facts should never be missed in an agile report and should be not more than a one-pager:

  • Velocity: The total of user stories a team delivers at the end of an iteration.
  • Overall completeness: This chart (e.g. pie) clearly shows how many story points are in which board state and gives you an overview about what’s already delivered, is currently in development and follows at a later point.
  • Burn-up chart: This chart sums up all delivered user stories vs. the entire product backlog. The vertical axis is the amount of Story Points. The horizontal axis is time, usually measured in 2-weeks or 1-month (depends on how you develop, so could also show weekly or daily progress).
  • Burn-down chart: This chart gives a clear indication of the status. It is calculated the opposite of the burn-up chart, so the more the line decreases the more value is delivered. As mentioned for the burn-up chart, the vertical axis is the amount of Story Points. The horizontal axis is time, usually measured in 2-weeks or 1-month (depends on how you develop, so could also show weekly or daily progress).
    The average velocity is used to calculate the potential end-point of the project.

The better a team’s estimates will become over time, as they learn from each iteration. These factors above help at the sprint planning to define what a team can/should achieve during a sprint, and what is too much.
Besides your one-pager includes several charts for velocity, overall completeness, burn-up and burn-down of your product backlog you should also include some comments about the state. Especially if the project is running behind or facing some (serious) risks, the stakeholders usually appreciate a brief explanation.