Cycle Time Breakdown

Cycle time is one of the key metrics for understanding how efficiently work moves through the software delivery process, from coding to deployment.

The Cycle Time Breakdown shows the time spent across different stages of the issues completed by the team. Only issues with recorded activity are included in the calculation.

Cycle time is attributed to the period in which an issue is completed, based on its closed date. Once an issue is closed, its cycle time is reflected in that period, providing a consistent view of completed work and preventing later issue updates from shifting results across reporting periods.

Time spent on requirement definition or design activities is not included in the active cycle time 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 time is measured from the first commit until the pull request becomes ready for review (either when it is opened or when it transitions from draft to ready).

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 contributor.

Identifying the issue or feature to be divided into smaller issues can help contributors 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 contributor 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 contributor, increasing the time spent on the coding phase.

To overcome this challenge, contributors 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 contributors who are working on issues requiring code refactoring.

Multiple Active Tasks/Projects

It is highly possible that contributors 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 contributor task assignments and serializing the task for contributors would be the best practice to minimize the time lost in coding.

Pickup

Pickup is the time from the pull request is ready for review to the first review action. 

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 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.

During the review phase, reviewers may leave comments and request code changes, which can require additional development work before the pull request is ready to proceed. These iterations are a natural part of the review process and may extend the overall review duration. However, this does not result in the elapsed review period being reclassified as coding time.

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 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 will mark that this release has been published and measure the deployment time accordingly.