Agile Metrics Explained: Cycle Time
What is Cycle Time?
Cycle Time is a measure of how long completed work items spent in progress - how long it took to get them done. Unlike velocity or throughput, which is measured at the team level, cycle times are recorded for each individual work item.
Looking at recent cycle times for your team gives you an indication of the size and variability of your work, the predictability of delivery once work has commenced, and the speed with which you can respond to change.
What does good look like?
Most agile and lean delivery teams have a target cycle time limit (their Sprint/Iteration length in Scrum and SAFe, or their Cadence in Kanban). You can compare your actual cycle times to this limit - are you as responsive as you're aiming to be? What proportion of work gets completed within the limit?
Typically cycle times do not fit a symmetric normal distribution or "bell curve". The presence of delays, blocked work and emergent complexity result in some work taking much longer to complete, creating an asymmetric distribution with a long tail of high cycle times.
This long tail pulls the mean cycle time to the right, making it less useful for understanding what's going on. If Bill Gates walks into a bar, then on average everyone in that bar is a multi-millionaire! Instead, use percentiles to describe your cycle times: "50% of our recent work was completed within 5 days, 85% within 14 days and 95% within 22 days". Longer and fatter cycle time distributions reduce predictability, because you are less certain about how long future work will take to complete once it is started.
If your team consistently completes the vast majority of work items within their target cycle time limit, its an indication that the sprint length/cadence is a good fit and that your backlog refinement and delivery processes are providing good responsiveness and predictability.
What are the pitfalls to avoid?
The "two week sprint" has become the de facto default, and is often adopted by agile teams without consideration for their own context. If your team can't complete work within two weeks, then it doesn't make sense to have a two week sprint!
Choose a sprint length that means you actually get stuff done and get rid of "roll it into next sprint" syndrome. Does this sprint length feel too long, perhaps because you want more frequent feedback and more responsiveness? Then focus on practices and processes that reduce the time it takes to create quality work (e.g. test automation).
Cycle times are only measured once work is complete. This makes them a lagging indicator - by the time you notice an increase in your cycle times, the increase has already occurred and it's too late to address it! Measuring the age of your current work in progress is an excellent supplement to cycle times, because it shows the changes as they are happening.
How can I start measuring cycle time?
If you have a physical team wall and story cards, then collecting cycle time data can be as simple as a daily practice of adding a tally mark to each card in progress. Some electronic agile tools have cycle time reports available (also called "control charts"), with varying degrees of readability and correctness.
Alternatively, Mazzlo Delivery Analytics provides a real time view of your team's cycle times and work in progress age, with easy to understand insights and alerts. We offer a free trial, or you can contact us for more info.