Metrics and Measures: What’s the Difference?



What is the difference between ‘metrics’ and ‘measures’? While answering this question, I am going to stay away from ‘text book’ definitions or differences on these two terms and I am going make it experience-based.

For people on the ground who are typically 'hands-on' team members,  ‘measures’ and ‘metrics’ are synonyms. Yes. For most of them these are synonyms. Those who write code or test code do not make a big deal of differentiating these two terms. They say, “Let us get the work done first, measure what matters, analyze, improve and move on.”  Some of them do understand the differences but they do not keep it all along and focus on those differences.

For Software Quality Analysts or Process Specialists, Researchers, Teachers etc., these are two different terms.

Whether that is an appealing answer to you or not, I think it is worth reading further and appreciating what these two terms mean to us in simple terms.

You measure certain things in software projects. Examples include effort, size (such as Function Point), number of review defects, number of testing defects, etc. When you combine or consider multiple measures to infer something, it becomes a metric. Examples include productivity (FP per Person Day), or cost of quality (COQ). Measures are fundamental (or raw data). Metrics are derived and help us in sense making and planning the next course of action.

Here is a simple example - weight and height of a person are measures and Body Mass Index, which is a function of height and weight, is a metric.

Metrics help in decision making. Metrics are expected to exhibit certain behavior. For example, productivity of a team is expected to remain steady or increase over a period of time under all general circumstances. Measures are collected but not analyzed in isolation in all general circumstances. Nor are they bound to exhibit certain behavior.

It is not that simple. Something which you perceive as a ‘measure’ can be a valuable ‘metric’ to someone else. For example, for a development manager who is working with a team and moving closer to the production release every measure matters. “Why have we taken 18 hours to fix this defect?” is not a reactive question. And, “Let us not react. Let us look at the average hours to fix defects. The numbers are not modulating at all. We are within limits” is not going to pacify either.  Right?

Obviously the way different stakeholders see and treat metrics and measures when the battle is going on and the way they do it after the battle is over are different. After the battle is over, some of those stakeholders and a new set of experts analyze, infer, interpret, extrapolate, and predict what is going to happen in the next battle. We fight different battles at different times. That is why, in order to win, understanding these differences is the first step and selecting the right set of measures and metrics is the next.

There is more to it. One topic is classification of measures and metrics. You will find different classification of measures and metrics at the website of National Institute of Standards and Technology.

Do you have any other points to add here?