How quickly can the team convert a requirement into a done increment?
Cycle Time is the elapsed time from when the work on a Product Backlog Item (PBI) starts until the work item is finished. Cycle Time represents the elapsed time from the moment the team begins developing a vertical slice of functionality until that slice is useable and meets the Definition of Done. It can also be defined as the amount of elapsed time a work item spends as Work In Progress. It includes the time the team spent actively working on the PBI and all waiting times when there was no active work.
Cycle Time has been identified as one of the most critical measures of software delivery performance. [Kim, Humble, and Forsgren, 2018] Unhealthy long Cycle Time is a signal that warrants additional analysis. You should look for other more specific metrics to uncover the root cause of any problems.
To collect the needed data points, you must note the start and end times of all PBIs. Then, over a predefined period, you calculate the mean and standard deviation of those measurements.
Cycle Time is purely empirical, which makes it such a powerful metric. It does not include estimates that are contaminated with a well-known desire to please, optimism (we can do it!), or time pressure. In the long run, you need not factor in external dependencies, like urgent maintenance work on other projects, unplanned team dynamics, or similar.
Since Cycle Time relates to the whole development lifecycle, there are many different ways to improve this metric. Some of them are:
Introducing or improving lean software practices (especially regarding identifying and removing waste, limiting work in progress, etc.)
Introducing or improving agility in the development process (e.g., Scrum or Kanban)
Improving engineering practices esp. quality-related (quality shift left and shift right, continuous quality, and automated testing, etc.)
Introducing or improving modern DevOps tools and practices - continuous collaboration, continuous integration, continuous delivery, continuous learning, automated testing, tight and fast feedback loops, etc.
Cycle time measures your development team's ability to deliver. That is why you should constantly monitor it and its trends. If Cycle time indicates opportunities to improve, analyze other more specific metrics to decide how to proceed (e.g., Build and Integration Frequency, Release Frequency and Mean Time To Repair). Introduce improvements one by one, starting from the one with the most significant gain.
In the OKR goal-setting methodology, metrics are preferably used as part of a Key Result.
There are hundreds of metrics in the Agile Tools ever-growing library.