Measuring Agile Maturity

and the importance of cycle time

In my opinion, there’s only one efficient way to measure the maturity and performance of an agile team, and it’s done by measuring cycle time.

In a traditional project, you have the project cycle time, which is the time between start of the project and the final delivery or release.

In an agile project, the cycle time can be measured on the level of user stories.

Lean

The above reasoning is supported by two main principles of a lean mindset:

1. According to the Poppendiecks, reducing cycling time is one very important principle of a lean mindset: you get faster feedback and test results, you prevent work from clogging your development queues, you improve morale because the team sees that the work ‘dissappears’ faster from the backlog.
2. ‘Avoiding waste’ is the primary objective of a lean approach. Any wait time between the different process steps can be considered as waste. Reducing the wait time can therefore be considered as a good way to get rid of ‘waste’, and also reduces the overall cycle time.

How to measure

The following image shows a simplified view of the life cycle of a user story in an agile project, including the potential wait times:

The cycle time is the time between ‘Ready to Start’ and ‘Release’. This time can be signficantly reduced by reducing the wait times (WT1, WT2 and WT3).

Depending on how you organise your sprint backlog cork board (or equivalent), you can start by noting on each user story card the date on which the story became ready for development by your agile team. This might be the start date of your sprint.

As soon as you meet all the ‘definitions of done’ for that particular user story, note the actual date again on the story card. The difference between the two dates is the user story cycle time.

How to calculate the average cycle time

At the end of each iteration, calculate the average of the cycle times and divide the result by the average complexity of the user stories of the sprint.

The result of this division gives you the average cycle time of that particular sprint. The division by the average complexity is necessary to standardize on complexity.

Over time, when your agile team matures and becomes more efficient, you should see a decrease of the average cycle time. If this is not the case, then you’re doing something wrong, and there are probably some bottlenecks in your process that you want to resolve.

Advanced mode: Cycle time variance

Reducing cycle time is one thing, but what about cycle time variance?

Let’s see these two different cycle time-related metrics on a graph:

The distribution of cycle times for two teams (green, red). X-axis shows cycle time, Y-axis shows the number of cycle times.

The red curve show the distribution of cycle times of team 1, whilst the green curve shows the distribution of cycle times of team 2.

The green team has a higher maturity level because of two reasons:

1. The mean/average cycle time CT2 is smaller than the mean/average cycle time of team 1, CT1.
2. The standard deviation of the measured cycle times of team 2 (B) is smaller than the standard deviation of the cycle times of team 1 (A).

This means that over multiple sprints or projects, team 2 is able to produce better predictable output.

Why cycle time is the right indication for maturity

1. It focuses on the final goal (customer value) and not on the process (the customer doesn’t care).
2. It is very easy to collect the relevant data.
3. It’s a very simple and understandable metric.
4. You don’t need additional tools, only a pencil and a calendar.

Stefan Luyten

More information: http://www.triton-consulting.be