What is Cycle Time and Why Does it Matter?
What is Cycle Time?
One of the more important metrics we look at for our own engineering team, as well as for the engineering teams using Velocity, is Cycle Time. Cycle Time is, very roughly, a measure of process speed. We’ll explore the definition in more depth but first, it’s important to understand …
Why Does it Matter?
A number of engineering organizations practicing lean and/or agile development seem satisfied having their process be proof enough that they care about speed and are moving quickly. And, yet, these teams are likely not measuring any kind of speed. Or worse, they are using metrics more likely to lead to dysfunction than speed.
Mary and Tom Poppendieck, who popularized the idea of applying lean manufacturing principles to software engineering, discuss this phenomenon, specifically for cycle time, in their book Lean Software:
Software development managers tend to ignore cycle time, perhaps because they feel that they are already getting things done as fast as they can. In fact, reducing batch sizes and addressing capacity bottlenecks can reduce cycle time quite a bit, even in organizations that consider themselves efficient already.
In other words, rather than trust your gut that you’re moving as fast as possible, why not supplement your understanding with a quantitative measure? As with other metrics, tracking cycle time can reduce bias and provide a trustworthy baseline from which to drive improvement.
Back To: What is Cycle Time?
Ultimately what we’re trying to understand is the speed at which an engineering team can deliver working software, as measured from the moment they start working on it, until it has been shipped and is providing customer value.
Since the term originates in Lean Manufacturing, where “start” and “end” can be unambiguously defined, it’s not always obvious how to apply it to software engineering.
Starting at the end of this process, the delivery, is in some ways the easiest: delivery of software is the deployment of production code.
The beginning of the process is more difficult to define. Asking when software development begins is an almost philosophical question. If you’re doing hypothesis-driven product work and are testing your hypothesis – has work started? In his book Developing Products in Half the Time, to illustrate the inherent ambiguity, Donald Reinertsen calls this phase the “fuzzy front end”.
This is why we tend to see development broken into two phases, design and delivery, where design encapsulates activities prior to writing code. Since the delivery phase has a more regular and reliable cadence, it’s better suited to regular observation and measurement.1
Here at Code Climate, when we’re referring to the length of the delivery phase (and not the design phase), we use the term “Code Cycle Time”. More specifically, we define Code Cycle Time as the average elapsed time between the first commit and merge time for pull requests. We use these two markers since, while they aren’t perfect, they are more universally trackable than other markers we’ve considered.
What’s Next?
Hopefully you now have a better understanding now of what Cycle Time is and why it matters. As a next step, you’re probably starting to think about ways to effectively minimize Cycle Time. We took a data-driven approach to this question recently and analyzed thousands of pull requests across hundreds of teams. The results were interesting.
If you’re interested in learning more about the origins of Cycle Time in Software Engineering, Mary and Tom Poppendieck’s book Lean Software, Chapter 4 “Deliver as Fast as Possible” is a great starting point.
If you would like to start tracking your own Code Cycle Time, get a free Code Cycle Time report from Velocity.
Related Resources
Cycle Time in Lean Manufacturing
- “Cycle Time” - A breakdown of Cycle Time into component parts
- “Takt Time – Cycle Time” - Describes some fundamental misconceptions around these terms. (Fittingly, the post includes a now 8-year running comment thread.)
- “How to Measure Cycle Times - Part 1”
- “How to Measure Cycle Times - Part 2”
Cycle Time in Software Engineering
- Lead time versus Cycle Time – Untangling the confusion
- Understanding Cycle Time in Software
- The difference between Cycle Time and Lead Time… and why not to use Cycle Time in Kanban
- Measuring Process Improvements - Cycle Time?
- The Five Best Metrics You’ve Never Met
Related Terminology
- Takt Time
- Lead Time
- Wait Time
- Move Time
- Process Time
- Little’s Law
- Throughput
- WIP
1 Thank you to Accelerate: Building and Scaling High Performing Technology Organizations, by Nicole Forsgren, Jez Humble and Gene Kim for the Donald Reinertsen reference, as well as the articulation of software development as having two primary phases (Chapter 2, p. 14 “Measuring Software Delivery Performance”). Accelerate is an excellent resource for understanding the statistical drivers behind software engineering. We were proud to have Nicole Forsgren speak at our Second Annual Code Climate Summit.