Cycle time is an essential part of Dora metrics that helps evaluate your team’s quality and overall efficiency of your Engineering performance. In a nutshell, it measures the time it takes for your team to complete work items once they begin working on them.
To achieve Elite performance, you should actively work on reducing your cycle time. Since it represents the different phases of the delivery process, from code to production, you can focus on its four main components: coding time, PR pickup time, PR review time, and deployment time.
In this article, we’ll look at ways to reduce your overall cycle time by improving each of these four components. Let’s dive in!
What is coding time?
You’ve probably had this issue at least once as a developer or a team lead: it’s just taking too long to write code! Until you have the code written, it can’t be reviewed, iterated upon, and merged into production.
Coding time measures the time it takes from the first commit made to a branch until a pull request is submitted. We can correlate short coding time to low work in progress, small PR size, and clear requirements.
Keeping coding time under control is fundamental to improving your software development process. By looking at branches where coding time is pushing your limits, you can guarantee that your overall coding time stays under control.
What causes high cycle time?
- The task is too big. This is probably the most common reason developers spend too much time coding one task; it is simply too large.
- The task is too difficult. Sometimes, a task can turn out to be harder than expected. For example, maybe the problem wasn’t completely understood in the first place, or several unknown variables were only later discovered, making the project bigger than anticipated.
- The task is languishing. In this case, the coding time is taking longer than expected because the developer started working but then dropped the task for a long time. Most likely, the developer turned to other tasks based on new priorities.
How to reduce cycle time?
The best thing you can do to reduce cycle time is to educate your team on the need to divide the work into small, manageable pieces. This will improve the overall coding time and positively affect PR times, where the commits get reviewed faster.
What is PR pickup time?
You’ve worked hard on a piece of code and finally finished it. You then create a PR and wait for the review, but nothing happens. Your team didn’t notice your pull request, even if you assigned the PR to someone.
PR pickup time measures the time it takes from when a pull request is issued until someone starts to review it. Low PR pickup time represents strong teamwork and a healthy review process.
Long PR pickup time, on the other hand, is frustrating. Code with a long delay between PR creation and review was just sitting there when it could have been adding value to your customers.
What causes high PR pickup time?
- The team doesn’t know that the PR exists. PRs can easily go unnoticed or be forgotten. For example, a developer might not assign the PR to anyone, or the reviewer may forget about the request due to other work they have.
- The team is too busy. Developers have enough work they need to get done. Sometimes it’s challenging to find the time to do reviews, and developers put them off due to other priorities.
- The PR is too big. A big PR suggests lots of changes and complexity. Reviewers know it will take a lot of time, so they keep putting it off until they have a block of interrupted time to work through it. Unfortunately, this can mean a PR is being pushed forward for weeks.
How to reduce PR pickup time?
- Use automated notifications to inform developers about PRs they need to review.
- Monitor the amount of work each team member has taken. Of course, you should split the work equitably among team members, and no one should be overworking. This helps ensure everyone has time to perform reviews and optimizes overall development speed.
- Reduce PRs and keep them small so that developers can review them quickly. PRs that developers can check at a glance can have near-immediate pickup times, while bigger PRs can take days or weeks to get picked up.
What is PR review time?
Before merging a PR into the source code, you need to review it to find issues and ensure that it follows your team’s coding style and standards. A developer starts a review, but they’re then pulled into another task and forget about the review altogether. As a result, the code just sits there, doing nothing.
PR review time measures the time it takes to complete a code review and get a PR merged. Low PR review time represents strong teamwork and a healthy review process.
What causes a high PR review time?
- The PR is too big. Developers are reluctant to review big PRs, even after they have started since big PRs mean many code changes. Keeping track of all these different kinds of changes makes it harder to conduct effective code reviews.
- Too few people are assigned to do reviews. To maintain high-quality code, some teams limit the number of people who can review PRs, usually to the more senior developers. This is well-intentioned but can result in massive bottlenecks, with review requests piling up on just a few people.
- The team gets diverted into other work. Developers deprioritize reviews in favor of different work. If they discover a bug or receive a request for a high-priority feature appears, reviews get pushed back.
- The team forgets about the review. When developers start a review but then need to jump to another task, they commonly fail to come back to the review. A review can be “in progress” for days or weeks if there is no notification mechanism.
How to reduce PR review time?
- Commit small, commit often. The more precisely you scope a PR, the easier it is to review and the faster it can get into production.
- Use the logic of pair programming in code reviews with senior and junior developers. This will help everyone broaden their knowledge of the code base, and the reviews will serve as learning tools where more junior developers can improve their skills.
- Make sure your team understands the importance of code reviews and that they have enough time to perform them.
- Schedule automatic notifications to remind developers when they started working on a PR review but haven’t finished it after a couple of days.
What is deployment time?
You’ve written new code and created a PR, which is picked up and reviewed. You respond to comments, update the PR, and the PR gets approval to merge into production. But code still has to go through testing. Maybe your organization merges new code in batches every couple of days, or your team has been putting out fires, so they’re not releasing new code into production.
Deployment time measures the time from when a branch is merged to when the code is released. Low deployment time correlates to high deployment frequency.
The longer it takes to deploy the code, the longer it will take you to retry failed deployments, recover from outages, and provide value to your customers.
What causes high deployment time?
- Personnel bottlenecks. To ensure that high-quality code gets merged into production, some teams only allow some developers to merge PRs. This is well-intentioned, but senior developers tend to get overburdened since they are more knowledgeable.
- Inefficient testing. Your test suite should be robust, comprehensive, and fast, so you can spend time writing code, not waiting for the tests to complete.
- Code changes are too big. Big tasks and PRs lengthen the coding time and discourage people from reviewing them because it takes a long time. They also cause long deployment time: they’re more likely to create bugs, so developers put off merging them.
How to reduce deployment time?
- If a team member has taken on too much work, you must better distribute responsibilities within the team.
- Create a fast and efficient testing suite.
- Commit small. Small changes are much easier to understand; thus, pushing them live is much less scary.
Conclusion
There are hundreds of ways to reduce cycle time, and this article does not provide a comprehensive list. However, it can help you get started.
If you’re looking for a solution to measure the DORA metrics, Codacy quality is the way to go.
