Agile Project Metrics
Project managers who are new to agile methods often have questions about how to track progress on agile projects. Some of the traditional measures don’t line up very naturally with agile thinking and agile practices, especially measures that are concerned with tracking team members’ time and comparing estimated and actual task durations. One of the main issues is understanding how to project realistic delivery dates with methods that don’t lend themselves to the Gantt approach.
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.)
- Identify each stakeholder for a project and understand what measurements are of interest to each
- Understand the timeframe, level of detail, and scope of information to provide to each stakeholder
- Understand how metrics can function as informational, diagnostic, and/or motivational
- Understand how to put together a project dashboard or scorecard that conveys the right information at the right level of detail
- Understand how to correlate trends in metrics with opportunities for improvement in the team’s application of agile practices
- Understand how to use metrics to demonstrate the value-add of agile methods to skeptical management in a traditional organization that is in an agile transition