Home > Agile stuff, Scrum > One Metric to rule them all

One Metric to rule them all

There are numerous things you can measure when it comes down to software projects. I usually see that, if things are measured, the things that are measured do not result in the expected behavior. I’ve seen KPI’s on number of bugs fixed, features solved within given estimation, documents delivered and even hours worked. Eliyahu M. Goldratt wrote in his book The Goal “Tell me how [and when] you’ll measure me, and I’ll tell you how I’ll behave”. People normally try score as high as possible on the specific metric that is used to measure them. So if you are not measuring the real problem, you’ll probably just end up with high scores on your metric but without any improvement of your real problem.

In case you are trying to improve some aspect of your software development process you need to define a KPI. The KPI should express a measurement on the root cause of the problem. Lets say e.g. that you want to improve your estimations for delivering features so that the SW department gets better info for making planning decisions. You decide to measure how many features are realized within the estimated time. Lets say that as a result of this KPI you’ll see an increase in issues that are solved within the given estimation!! Good……., problems being solved right?

but….. did the estimations really improve? or did the estimators just added more padding to be sure their estimations were ‘correct’? Taking a step back… were you unhappy with the estimations or with the time it takes to deliver features? Why why why does it take so much time to deliver a feature? What is the root cause?

If you are not that happy with the time it takes to realize a feature than you could measure just that! From Lean we know that the time it takes from the moment a feature is known until it is actually finished is called Lead Time. It is the average time it takes for one unit of work to go from start to finish through the process, including delays between sub-processes. We also know that in a stable system we have that Lead Time = CycleTime * Work In Progress + Delay Between Sub-Processes, where Work In Progress is the number of features currently in the system and Cycle Time is the average time it takes for a feature to be realized. Notice that the Work In Process strongly increases lead time. Also note that Delays Between Processes directly contributes to Lead Time.

By measuring the Lead Time, Cycle Time, Work In Progress and Delays Between Sub-Processes we are measuring the things that really matter. Next to that they give us a clear indication for potential wastes in the process so you can get to the root cause of why it takes so long to realize a feature! So once you have these metrics setup for your department you can start identifying the wastes and eliminating them by defining KPI’s on them. But remember the one metric that rules them all is the Lead Time!

the average time it takes for one unit to go through the entire process – from start to finish – including time waiting between sub-processes.

Categories: Agile stuff, Scrum Tags: ,
  1. July 27, 2009 at 2:49 pm

    One very important piece to add to this article is the information radiator to show the metric. Everyone needs to see the metric… ALL the time. It needs to be updated (daily).

    Otherwise it has little impact.

    Last thing you need is a manager yelling at people that the KPI is trending badly when they can’t see it.

    Good post.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: