The Pull requests cycle time breakdown graph measures the time interval between the first commit on the branch (programming) and its merge in preparation for deployment. Depending on your preference, you can view this data by day, week, month, or sprint. However, note that if a Kanban-type board has been linked to your Axify project, the "sprint" option will not be available in the filters at the top of the page. In addition, the periods "last 6 months" and "last year" do not allow the display by day.
Psst! Be careful not to confuse this graph with the one that has a similar name available in the Process Axis since they do not use the same data (different sources for the two axes). In addition, if you want to get more visibility on the deployment portion of the cycle, both in terms of time and number of deployments, we invite you to set up a webhook and check out the DORA metrics.
Reading the graph
For the following graph, the period displayed corresponds to the last 3 months and the display mode is by week. We can see that the average cycle time of a PR is 20 hours for this team. We can also see the time breakdown according to the 3 phases involved.
- The Coding phase, referring to the time from the first commit to the moment the pull request is issued or opened.
- The Pickup phase, showing the time from where the pull request is opened to the first interaction (e.g., comment, reaction, thumbs up).
- And the Review phase, which represents the time from the first interaction (e.g., comment, reaction, thumbs up) to when the pull request is merged.
The goal here is to identify the blockers in your delivery flow at the PR level. By paying attention to various elements, such as the time spent at each stage of the cycle, the pull request size, or the work in progress, the team will be able to address the potential blockers and reduce its cycle time.
For this team, we can see an improvement in cycle time, both globally and for each phase, thanks to the variation indicators. These indicators, in green for our example, compare the average time (for the entire cycle time as well as each stage) of the current period to that of the previous period. To learn more about the variation indicator and its calculation, check out this article!
Calculating the metric
Overall, we consider the first commit to be the start of each PR's cycle time, while the time the PR is merged marks the end of the cycle time. The indicator visible in the upper right corner of the graph (20 hours for our example) is meant to be an average of the cycle time of each merged PR for the selected period.
The same calculation is then applied to each phase, following the logic presented in the section Reading the graph above.
Particularities of each phase.
Coding: If the code review is opened before the 1st commit, the programming phase will be considered at 0.
In the case of GitLab, the time spent between drafting a pull request and the moment it is made ready is accumulated in the "coding" phase. If a pull request is drafted but never made ready, the entire lifecycle of the pull request until it is integrated will be considered "coding".
- In the case of GitLab, the time spent between drafting a pull request and the moment it is made ready is accumulated in the "coding" phase. If a pull request is drafted but never made ready, the entire lifecycle of the pull request until it is integrated will be considered "coding".
Pickup: This phase begins with the first revision, including from the author of the merge request. If there is no revision, the merge date of the pull request is used to mark the end of this phase. This phase is crucial as it may reflect a bottleneck in your flow, like idle or stuck pull requests.
In GitLab's case, a review takes the form of an interaction made on the code review such as a comment, approval, or emojis. In the case of GitHub, this revision takes the form of the first review made on the code review.
The first review considered must have occurred in the ready state of the pull request in question.
Any time the pull request is in draft is not considered in the pickup phase.
Review: If no revision is performed on the code review, this phase will have a cycle time of 0.
- In GitLab's case, the start of the review phase corresponds to the addition of a revision on a pull request in the ready state. If the first revision occurs while the pull request is in draft, it will not be considered the start of the review phase. Any time the pull request is in draft is not considered in the review phase.