Metrics

If you look at Agile, you will see a whole heap of ways to gather and show metrics. These may include, but are not limited to Cumulative flow diagrams, Burn down charts, Story points, Velocity, Lead time, Cycle time Just to name a few.

I’ve seen these used and sometime abused just because it is what you do in Agile.

I tend to do things a little different.

For me, metrics are used for a number of things

  • To look good
  • To help find problems
  • To help plan
  • To see if something made a difference

To look good

These are metrics that I call Vanity Metrics. They make you look good and are generally open to abuse. For example closing all stories at the end of a sprint even if they are not complete or have lots of known bugs so your velocity is nice and high. You then create new stories for the next sprint or bug tickets so your velocity remains high.

In my opinion, this is all for show and only strokes someone’s ego.

It’s is also not the metric that makes it a vanity metric but how it is used. All metrics can be corrupted to become vanity metrics and thus be used for gaming the system.

If it is there to make you look good. Then don’t use it any more. That is my opinion.

To help find problems

Metrics used to help find problems are when you measure something to determine where a problem lies. One method of doing this is to put dots on a card for each day it is in a position on the board. If the card hasn’t moved for a few days/weeks or even months, this may indicate a potential problem. It could show there is a bottleneck somewhere. What is the bottleneck? Could someone be over worked? Is there a lack of knowledge? Is there a wait outside the team? Has the work been prioritized incorrectly? Too little info before the work started?

It doesn’t matter what the cause is, it could be any number of things. The question becomes, How can you prevent it in the future? You may not be able to do anything now, but what measures need to be taken to make the problem go away?

To help plan

By gathering metrics, you can start getting hard data on how long something takes to deliver. It may take 4 hours work, but if it is not delivered for between 1 week and 6 months because of the way you work, then why start now?

If you don’t gather the data you can’t always see how long things can actually take to be delivered.

You can also see how much of what is delivered is actually used. How much is stillborn. How much value a piece of work gives.

How much of your work is planned. How much is unplanned. How much is business driven. How much adds to improvement. How much is innovation.

To see if something made a difference

I do some support work in my role. Part of that support work is every morning when I’m on the on-call roster is to do the daily health check. This involves looking through the issues of the last 24 hours and fixing, resubmitting failures. Every day, I take a record of the time it takes me to fix and resolve each problem, and then record the aggregated time to get a trend. (Note, I do this myself, I do not “tell” anyone else to do it. Other members of my team may choose to do this as well). I then put this into excel and get a trend of the time it takes to resolve these issues each day.

Then, I choose an issue that has caused me the most pain, and work towards making it go away so it never happens again.

The metrics I take are used to determine if fixing the issue made a difference to the overall work. It has. When I first started with the company, the morning health check took a whole day to do. Now it can take up to 15 minutes on a good day. Sometimes it can still take all day, but that is rare. The overall goal of the metric for me is to make it to zero, and keep it at that.

Taking these sort of metrics gives you hard data, even in the short term to see if something you have done, an experiment, a fix, a deployment of new functionality actually made a difference.

Another example could be the deployment of a new feature on a web page. Did anyone use it? You won’t know if you don’t record the data.

Conclusion

Don’t get bogged down in the standard metrics that “Agile” uses. They may or may not be useful to you. What is more useful is to record the metrics to drive a goal, to drive decisions based on hard data, not on intuition, gut feel, or opinion. Sometimes, you have to make up a metric based on the effect, as not everything is directly measurable.
Sometimes, having no metrics at all can be useful. Don’t measure everything, just measure a few things until the goal is reached, then move onto something else.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.