Merge request analytics
With the widespread adoption of git and git branching strategies, merge requests have become first-class citizens in our world of software development. The most widely used strategy is the git-flow branching strategy which most corporates and startups have adopted. Irrespective of the strategy that you follow if your development process heavily involves creating WIP / Draft merge requests, peer review, incorporating feedback, and reworking, this summary will help you to understand your process better and potentially even optimize it.
According to our study of different engineering teams, the most bottlenecked engineering process is the way a team handles merge requests. And why shouldn’t it be? There is so much intra-team dependency in the review and approval process of a code change. That is the exact reason why we wanted to delve deeper into this process and figure out small changes that make a significant impact on the team.
Why should you care about your merge requests?
Merge requests are a representation of a chunk of work that could be an entire feature or a small enhancement to your codebase, this piece of work goes through multiple iterations, which starts with the developer committing to develop new features and ends with a request being merged to the intended branch which would generally mark the completion of a task. Between these two events, a team spends a lot of time to ensure the changes are what is intended and potentially bug-free. Given a merge request covers these many aspects of your development process and merging one is a result of synchronized teamwork, it’s worth putting in the effort to understand what your process looks like and if there are scopes of improvement.
The cycle time of a merge request is an indicator of how long it took from the first commit in the merge request to when it was actually merged. This is an excellent summary of how long a team takes on average to develop, pick up, review and rework new features. This not only increases predictability within your team but if tracked over time also helps you be more efficient in these phases.
Cycle time and its stages
Cycle time — Time it takes from your first commit till when the merge request was merged.
A breakdown of this entire time period helps you understand which phase takes how much time and what can be improved.
Development time — How long it takes for the actual development effort, which is from your first commit till the merge request is created
Pick up time — The time taken from merge request creation to your first review comment
Review & Rework — The time period from your first review comment till when the merge request gets merged.
What do these stages represent and how can you drive action using them?
Development stage
The development stage is a representation of the amount of time taken to develop the changes in the merge request. Average development time is also a good metric to understand how long it takes for your team to develop a feature (if you follow feature level merge requests).
Another way to look at development time is as a percentage of the total time taken. Ideally, you would want to have this percent as high as possible, indicating there is absolutely no waiting time and rework effort going in for your development work. Realistically we have seen highly efficient engineering teams have 60–70% of their total time as development effort.
The team’s average development time of 3 days and 10 hours is around 70% of the overall average of 4 days and 21 hours which is excellent. There’s also a week-level graph and a details section (shown below), which could help you drill down into the why of the problems.
Pickup phase
Pickup time is one metric which is the easiest of all to drive action from. It’s a representation of how long merge requests are idle for, waiting for someone to start reviewing or approve it. Having this metric as low as possible would mean a highly efficient reviewing and merging process within the team.
The simplest way to drive action from this metric is to track it at an iteration level and ensure there’s a downward trajectory across a set of iterations.
In the same example, our average pickup time is 1 day 6 hours, which means a merge request on average is idle for a day, if we could better plan and arrange tasks, this number could be reduced over time.
An ideal graph would decrease over a few months and then plateau out as you reach towards a more optimized review process.
Review and rework phase
Review and rework phase indicates the effort on average that goes into correcting changes after the initial development phase. This is not only a representation of the amount of time it takes but also the percentage of effort that goes into rework.
Having the rework time as zero would have been ideal. Realistically we have found having this metric below 20% of your average cycle time is great and goes a long way to boost team productivity.
Some other metrics that supercharge your review and merge process
Throughput
Merging a merge request is an event that says work was developed reviewed and reworked to ensure the highest quality. And to know how many such iterations your team can do in a week, sprint or quarter is a great way to understand the efficiency of the team and get predictability on what your team can deliver.
On the platform, you can view it as an overall number along with trends across time.
Detail view
One of the key use cases we want to enable for engineering teams is that have a singular view of all merge requests that are open across your repositories and have all details of those requests available in a single view. For every merge request you can look at these details in a single view:
- Creator
- Approvals
- Jira tickets it is resolving (based on the commit messages / merge request description)
- Contributors (everyone who has made a code change for this merge request)
- Cycle time and its breakdown
- Number of reviews, along with who has reviewed a merge request
- Work segmentation in this merge request
- Amount of changes in this request (Impact)
- All the risks associated with a merge request
When using your existing git tools to look at your merge requests, having a singular view across a subset of repositories is not possible, we want to enable that along with getting all information relevant in a single place.
Merge request risks
We identify and track three different risks for every merge request.
- Long pending merge requests — For merge requests that have been open for a long time and need your attention to be merged.
- Risky merge requests — Flagging out merge requests that have a huge amount of changes so you can ensure these requests are double-checked to ensure correctness.
- Rubber stamping merge requests — Merge requests that were merged very quickly and potentially not reviewed correctly which could potentially mean buggy code in your systems.
These risks are relative in nature, meaning when you create your project with us we read your historical data and adapt these risks and the entire platform to your team dynamic. These risks can be viewed in the project risks dashboard and also in the detailed view mentioned above.
Creating your own dashboards
On all the above metrics you just saw, you can create your own views as well. The goal is to ensure you and your team track these metrics to improve your processes irrespective of whether it’s using one of our pre-built dashboards or you creating one for yourself. We also understand you would want to start with a few metrics and then over time iterate what you track. To enable this we have added all our merge request metrics and risks to our custom dashboard offering as well. Which enables you to create, save and share visualizations selectively for the metrics that matter to you.
How teams have benefitted from these metrics
Merge request analytics use case was defined and brainstormed along with our existing users, thus we have a good amount of practical use cases to share on how teams have used these metrics and how can you use them as well.
- A team has incorporated risky merge requests within their review process by ensuring every risky request has not 1 but 2 reviewers to ensure the code getting merged is on point.
- Pickup time was used by a team to set targets at a monthly level, wherein they wanted to ensure the pickup time is always less than 24 hours. Before tracking which was more than 35 hours, are now seeing a reduction of 30% in times when requests are practically stagnant.
- A team following agile, in their standups along with discussing the tickets they are working on, introduced this discussion of which open requests are being reviewed today and by whom using the open requests detail view.
- Having ticket numbers in commit messages is very common, but at a merge request level the team often missed putting in the right numbers, using the detailed view of all merge requests, they were able to enable the team to get this data.
- Review and rework along with churn of a merge request was used by a team to understand the amount of effort going into resolving things after initial development is done, these metrics are not necessarily negative for this team wherein they actually encourage this way of development where a code is committed and iteratively worked upon to ensure the highest quality.
Merge requests are a very important part of our development process, even the smallest improvement here can go a long way in improving the overall productivity of the team. At AnalyticsVerse, we believe in ‘optimizing processes over people’, and using these dashboards and metrics around your merging process you can efficiently achieve that.
If the only hesitation you are facing is you don’t know where to start improving, don’t worry we are here exactly to give you a headstart and evolve with you and your processes. You can start your free trial today here, or you can also schedule a no-commitment demo call by dropping a note at demo@analyticsverse.com
