Cycle time in software development can have different meanings for different teams. Some define it as the duration between the start of development on a feature and the code merge. Others see it as the time between the first commit and the merge.
At Uplevel, we have a flexible stance on what you can consider the start of cycle time. We understand that different organizations have different workflows. Regardless of the definition, reducing cycle time is vital for improving business agility. Shorter cycle times allow teams to quickly address bugs, avoid work piling up, and release smaller, incremental updates. This helps maintain a steady flow of improvements, making teams more responsive to internal needs and customer feedback.
Keep reading to learn more about what causes high cycle time and how to reduce it.
Many use the terms "cycle time" and "lead time for changes" interchangeably. But they are not the same. Lead Time for Changes is a standard DORA metric with a fixed definition: the amount of time it takes a commit to get into production.
Regardless of whether it begins at the start of work or the first commit, cycle time ends at merge. Lead Time for Changes ends at deployment to production. The latter provides a complete picture of development efficiency by including the deployment phase, offering insights into the development-to-production pipeline.
Note: Per the definition, cycle time measures the time until code merge – irrespective of whether it was done after reviewing the code or not.
Cycle time is a diagnostic tool for identifying bottlenecks in the development and review process. A high cycle time doesn't necessarily indicate inefficient developers; it often points to systemic issues.
For example, many factors outside a developer's control can extend the time from commit to merge, such as:
Delayed code reviews
Multiple review cycles
Shortage of available reviewers
Understanding these factors is essential for effectively addressing inefficiencies and implementing targeted solutions. While systemic issues can significantly increase the cycle time, developers can also take steps to improve the process. For example:
Writing clear, well-documented code that makes it easy for others to review the code.
Submitting smaller and more manageable PRs to make reviews quicker and more efficient.
Not submitting multiple changes into a gigantic PR
By focusing on the broader context and fostering best practices, teams can improve processes and reduce cycle time without unfairly pressuring individuals or specific teams.
To effectively reduce cycle time, you must identify where bottlenecks occur. Then, you can create strategies to reduce it. But first, you need to decide what activity you want to consider the start of cycle time.
In Uplevel, for example, you can measure cycle time by two methods:
First Commit: The duration of the first commit to when the PR is merged.
First Activity: The time from the earliest first commit or when a linked Jira issue moves to "In Progress" status until the PR is merged.
Regardless of how you measure cycle time, break it down into different phases and examine them separately. It will allow you to pinpoint specific areas for improvement.
We recommend splitting cycle time into three phases:
Initial development: From the start of work to when the PR is opened.
Wait: The time from when the PR is opened to the first reviewer action, such as commenting, requesting change, and approval.
Review: Time from the first review action to PR merge.
Then, take each phase's median to understand its typical duration and filter out the outliers or tasks that took significantly longer or shorter than usual.
Uplevel’s engineering intelligence platform can make tracking all of this a breeze. Book a demo now.
The complexity of pull requests (PRs) impacts cycle time, as more complex changes require more time to review. Tracking PR complexity can help you identify teams that consistently write complex PRs for the reviewer.
A good range to aim for is around 20% of PRs being complex. If over 50% are complex, consider breaking them into smaller parts. Keeping PRs manageable also reduces risks for bugs, as reviewers will likely have an easier time doing a thorough review given their time constraints. It also simplifies the review process.
Analyze complex PRs by repository, manager, or report group to gather insights to address cycle time challenges.
If engineers are constantly swamped with "high-priority" assignments, they won't have time to review PRs. That’s why managing work-in-progress (WIP) tasks is essential for reducing cycle time.
Here is what you can do to address this:
Assess WIP levels to reduce PR wait times.
Analyze PR throughput to minimize excessive context switching.
Evaluate the number of epics for each manager, report group, or team to prevent delays in code or reviews.
As an engineering leader, guide your managers in controlling WIP and promote conversations about multitasking to reduce cognitive load and maintain a steady flow of completed work. Prioritize making work visible and enforcing WIP limits to enhance focus and productivity.
The complexity of your software architecture can significantly impact cycle time. Tightly coupled architectures (components in the code are highly dependent on each other) often lead to longer cycle times due to the need for extensive checks during reviews. When elements are highly interdependent, changing one part may require modifications in others, increasing PR complexity and reviewer attention.
To reduce cycle time, work towards a loosely coupled architecture, where the components are comparatively independent.
Matt Hoffman, a product manager at Uplevel, explains this using an example: “If there are two different systems that interact via APIs, then you can make necessary under-the-hood changes and bug fixes to one of the systems as long as the API and behavior doesn’t change. Here, a subject matter expert can focus on their own system and doesn't necessarily need to know gritty details of dependent systems. This can speed up cycle time."
Implement clear guidelines and standard processes to reduce the challenges of complex architectures. This approach can simplify reviews, reduce the ripple effect of changes, and ultimately lead to faster, more efficient development cycles.
Effective project planning isn't just about scheduling known tasks—it's about anticipating the unexpected. Poor project planning, unplanned work and meetings, and ad hoc requests can significantly impact your team's productivity and lead to bottlenecks if not correctly accounted for.
Consider the experience of an enterprise sales SaaS company that struggled with this issue. Their VP of Engineering could not make data-driven optimizations due to a lack of visibility into unplanned work:
Uplevel helped him track the time his team was spending on Slack, meetings, and ad-hoc requests. He also became aware of how much time they had for deep work so he could plan better.
By improving your planning process and accounting for ad-hoc tasks, you can reduce hindering blocks in your development cycle and reduce your team's overall cycle time.
Reducing cycle time often requires a cultural shift in how teams approach work. This is only possible when senior leadership provides the direction.
Here are a few cultural changes that have proven effective across various organizations:
Create norms that encourage swift action, such as requiring PRs to be addressed within a day or even an hour. Emphasize the importance of unblocking teammates by prioritizing reviews over new code development.
While you should focus on reviewing PRs as soon as possible, you should also prioritize working on new story cards and developing new features. There should not be a situation where most of the dev team focuses on reviewing PRs in a sprint, which might lead to less work on new feature development.
Consider these strategies to strike a balance:
Distribute responsibility by assigning at least two reviewers to each PR so the other can work on it even if one person is unavailable.
Adjust your Git setting and create a pool of potential reviewers. This way, anyone available can pick up PRs–even if they are not the originally assigned reviewer.
Use PR assignments as a learning opportunity by having team leads strategically assign them to junior developers. This approach helps junior team members gain a deeper understanding of the codebase.
Even simple systems such as Slack alerts can ensure timely reviews.
Remember, the goal is to balance faster delivery with maintaining high code quality. Your approach should fit your team's unique needs and dynamics.
Enterprise software teams often struggle with high cycle times when “invisible tasks” like unscheduled meetings, defects triaging, or helping other teammates take a significant part of their developers’ workday. Reducing cycle time is about uncovering subtle inefficiencies in your software engineering processes.
Traditional approaches to finding the cause of high cycle time (like DORA metrics) fall short because they tell you what’s wrong but not why. Uplevel’s engineering intelligence platform provides comprehensive team data to reveal the underlying factors contributing to high cycle times.