Lawrence Oliva touched on a great issue when using metrics in an organization “…it is important for metrics to support your project and not just be a bottomless pit for data collection and weekly presentation.”
I agree with this sentiment. Far too often do we feel good about collecting relevant metrics and then not finding time to implement the data in a feedback loop to increase the awareness and knowledge in the organization. This is the key for effective use of metrics to increase the quality of the next iteration.
Oliva continues “If currently used metrics are not driving your team’s time, energy, and skill set mix towards achieving project success, it’s time to select a new set of measurements.”
Selecting new metrics may be premature if the current ones are not being used effectively. If problems are arising after the metrics have been fed back to the relevant people, including additional explanation as why anomalies were apparent and suggestion for improvement, then a change in metrics may be required.
Oliva suggests selecting two metrics for the Project Manager, two for the Development team and two more for the Management Team.
I would enhance this to three metrics each, totaling nine. There are several reasons for this but the main one is that having two reports will often lead people to implicitly feel that a choice needs to be made to improve one or the other, whereas often they are not mutually exclusive. I Adapt Rothman and Derby’s “Rule of 3″. One solution is a trap with no choice, two alternatives give a choice of this or that while three alternatives leads people to come up with more options.
I like the metrics chosen for PMs and Senior Management however one of Oliva’s suggested metrics for the development team, Lines Of Code (LOC), I would argue is not even a metric. Even if we agreed it was, what does a a sudden drop in this number mean - a section of the codebase was deleted and lost (bad) or someone refactored the codebase to improve quality (good)?
My three initial metrics for the development team would be:
Bug Count (also stated by Oliva)
Blocks of duplicate code - various tools can do this and can be implemented as part of a build. If a bug exists in duplicated code on one instance may be found and corrected leading to the false conclusion that a particular bug has been fixed - it’s only been fixed in that part of the code.
Static Code Analysis Warnings - again various tools do this and once configured correctly gives huge benefit in identifying possible bugs pre-release
I do understand that other metrics are just as important - Code Coverage for example. But I had to choose only three 
Recent Comments