You are right, Chris,

I did not measure value, barely output (because you can deliver a lot less faster), but rather the cycle time. But this is intentional.

The idea is to separate the measure of how well you are migrating towards Agile, from how good are you in your business.

If you think carefully, if a company tries to deliver more or less value, and it fails, it is often difficult to pinpoint the reason: bad programmers, bad SM, bad PMs, bad QA, bad processes, ... You have a lot to "blame", but almost nothing to pinpoint as root cause unless you can create a hypothesis and prove it.

On the other side, with this metric, we only focus in how well are we approaching towards the ideal agile practices. It is completely objective, easy to measure, and easy to find where we are delaying it at each point. It also guides about how to replan processes, so they can be closer to the objective.

And the closer we get to the metric objective, the better we can deliver value. Because if something fails, and we have a hypothesis, if we have to wait four or six months to test whether it was true or not, we are not adapting and being agile fast enough. But if we deliver every three hours, we can prove any hypothesis quickly enough to accumulate and compose value.

So yes, we should measure both, but, if we want to know if we are getting close to agile, or we got stuck, that is the metric.