We are often asked in Agile about what metrics we can provide to the appropriate level of management. “Velocity!” we all say at once, even though we know that velocity carries its own built-in danger. “Quality!”, some say; “Releases!” say others. These are good too, but they reveal only a small part of a bigger picture. So what’s the answer?

Metrics are important, and we had lots of them in waterfall. The traditional command and control structure relied heavily on these metrics to support important decisions made at every level of the organization. When we transform from that structure into an Agile mindset, many (if not all) of those metrics become immediately obsolete. This naturally leaves a traditional management team feeling uncomfortable. We knew what to measure in waterfall, and we look to find ways to attain those same measurements in Agile, even when it’s not possible.

The trinity of possible metrics listed above is loaded with potential pitfalls that we have to avoid. We know that velocity by itself is relative only to a single team and there is no way to compare them except against themselves. Velocity is a great metric, don’t get me wrong, but it’s not a “look how fast we are going!” metric. Pushing a team to only go faster can often lead to inflated estimates, and not actually delivering more value. Quality is an excellent metric too. If we are turning out code with zero defects (okay, minimal defects), that’s a great thing! But if we are writing high quality code that doesn’t deliver value, because we are only working on the easy things, quality becomes a meaningless metric too. Releases! That’s the answer. Again, not really. Frequency of release is not indicative of value. We can release high-quality code on a constant basis, but if it’s not the most valuable work in our backlog, and isn’t delivering what our customers need, there’s no point. Releases are not the metric we are looking for.

So what is?

Well that depends.

First ask yourself what you are trying to achieve, and what questions you are asking to understand what that goal is. Once you know that, you can better understand the metrics that you need to measure progress toward said goal, by answering your questions. It might be a planned vs actual variance for the team to make sure they are working at a predictable, steady rate. It might be that the PO is placing value points on PBIs (using an organization-wide standard) and you need to know how many value points/team member are being delivered. It might simply be that you need to show an updated forecast of remaining work on a regular basis and understand where progress is slipping and any so that leadership can act quickly to reverse that trend.

Don’t lock yourself into a specific metric as the panacea for all your questions. Those metrics just aren’t there. Ask the necessary questions and understand what the ultimate goal of your metrics is, and choose them wisely.