Agile CMMI: KPIs for Agile Teams

products, and the profile of the process that produced them. Second, KPIs gain relevance and timeliness when they are automated. Third, mediating process transparency through KPIs enhances communication with management, suppliers, and customers.

3.0 - Timebox your KPIs
An Agile process transforms backlog into working software through transformational stages: design, programming, build and test. In a given timebox or sprint, the process is characterized by two principals measures: the volatility, or degree of churn, created by the team with respect to logic artifacts, such as code and test script; and the volume of the logic artifacts produced, such as the net number of source lines of code added, or the number of backlog work items addressed in that timebox. The quality of the work product as it moves through the process is given by assessing compliance with the team's engineering standards.

3.1 - Volatility
Volatility informs the team of the transactions taking place in the process. Visualizing process volatility from a variety of perspectives brings transparency, and permits lean development governance[ii]. Consider how much we can learn from the following graph, showing the churn associated with coding changes for a May 2007 timebox[iii], expressed as gross LOC changed per week for summary activities:

In general, we want to see coding changes calm down in advance of a release, to give sufficient time for final test (e.g. integration, acceptance, or production trial). Volatility graphs depict durations and magnitudes: "Backend Integration" completed in the second week, with modest code changes (1,300 LOC) relative to the other summary activities. "Web Service Impl" ramped up to a peak period in the third week; this is a desirable trajectory in a timebox, often likened to an aircraft flight, with a smooth glide plane to land at the code freeze date. "Client Features", on the other hand, is undergoing such a high rate of change in the final week that it is clear that extra scrutiny will need to be given to contain the risk introduced to the project by those late breaking changes.

The next example shows how churn can also be examined in terms of who is contributing to the code base through the course of the timebox. This yields two valuable aspects of process: are programmers able to complete tasks in a timely manner, and is anybody making unauthorized changes to our project:

Contribution is not the same as productivity: there are many factors to programmer productivity beyond how many lines we code. However, if developers are unable to contribute work against backlog in a timely manner, then either they are blocked and need assistance (e.g. Barney seems to have gotten blocked before the halfway point), or the breakdown of coding tasks may be too coarse grained for real agility. Visualizing contribution support Agile methods by letting us put course corrections and mentoring in place early on, when they can do the most good.

There are many other forms of volatility analysis that yield insight into process: by stream (or branch); by framework; by type of logic artifact, to name a few. The important thing is to start with a small set of simple, pragmatic measures that make a difference, and build from there over time. 

3.2 - Volume
The volume KPI expresses the changing size of the logic artifacts over time. There are many uses for this KPI: volume is one of the principal correlations to future maintenance costs; OO efforts often want to see a reduction in volume at various stages, as classes are refactored, combined and collapsed; volume is fundamental to code coverage and defect density; and more.