Quit Focusing On Vanity Metrics

You know how it goes, projects get put into queue, hours are logged, code is created, defects are logged, etc. There’s data being entered/changed in a variety of systems like PlanView, ClearQuest, QualityCenter, etc. Someone is requesting metrics so they can see what’s happened, what’s happening and what might happen. You try your best to get the data from the various systems to provide the requested metrics. Now the question is, did you provide vanity metrics or actionable metrics?

Vanity metrics can be defined as numbers or stats that look good on paper, but don’t really mean anything important.

Actionable metrics can be defined as numbers or stats that tie to specific and repeatable tasks you can improve on to help meet your business goals.

Example of Vanity Metrics: Total Lines of Code

Example of Actionable Metrics: Lines of Code added/changed/deleted by a specific function/module. Defects tied to test cases tied to the line of code, which in turn is also tied to a test case.

I’m not saying it’s not good to know how many lines of code your application consists of but what good is that number? What kind of informed decision can you make by just knowing that number?

Actionable metrics would allow you to focus in on the specific function/module to determine if the test cases were written wrong, missed requirement, technical issue, etc. The actionable metric would also allow you to see when the function/module really needs to be done. Application teams are always working on more than one release at a time so maybe that function/module isn’t even needed for 4 more months and there’s another module needed in 3 weeks.

Are your metrics based on vanity or are they actionable?