Cycle Time Breakdown

Cycle time is one of the key metrics that can reflect many details regarding the process that includes from coding to deployment. 

Cycle time breakdown presents the timing of different steps of the issues the team has worked on. 

The issues without any action are not included in the calculation. When the issue status is updated after it is in the done state, the cycle time value will also be updated. Additionally, the time spent on defining requirements or design processes is not included in the active calculation.

The cycle time steps are represented as;

• Coding
• Pickup
• Review
• Deploy

Each of these steps represents a different part of the deployment process. The details are provided in the below section.

Coding

Coding is the time either from issue status change or from the first commit to the pull request is opened. 

This differentiation is provided as a configuration. If an issue repository is integrated and this option is selected, the time measured from the status change of the PR-associated issue to the opening of the PR.

We strongly advise you to keep constant track of the coding value. In case of any increase observed in coding time, there would be preventable causes that can be solved by simple actions to reduce the time lost in this period.

Possible Causes and Related Actions

Tasks Require a High Number of Code Changes

In some cases, after the product team analysis, the task opened may contain changes in different, unrelated parts of the product. In this case, the complexity would be quite high for the developer.

Identifying the issue or feature to be divided into smaller issues can help developers to reduce complexity and eliminate the time lost in the coding phase.

Unclear or Missing Task Specifications

In case of failure in the task analysis process, the development may start without possible scenarios addressed or corner cases identified. In this case, the developer may be subject to additional challenges after starting the development cycle.

The issue analysis should be encouraged to cover all the related cases correctly and the issue should be delivered to the development team with maximum clarity. 

Complex Code for Refactoring

Code refactoring can be much more difficult to write the same code from scratch. Unclear, high-difficulty rated codes can bring additional challenges to the developer, increasing the time spent on the coding phase.

To overcome this challenge, developers can be paired as one of them being experienced in the code base to explain and clear the refactor details. Additionally, adopting one of the best practices such as providing clear comments on the code phase or detailed documentation would also help the developers who are working on issues requiring code refactoring.

Multiple Active Tasks/Projects

It is highly possible that developers who are working actively on multiple tasks or projects will experience time lost while switching between tasks and projects. 

Since keeping the focus on a single task will improve productivity, carefully planning the developer task assignments and serializing the task for developers would be the best practice to minimize the time lost in coding.

Pickup

Pickup is the time from the pull request is opened to the first commit that is issued. 

This is one of the key parts to affect the cycle time. Since it requires drawing the attention of the reviewers, it is one of the major reasons for the latency in the deployment cycle.

This metric can reflect teamwork and synchronization between team members. If the pickup value is high, raising awareness on this part will play a major role in a more efficient process.

There could be preventable reasons for a pickup time to be high. The possible reasons are presented in the section below;

Possible Causes and Related Actions

Synchronization is Missing

If the reviewers are not aware that the pull request is issued, it will take longer to realize a pull request is open and focus on the corresponding pull request.

Automatized channels such as triggered emails or chat program notifications can be utilized to notify reviewers automatically from multiple channels.

Team Members Have a High Workload

When the team is focused more than they should actively be working, even if the notification flows are in place, it may not be possible for the team to respond promptly.

Valven Atlas offers workload analysis to identify the issues the team currently working on and the distribution of works team members are focusing on. Planning the work evenly and correctly would eliminate overloading your team and help them to give better responses to open pull requests.

Pull Requests with High Complexity

When pull requests are complex and bigger than standards, the reviewer may lose time evaluating the pull request. 

As a best practice, distributing the work into smaller parts will result in better coding and better review processes. 

Review

The review metric shows the time from the pull request’s first review to its merge. It is a demonstration of the review process so this metric should be followed carefully to understand how well the process works.

The total review time is a combination of pickup and review so the reasons for the high review time and precautions are the same as mentioned in the pickup section.

In case any comments or requests for a code change in the review phase will result in returning back to the coding phase and after the coding, it will proceed to the review phase through pickup.

Since the code that will be included in the production requires multiple team members from different roles to align, there will be back-and-forth discussions and change requests. Therefore, reducing the latencies in these processes will have a more significant impact over time.

Deploy

The deploy section highlights the time spent from the code being ready to be deployed in production where the customer can use the related feature.

Deployment time also includes testing so testing actions and issues detected in the test process can result in returning to the coding phase and revisiting the deploy section after passing through pickup and review again. 

To be able to measure the deployment time correctly, additional integration to CI/CD tools is required. However, alternative approaches are also offered either direct Git repository integrations or issue repository integrations.

Without CI/CD integration, you can define a branch containing a specific pattern, a word like 'release' and Valven Atlas assumes that when a merge applies to this specific branch, the deployment is completed and measures the time to deploy.

Another approach is to create an issue in the repository which is again associated with the specific release. When this release is completed, Valven Atlas will mark that this release has been published and measure the deployment time accordingly.