What is software development cycle time?

Software development cycle time refers to the period of time from an engineer’s first commit to the deployment of code. Some teams also refer to this period of time as lead time. Cycle time or lead time indicates the time taken to complete a particular dev task.

Cycle time is often used to infer a dev team’s process speed. It measures a dev team’s efficiency and ability to deliver working software within a defined time frame.

Measuring cycle time for teams helps leaders get visibility into the speed of each team, time taken to complete particular projects, and the overall performance of teams compared to each other and against the rest of the organization. Additionally, optimizing cycle time can help leaders build a positive team culture and can boost innovation and creativity in engineering teams. Cycle time is a lagging indicator, a metric that confirms patterns that are in progress. This means that cycle time isn’t a productivity measurement tool, rather it can be used as a signal of underlying issues in a team.

Since cycle time refers to the speed of team performance, most teams strive to attain a low cycle time within which their teams are able to achieve optimum efficiency. The Accelerate State of DevOps Report research of 500 engineering teams suggests that the top 25% of successful engineering teams achieve a cycle time of 1.8 days, while the industry-wide median is 3.4 days, and the bottom 25% of teams have a cycle time of 6.2 days.

The impact of high cycle time

Risk to code quality

When cycle time is high, a natural eventuality is for more work remaining in a work-in-progress status. As sprints close and deadlines loom, engineers end up juggling between several unfinished tasks, increasing the risks of errors and writing buggy code. At the same time, the longer it takes to merge code, the more context is lost by authors. These incidents impact code quality and increase the chances of missing edge cases. This is a vicious cycle, when it takes longer for engineers to revisit the code after review, the longer it takes to fix the code, in turn increasing cycle time.

Risks to delivery

Increased cycle time inevitably leads to tasks overflowing sprints that delay delivery. As sprints remain open over time, it leads to several critical tasks remaining unfinished and hence impacts the speed of delivery for the team. Furthermore, the effort to review and rewrite incorrect or inefficient architecture or poor code, the loss in context due to long gaps to pick up reviews, and the context switch between WIP tasks caused as a result of high cycle time severely impact the productivity of the entire team and the quality of the code.

Bad employee experience

As code stays in WIP status, engineers shift between several tasks, increasing context switches and the associated lull in productivity. As the habit stretches, engineers find themselves context switching between different git branches and pull requests while working under the pressure of delivery timelines from the product team.

In most teams, cycle time increases are attributed to the bottleneck caused by reviewers. As more review requests pile up, it adds to the pitfalls of context switches, poor workload management, and threatens well-being. These circumstances compound into individuals feeling increased stress, anxiety, exhaustion, and eventually burnout.

When engineers and their teams work under such pressure, within a matter of time, they begin missing schedules and deadlines, often delivering code that underperforms. This leads to team members feeling unsatisfied, often impacting engagement and morale.

Why should you be wary of very low cycle time?

Though a cursory glance of a very low cycle time metric for a team might be an initial reason to be buoyant of the team’s performance, managers and leaders must pay attention to such instances. In almost every case of very low cycle time, which is lower than industry averages, we see that the time to review is considerably low. For engineering leaders, this is a potential “gotcha” moment since very low cycle time could be a possible signal of low-quality code reviews. Managers must implement checks and workflows that ensure thoughtful and detailed reviews for all PRs.

What causes high cycle time?

While managers and leaders are cognizant of the importance of cycle time, they aren’t always equipped with data for visibility into why their team’s cycle time might be higher or lower than optimum. Understanding the processes that constitute cycle time and delving into the components that make up cycle time can help leaders make decisions that positively affect developer happiness, productivity, and overall team performance.

Large PRs

Large-sized PRs take longer to code and hence they go unopened for too long, increasing the time to open a PR. For instance, most teams target PR sizes to be under 300 changes and when this threshold increases, the time to open the PR becomes longer. Even when large PRs get opened, they get stuck without being pushed to the review stage since most reviewers are apprehensive about reviewing large PRs for two reasons:

1. A large PR signifies a large effort on the part of the reviewer. It requires heavy and intense work for which the reviewer has to plan and reorganize their existing workload substantially to accommodate a large PR review.

2. Large PRs are infamous for their ability to introduce several new bugs. Hence reviewers view them as high-risk tasks.

Low seniority or expertise

High coding time and high time to review are often signals of low expertise within a team. When teams lack expert engineers or when junior engineers are not onboarded with a thorough orientation, learning, and development process, it reflects on the cycle time of the team. Most junior engineers or engineers with low domain expertise take longer to create a PR, have to go through multiple back and forth reviews, leading to a high number of edits, rework, and increased time to merge.

When a team lacks senior engineers and experts capable of complex reviews, the pickup time suffers. Reviewers without the necessary expertise take longer to open PRs and longer to review. This adds to a reviewer’s workload and becomes a bottleneck to the team.

Lack of documentation

Documentation in code and coding guidelines like code comments are a great practice that is unfortunately overlooked too often. Documentation can help reviewers and future collaborators review and work on code faster and better, reducing pickup time and rework time. Coding guidelines help authors to have the pull requests in a better state at the get-go. They also help reviewers avoid multiple back and forth on basic guidelines and workflows. This documentation is especially helpful in cross-team collaboration or cross-functional collaboration on code owned by other teams. Different teams follow different patterns of code and documentation helps maintain consistency. A readme specific to a codebase about coding patterns or supporting items like how to and where to add logs, and emit metrics, and approval criteria, etc., can go a long way in helping teams optimize pickup time and review time.

Low involvement & Low responsiveness

When reviewers lack engagement and involvement, they tend to not review code despite having enough time and resources. Similarly, when engineers are disengaged and slow to respond to comments, it increases the time a PR takes to go through a complete review.

High workload

An unmanaged and high workload can lead to engineers struggling with several WIP PRs, inevitably reporting a longer time to code and rework. For reviewers, the volume of review requests piles up towards the end of a sprint rather than a gradual inflow of PRs leads to them getting overwhelmed. This constrains reviewers’ own coding time and also leads to a high number of PRs being merged without review, thereby risking code quality.

As reviewers struggle with completing their own code, the reviews, and the rework, the team suffers a high cycle time.

High CI/CD time

Engineers might be waiting on builds to complete and tests to pass before the PR is ready for review, thus leading to an increase in cycle time. The process becomes even more inefficient when engineers have to make changes after every review and wait for a drawn-out and slow CI/CD that prolongs the time to merge. Not only does this increase the cycle time, but it also leads to feelings of frustration in contributors.

Lack of pre-commit sanity checks

When teams do not implement simple sanity checks before creating PRs (like linting and test code coverage) they lead to avoidable nit pics during code reviews (where the reviewer may have to spend time pointing out formatting errors or test coverage thresholds that should have been covered by the author by default).

How can managers combat high cycle time?

PR size matters

The first step to reducing cycle time is addressing the issue of large PR sizes as a team. Equipped with quantitative metrics about batch sizes, leaders can initiate open feedback conversations and retros to discuss issues such as breaking down PR sizes that enable teams to merge code at a consistent pace. Team leads can ensure that PR sizes do not grow large due to expanding the scope of work.

The team can also come together to acknowledge the complexity of new work, potential risks, and instances of rework. This can help team leads and managers to optimize processes and workload for better performance. When leaders notice individual developers with high levels of context-switching, they can address issues and inefficiencies in data-driven 1:1 meetings.

Better workforce planning

Team leads must ensure that junior engineers are onboarded, adequately trained, and equipped with the right tools and resources so that they can contribute to the team’s performance quickly. Leaders must also ensure that teams are composed of a balance of junior and senior staff to create an efficient work environment and foster a culture of learning and growth.

Incentivize reviews

By keeping PR sizes small, managers can ensure that peers pick up review work without fearing the usage of large periods of time. Managers can also distribute review workload fairly using quantitative input into existing workload management. Emphasizing code reviews across the team and rewarding a culture of code reviews can help more hesitant peers to pick up review work alongside their coding. Better training and better tools can also help developers to become confident in their reviews, helping them become more enthusiastic about review work.

Better workflows

Deployments should be consistent, reliable, and optimized for smooth operations. In order to achieve such a cadence, managers must ensure that their teams are provisioned with the right tools, communicate regularly with their teams regarding processes and bottlenecks, and create team environments that promote learning and development to strengthen the review process.

How optimal cycle time impacts individuals, teams, and businesses

Impact on developers: An optimal cycle time directly impacts developer happiness and satisfaction. Several engineers and managers often report their experience of feeling a sense of achievement, satisfaction, and purpose after completing projects and pushing code to merge. When engineers are able to merge more code because of efficient practices, it allows more time to work on innovation and newer projects. All these lead to better individual satisfaction and happiness.

Impact on teams: Measuring cycle time can help understand a team’s delivery cadence and help maintain stable efficiency metrics. When leaders strive to optimize cycle time, they are able to rebuild tooling resources and processes to adequately provision their teams. When cycle time climbs upwards, team leads can pre-empt threats to productivity by reorganizing their teams and workload to optimize performance. These preemptive steps can lead to a team succeeding in achieving its goals.

Impact on businesses: Business leaders can use the cycle time metric to align larger business requirements with engineering capabilities. When business goals include shipping more products or faster updates, studying the cycle time of existing teams helps leaders strategize resource needs and allocation. This encourages better, faster, and more data-driven decisions. Optimizing cycle time can help businesses complete more projects and resolve issues faster. This makes businesses faster to market, leaving their customers and stakeholders happier and satisfied.

Cycle time as a stand-alone metric offers immense insights into team performance, individual productivity, and business success. However, when cycle time is studied within the constellation of other metrics, the potential of engineering practice is greatly amplified because of the possibilities of optimization, alignment, and engagement. Modern engineering teams must adopt a practical and systematic approach to measuring team performance using a framework of metrics that are aligned with business goals. When this data-driven view is combined with qualitative input from good communication practices, the potential of engineering teams can skyrocket.

Hatica equips engineering teams with granular visibility into team cycle time alongside 60-plus other metrics enabling them to reduce bottlenecks to accelerated delivery and achieve a better developer experience. Learn how Hatica can help you build better engineering teams. Request a demo →