I can define the time between bug/feature and fix/implementation. A Bug is reported and the bug is closed in the bug tracker. Pretty easy ? Sure you will have multiple of these, each for one severity like critical, blocker and so on. Use the API of your bug tracker to get it . That metric tells me if I’m still in my SLA.

Same for a feature. If the business analyst takes the time to describe the feature, it must be worth it. So whenever he switches to status ‘ready for implementation’ we count the time. If it turns out that several features sit around and do nothing we need to look at them and analyze why nothing happened and how we can prevent wasting time of the BA because if they did not get implemented for so long, chances are all the things around changed already and we need to rewrite anyway. But you are right, we are just starting to have a look at those.
We are doing agile development if this helps explain why we do look into these metrics.

Why do you think cyclomatic complexity is a pretty bad metric ? Just because of long switch statements ? Any more reasons ?

But a good thing with your article is that you have consistently misspelled cyclomatic complexity, which is good, because I think it is a pretty bad metric, so now you’ve potentially confused Google so badly that no more people can find it on the net. I suggest “Essential Complexity” as its replacement, since it will, for example, not give high numbers for a long, but simple, switch statement.