I want to share with you a post I’ve just read in the Agile Journal web site called: Agile Projects Must Measure Business Value . Of course I suggest that you read the whole article: I just did a personal summary.
It deals with the well known problem that we have to face any time we want to change process (especially when you move to a non-standard one like an agile method): how can you say that this new system is going to be better?
This topic introduces the interesting topic of measurements and metrics: a topic well known and loved by agile people.
The author did a research on a number of companies asking these questions:
What metrics do your clients typically collect and report on?
What metrics do you advise them to collect and report on, to better reflect an Agile project’s success?
Have you seen Agile teams measuring business value, and if so how?
Are there any best-of-breed tools or techniques that you recommend to measure Agile project success?
The result was pretty standard:
The list of traditional development metrics is obvious. We continue to see teams focused on quality metrics, such as defects per phase or release; schedule metrics, such as actual effort/days versus estimates and delivery milestone achievements; and cost metrics, such as budgeted versus actual costs, internal (sunk) costs, and also production support financials
But one of the interviewed has something to say about standard measurements:
[…] let’s use an analogy to football. I listen to all these analysts (professionals) tell us that the keys to winning are running the ball (increasing time of possession) and stopping the run (decreasing the opposition’s ability to control the ball). Nonsense! These are not the keys. Scoring more points than the opposition is the key.
And here are the author’s advice
Most teams transition to Agile metrics and simultaneously maintain more traditional metrics and reporting methods. Scott Ambler, Practice Leader Agile Development at IBM Corporation, suggests that teams start by collecting some basic data, such as:
1. Actual cost (hours, $, …)
2. Some sort of functionality delivered (use case points, user story points, …)
3. Defect trends
4. Stakeholder satisfaction
[…] For managing and monitoring Agile projects, the experts agree: less is more