Cycle Time
Last updated
Last updated
The cycle time is the average duration that Pull requests spend in different stages of the pipeline, including "Coding," "Pickup," "Review," and "Merge."
This typo metric helps in analyzing your PR workflows & is generated using your Git data.
Typo considers all the merged Pull Requests for the main/master/production branch for the selected time range and calculates the average time spent by each Pull Request in every stage of the pipeline. As a default, 24-hour day & 7-day work week are considered in all calculations. These can be customized as per your processes.
No open/draft Pull Requests are considered in this calculation.
Click here to learn more about Cycle Time configuration
The "Coding" stage (indicated in red in the screenshot below) represents the time taken by developers to write and complete the code changes.
For all the merged PRs, Typo calculates the average time between the first commit of that Pull Request to that Pull Request being raised for review. In the case of squashed commits (that merge earlier commits), the last available commit associated with the Pull Request is considered to be the first commit - this might impact the actual Coding Time.
The "Pickup" stage (indicated in green in the screenshot below) denotes the time spent before a pull request is assigned for review.
For all the merged PRs, Typo calculates the average time between the Pull Request being raised for review to the first review comment being posted on it. In case a Pull Request is approved or merged without any comments, the Pickup Time will be considered as ‘0’ for all such Pull Requests.
The "Review" stage (indicated in yellow in the screenshot below) encompasses the time taken for peer review and feedback on the pull request.
For all the merged PRs, Typo calculates the average time between the first review comment on a Pull Request and the time it is approved. In case a Pull Request does not have a review comment, the Review Time will be calculated from the time that the Pull Request was raised for review. In case a Pull Request has been merged without review approval, the Review Time will be considered as ‘0’ for all such Pull Requests.
Finally, the "Merge" stage (indicated in blue in the screenshot below) shows the duration from the approval of the pull request to its integration into the main codebase.
For all the merged PRs, Typo calculates the average time between the approval of the Pull Requests and the time they are merged to the main/master/production branch. The final merge branch to be considered is configurable & can be set as per your processes. In case a Pull Request is merged without review approval, the Merge Time will be calculated from the first review comment on that Pull Request. In case a merged Pull Request does not have any review comments and approval, the Merge Time will be calculated from the time that the Pull Request was raised for review.
Measuring cycle time can provide valuable insights into the efficiency and effectiveness of an engineering team's development process. These insights can help identify bottlenecks, streamline workflows, and improve overall productivity. Here are some specific insights that can be gained from measuring cycle time and how they can be used to improve engineering team efficiency:
Identifying Bottlenecks: By measuring cycle time for individual tasks or user stories, you can identify stages in the development process where work tends to get stuck or delayed. This helps you pinpoint bottlenecks and areas that require attention or process improvement.
Process Efficiency: Cycle time can indicate the overall efficiency of your development process. Shorter cycle times generally indicate a streamlined and efficient workflow.
Team Productivity: Cycle time data for individual team members provide insights into their productivity and can be used for performance evaluations.
Process Standardization: Tracking cycle time across multiple projects or teams allows for process standardization and best practice identification.
By leveraging the insights gained from measuring cycle time, engineering teams can continually optimize their development processes, reduce inefficiencies, and improve overall team efficiency and productivity. Regularly tracking cycle time and using it as a performance indicator can lead to a data-driven approach for continuous improvement and better software delivery outcomes.
Benchmarking cycle time will help you implement the best industry practice and improve your team’s performance & processes. You will also see the steps to improve your cycle time by clicking on “What to do if your coding time is high?”
When you click on deep-dive, you will land on the PR (Pull Request) section which will provide you with the details of your PR which impacts your cycle time. You can read more about the PR view & resolution here.
