An efficient way to measure the maturity and performance of an agile team is by measuring cycle time.

Cycle time is the time spent working on an issue — typically, the time taken from when work begins on an issue to when work is completed, but also includes any other time spent working on the issue. For example, if an issue is reopened, worked on, and completed again, then the time for this extra work is added to the cycle time.

Applying Theory of Constraints(TOC) for measuring Agile Maturity

Although TOC was originally a system for improving the production capabilities of manufacturing, it can be applied to other industries – including software development.

Bottlenecks in software production are identified by measuring the trend in inventory at each step in the process. The trend in inventory is affected by the production rate( or capacity) of each process step. The overall production of the system should be balanced against the capacity of the bottleneck. The bottleneck should be protected and exploited in order to maximize its throughput.

-David Anderson, “Agile Management for Software Engineering”

According to TOC, 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.

‘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.

Using VIEW26 for measuring Cycle time across JIRA Issues

In the above chart, X axis is representing the number of days to go from some status to another status (let’s say todo to done), and Y the number of issues with that day count. So, in this example, we have 15 issues that took 2 days to complete a cycle.

For most decision making, people use average cycle time rather than the cycle time of individual units of work. Velocity will always average over the length of a sprint, at minimum. You can, of course, measure cycle times of individual stories. This will enable calculating or eyeballing the variability.

Why cycle time is the right indication for maturity

Teams with shorter cycle times are likely to have higher throughput, and teams with consistent cycle times across many issues are more predictable in delivering work. While cycle time is a primary metric for kanban teams, scrum teams can benefit from optimized cycle time as well.

Measuring cycle time is an efficient and flexible way to improve a team’s processes because the results of changes are discernable almost immediately, allowing them to make any further adjustments right away. The end goal is to have a consistent and short cycle time, regardless of the type of work

In most real-life product development scenarios, delay costs are a lot greater than capacity costs. So it’s reasonable to assume that you should minimize cycle time.