There are numerous things you can measure when it comes down to software projects. I usually see that, if things are measures, 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 expresses 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 an 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.