.png)
Complete visibility into time & dollars spent
Create meaningful reports and dashboards
Set targets and get notified of delivery risks
Track and forecast all deliverables
Create and share developer surveys
Align and track development costs
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.
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.
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:
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.
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.
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.
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.