That's the problem that was raised by the parent comment. There is no single 'unit' for this formulation of velocity because it is too qualitative.

It's a similar property to "code quality" in that regard. There are metrics like 'test coverage' or 'dependency graph complexity' but these can also be gamed intentionally or unintentionally much like LoC.

There are lots of descriptive metrics you can come up with that can be useful in exploring how you are performing or how your performance is changing with regard to quality or velocity. But treating such a metric as an actual proxy for the underlying property is not useful and sometimes counterproductive as you point out.

I think this is where the notion of software craftsmanship appears. We are still at the point where it requires an expert who is engaged in the process to essentially sense how they or their team is performing on these properties. They can use metrics to inform that sense or to help in determining what actions should be taken.

But this is frustrating for larger organizations where frequently the people who want to measure a certain property are not actually participating in the process because they are separated by multiple layers of management. You essentially have to trust that every management layer below you is able to accurately assess a qualitative property, which is difficult to standardize and scale.

How about measuring time until a customer (or plural) gains value from a feature? I know it's very ephemeral, but in general building a bridge is not the end goal, what if no one uses it or even knows about it?