The time frame between ‘First Commit‘ to ‘PR Issued‘. It will show the average time it takes for a single engineering task (usually mapped to a branch) to go from First Commit to PR Issued.
Coding time is one of the most interesting engineering execution metrics to track over time. Since you want your PR Sizes to be small and your deployment frequency to be high, you want to make sure coding time isn’t increasing by a significant margin. If your coding time does spike, that is likely an indicator of larger issues down the pipeline.
Time to merge refers to how long it takes for work to be merged, starting from the first commit.
A high time to merge value might be a red flag. It can indicate the organization’s software development pipeline isn’t as efficient as it could be. Alternatively, it could be a sign of poor communication in the organization. Engineers might be struggling to develop the features they need due to not knowing or understanding the customer’s requirements.
This statistic refers to the average time it takes for pull requests to be reviewed. The more time it takes for the team to review and merge pull requests, the longer it takes for them to reach production. A high PR waiting time can also increase the risk of merge and logical conflicts due to the increased isolation time of branches.
If you subscribe to the notion that code is a liability instead of an asset, the value of this statistic should be easy to grasp. In short, large changes are riskier than smaller ones. The more code you have, the more likely it becomes you have buggy, complex, or hard-to-read code.
Code rework refers to the portion of the code that gets rewritten too often and too soon after first being merged. Though not necessarily a problem, it might be a sign that something isn’t quite right. It might mean the developers are struggling, generally due to a lack of skill, domain knowledge, or experience with the tech stack the organization favors.
A high level of code rework might also indicate problems in the codebase itself, such as poor architectural decisions, not adhering to coding best practices—such as the SOLID principles, particularly the OCP—or miscommunication with the customers, resulting in poorly understood requirements.
Review depth here means the average number of comments found in pull request reviews. By tracking and analyzing this number, you can get a sense of how deep and well thought out the reviews are inside your organization.
Speaking of reviews, sometimes pull requests might be merged without a review. There might be justifiable reasons for that happening, but it should be the exception rather than the norm. Analyzing this metric might indicate the source of quality problems. Especially if you look at it along with other metrics on the list.
For instance, by looking at previous statistics, you might notice that the ratio of PRs without review increased just after a spike in the PR review waiting time. With that knowledge, you might want to investigate ways in which you can improve the PR waiting time. This will not only guarantee the PRs get to production sooner but also reduce the number of PRs that get merged without review.