In recent years the demands from software development teams sound more and more like the lyrics to an old Daft Punk song. Stakeholders demand code that is harder (in complexity), better (in performance), faster (in delivery), and stronger (in security). 

So it’s no wonder that developers are stressed and burning out. In one survey, 39% of developers cited increasing workloads and demands from other teams as the top contributing causes for burnout. The same study also found that 10% percent of developers saw repetitive tasks as the main reason for stress and burnout. As that catchy song goes - more than ever, hour after hour, work is never over.

But how do you measure “work” and those “hour after hour” coding sessions in the context of software development? Cycle time is one of the most commonly employed metrics across software development methodologies to measure development velocity.

Before we delve into the whys and hows of cycle time calculations, let’s look at how time is (traditionally) measured in software development.

Velocity metrics and KPIs in software development

As a development team leader, one of your roles is to increase velocity (without causing burnout) by continuously improving how your team gets things done. As you know, before you can improve on something, you need to measure it as accurately as possible. For this, you need to select the most relevant metric. 

‍The two most common metrics for calculation and optimization in software development are lead time and cycle time.

Lead time & Lead Time for Changes

Lead time is a term borrowed from a manufacturing method by Toyota, and it measures the time between a customer placing an order and the time the customer receives the order. 

In software engineering, the velocity metric often used instead of Lead Time as Lead Time for Changes - one of the DORA metrics for DevOps. Lead Time for Changes measures the time it takes to implement, test, and deliver changes to a software product’s codebase. 

Instead of starting the clock when a client (internal or external to the organization) places an order or assigns a task, Lead Time for Changes measures the time between the first code commit in a task to its deployment in production. 

Cycle time

Cycle time is a metric that measures development speed from when work on a coding task begins to when it’s been delivered, deployed to production, and made available to users.

Another term borrowed from the world of Lean Manufacturing, cycle time is a velocity metric that focuses on calculating the performance of development teams rather than product managers, customer account managers, or decision makers assigning the development tasks.

Why calculate cycle time?

Cycle time calculation, on its own, introduces multiple benefits to the organization and individual software engineers. First and foremost, tracking time throughout the SDLC tends to motivate teams to focus on improving and streamlining processes and prevents both the submission and pulling of large code chunks for review. 

In addition, it can serve as a benchmark for comparison against the performance of developer teams worldwide.

There are other advantages to employing cycle time calculation and optimization that you should note.

A holistic metric for engineers

You’ll likely have metrics and KPIs to measure how long tasks take to get done, and you’re working on optimizing those metrics. However, focusing on indicators like lead time gives you a partial picture and a limited view of potential bottlenecks.

The main advantage of cycle time calculation is the holistic but specific view of your SDLC, which measures the engineering process rather than product outcomes.

Actionable and insightful

Cycle time calculations help you pinpoint the problematic areas and bottlenecks that may need your attention. By looking at the big picture, you can drill down into specific parts of the process and see where you can introduce changes or improvements.

For example, you may notice that work slows down during the review phase, which may be caused by a shortage of developer-first code security tools or a dire need for more automated testing solutions in your CI/CD pipeline.

Consistency and scoping

No one likes missed deadlines. No one likes guessing and estimating the time it would take to complete a coding task based on gut feeling alone, especially when speaking to the C-suite. Calculating and optimizing your cycle time can help you give estimates based on the data you collect.

The challenges with cycle time measurement

Cycle time is not a perfect metric, nor should it be the only one you employ. Its main drawbacks are rooted in its benefits: it is a holistic, “big picture” metric for software development leaders.

Not tracking individual performance

Cycle time regards software development as a team effort. Whether one developer did the majority of the work or it was effectively divided - cycle time focuses on how long it took the team to complete the task and get the code merged into production. Cycle time calculations won’t help you pinpoint the issue if the bottleneck in your SDLC is not a process but an individual.

Not considering quality

Software development management is often a delicate balance between speed and quality. Cycle time will give you a good indication of development speed but won’t help you with code quality. Ideally, you should pair your cycle time with other DORA metrics that measure code quality and reliability, like change failure rate.

Lag

Since we’re talking about velocity and speed, it’s worth noting that cycle time is a lagging indicator and cannot serve you as an “early warning” system for SDLC bottlenecks. It will take quite a while before your cycle time calculations indicate an issue, so this metric will not grant you instant visibility into your development velocity and the bottlenecks holding it back.

The formula for cycle time calculation in software development

To get a rough estimate of your cycle time, you need to measure the difference in days between the development start date and the ship date. 

Cycle Time = Release Time – First Commit Time

However, a more efficient way to calculate your cycle time is to break the process down into phases and sum up the total duration of each stage.

• Coding Time - The time between the first commit to a given branch and when a pull request is created for that branch.
• Pickup Time - The time elapsed between when a pull request is issued and when the first comment is made on a pull request, thus indicating that code review was initiated.
• Review Time - The span between the initiation of review (usually indicated by the first reviewer changing the PR state to “In review”) and the merge of a PR.
• Deploy Time - The time between merging the PR and the code being deployed to production.

Reducing cycle time with automation

Shorter cycle times often require a combination of organizational developer culture and intelligent tools that enable automation. In 2023, most software engineers will recognize the value and benefits of smaller pull requests and more efficient review processes. They need tools to offload repetitive tasks so they can focus on what they do best - writing code.

In the same way modern engineering organizations rely on metrics to consistently improve and optimize software delivery and velocity–security needs to instill similar metrics. Jit is leading a new way of thinking about security metrics as they apply to mean time to remediate, and change failure rate of introducing security vulnerabilities. We believe this approach to security metrics will deliver the same benefits in the security world as it has in the software delivery and DevOps world.