Demystifying Time Metrics: Cycle Time vs. Flow Time

It’s possible to resolve the time dilemma by mastering the metrics meant to manage it: cycle time and flow time are measurements created to track time, but in different ways and potentially at different stages. Here’s everything you need to know to leverage both metrics and make time measurement a force for good.

What is flow time?

Think of flow time as the broadest possible measurement of the process, as in, “How long does this take from start to finish including any delays or hiccups?” Flow time is part of flow metrics, from the Flow Framework’s six measurement metrics. (The other metrics are velocity, efficiency, load, distribution, and predictability.) Dr. Mik Kersten created the Flow Framework in 2018 to help organizations tie the software development process more closely to business goals. 

At its core, flow time is a way for organizations to visualize and ultimately understand (and improve) the entire software development lifecycle from end to end. Because flow time includes the time teams spend blocked or not working, it offers an unvarnished answer to the “How long will this take?” question. Flow time is also commonly used in manufacturing and as part of the Six Sigma and Lean philosophies.

Although part of the Flow Framework, flow time is also inextricably linked to cycle time, and in fact flow time is measured by multiplying the number of works-in-progress (WIPs) by the cycle time. Also, it’s important to remember that flow time is always going to be a larger number than cycle time, because it’s measuring the complete process. 

What is cycle time?

If flow time measures the entire process, cycle time is the way to track the stages within the process. Cycle time is essentially a subset of flow time, and it’s the perfect metric to add a modifier to, as in “pull request cycle time” or “code review cycle time.” Think of it as a way to measure all the discrete elements or processes that make up the overall flow.

Because cycle time can be used to measure nearly anything in the software development lifecycle, it’s uniquely situated to spotlight problems teams might not even be aware of. 

Organizations can use cycle time metrics to discover:

• Where and why blockers are occurring
• The need for training 
• How changes are working (or not)
• Why teams are missing deadlines
• What developers really need to be more efficient (tighter feedback loops, different tooling, better communication)

Is cycle time more valuable than velocity?

Teams can and should measure flow velocity as a way to gauge throughput and value creation. But it’s also critical to look at cycle time as it can bring to light some nuances velocity measurements can miss, such as unexpected blockers. Also, velocity measurements can be “gamed” through overestimation and it’s harder for that to happen when measuring cycle time.  

The benefits of measuring flow time and cycle time

We’ve repeatedly made the case that organizations can’t really know what’s going on in development without measuring, and that’s particularly true with flow time and cycle time. 

The flow time metric is the overarching data point: how long does the software development life cycle take, from start to finish, including delays? That’s invaluable data for both engineering managers and the business side because everyone needs to understand not only the scope of the process but also the scope of the downtime. 

But cycle time is where the rubber meets the road. With this data, teams know exactly what the average pull request or code review cycle time is (as just two examples) and they also have a solid idea of how to make it faster. The very nature of cycle time makes it the perfect candidate for iteration, tweaking processes, reducing works-in-progress, and generally breaking things down into more digestible chunks in order to increase speed. 

Less cycle time is definitely more for teams who now have the ability to innovate quickly, more easily change to respond to market forces, and have generally fewer sticking points in the process. Not only does this allow engineering teams to deliver more business value, but it also means potentially happier developers because of course no one enjoys being mired in outdated processes and practices.

How to get the most out of flow time and cycle time

Time feels elusive but it can be tracked and put to work. Here’s how engineering teams can get the most out of the flow and cycle time metrics.

1. Measure in context. Processes and productivity don’t exist in a vacuum, and simply looking at time metrics won’t be nearly enough for teams wanting to increase innovation and productivity while closely aligning to business values. We recommend a curated mix of metrics depending on organizational goals including the DORA metrics that can evaluate DevOps team performance as a whole and the SPACE measurements that are ideal to mix and match as a way to clearly view individual performance and goals. And of course, flow metrics bring engineering and the business side together around shared language and goals.
2. Create a culture of continuous improvement. The Accelerate State of DevOps 2022 Report (PDF link) found the organizations with the best “flow” and the highest rates of continuous delivery and deployment were those constantly tweaking their processes and paying close attention to performance at all levels. The more teams are rigorously focused on doing it better next time, the more customer value will be created and the higher employee satisfaction rates will be as well.
3. Compare the data. No program of metrics measurement is complete without an understanding of where that data stands when compared to industry standards. Regularly consult key industry benchmarks and schedule coffee chats with others in the industry.
4. Identify the problem areas. You’ve measured in context, and compared the data to industry averages so now it’s time to make informed decisions about problem areas and tackle bottlenecks that are standing in the way of forward momentum.
5. Come to an agreement on goals and changes. Bring all of the above to the table because metrics efforts are most successful when there is general buy-in and enthusiasm for change. Make a flexible plan, and don’t try to fix everything simultaneously. Teams practicing Agile should build incremental tweaks into sprints, and then use retrospectives to evaluate forward momentum.
6. Automate all the things. We know you already know this, but automation is *always* the gift that keeps on giving to engineering teams. So, while examining flow time and cycle time data, be open to opportunities to automate.

Put flow time and cycle time to work in your organization

Time metrics are some of the most powerful tools in an organization’s productivity arsenal, particularly when combined with a culture of continuous improvement. Tracking and evaluating these metrics doesn’t have to be difficult, and the resulting improved productivity, innovation, business alignment, and developer satisfaction are well worth the effort.