The Pull requests cycle time breakdown graph measures the time interval between the first commit on the branch (programming) and the deployment. Thus, the indicator associated with this metric (upper right corner) reflects the average total cycle time over the entire duration considered.
Essentially, code reviews go through three phases:
- Coding
- Pickup
- Review
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).
Example of use
The following graph shows the cycle time distribution for the selected period, i.e. the last three months, and displays the data by sprint. You can also display the data by day or month, depending on your preference.
In addition, the indicator associated with each stage of the cycle time will show the percentage increase (red arrow) or decrease (green arrow) in the time allocated to that stage.
- The Coding phase reflects the time from the first commit to the moment the pull request is issued or opened. For example, 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".
- The Pickup phase is the time from where the pull request is opened to the first interaction (e.g., comment, reaction, thumbs up). 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.
-
-
- The Review phase represents the time from the first interaction (e.g., comment, reaction, thumbs up) to when the pull request is merged. 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.
Want to add deployment time to your observations? Check out the Lead time for change graph instead.
To learn more about the variation indicator and its calculation, check out this article!