This is a presentation supplemented by a walk-through of Excel spreadsheets that demonstrate how to set up some of the charts described in the talk. The presentation has been given several times before and was well-received. A write-up, slides, and spreadsheets are available at http://davenicolette.wikispaces.com/Agile+Metrics.

This presentation uses the Principles from the Agile Manifesto as guidelines to understand what sorts of measures are relevant in an agile process. For example, one of the Principles states that working software is the primary measure of progress. That statement leads us to measure the amount of working software the team has delivered to date, which in turn suggests measures such as Running Tested Features (RTF) and Velocity. Another principle emphasizes the delivery of valuable software. That statement leads us to measure the amount of value the team has delivered to date, which in turn suggests measures such as Earned Business Value (EBV). The same approach leads us to several other measures that may be useful on agile projects, depending on circumstances.

A basic premise is that we should measure the minimum necessary to satisfy the needs of all project stakeholders, and nothing more. A common problem on traditional projects is the tendency for the manager to measure everything that is physically possible to measure, without regard to whether anyone actually needs or wants all those measurements. In keeping with the agile principle to do the simplest thing that could possibly work, we want to measure no more than is really necessary.

Another premise of the presentation is that any given metric can function in one or more of three ways: Informational, diagnostic, and/or motivational. Informational metrics are used to track progress, results, value, and performance to budget. Diagnostic metrics are used to expose problem areas. Motivational metrics are used to influence the behavior of team members or stakeholders. Any metric may function in all three ways at the same time. It’s important to understand that a metric may function as motivational (for good or ill) even if that is not its primary intent.

Projecting completion dates with a Gantt chart is largely an exercise in wishful thinking. The presentation shows how to project realistic completion dates based on empirical observations of the team’s capacity to deliver results, based on Velocity for iterative methods and on Cumulative Flow for non-iterative methods.

(I decided to submit this after reading some other submissions on the topic of agile metrics that seemed to be a bit overstated or dramatic. It isn’t that complicated.)