Skip to main content
Time to Merge
Updated over a year ago

What is Time to Merge?

Time to Merge measures how long your team takes to create, review and merge a Pull Request (PR) to a single branch.


Why Time to Merge matters

We measure Time to Merge because code reviews can often get blocked, impacting how fast you can ship your product to your customers (an additional insight that can be gleaned from viewing your team’s Cycle Time).

Optimising Time to Merge will improve the time it takes your team to deliver value to your customers, as well as improve the quality of the value you deliver. When done well, the code commits and their attached messages within a PR tell a story to people examining code at a later date, improving the maintainability and serviceability of the code base.


What ‘good’ Time to Merge looks like

Mature Time to Merge practice looks like developers reviewing and merging PRs on the same day they were opened.

This is enabled by the author’s discipline to create small pull requests, constructed with titles that are self-explanatory and descriptions that provide strong context and reason behind what outcome the code is meant to achieve. These practices go a long way in minimising the need for peers to add comments or tasks, and ask for further information to help with their understanding. Speeding up the review workflow by not blocking peers and being able to merge code sooner goes a long way toward building your team’s delivery success.


How Umano measures Time to Merge

For each Pull Request merged during the given interval, Umano measures Time to Merge by observing the time from when the Pull Request was created to the time when it was merged into a single branch.


Practices that influence Time to Merge

  • Number of comments on a PR

  • Number of tasks on a PR

  • Size of the PR

  • Number of issues addressed in a PR

  • Number of time a PR has reviewed (approvals)

  • Time to first review

What’s included?

Each model looks and specific activities within the tools. Below is a list of activities that contribute to Time to Merge and activities that do not have an impact on this metric.

Included

Not included

All Pull Requests in selected repositories.

All declined or open PRs that are not merged.

Tips for improving Time to Merge

  • Describe your changes well within each commit

  • Ensure the commit history is excellent, that good changes are made quickly, that the code review is performed and that it is understood what is being changed from the perspective of someone examining code in the future.

  • Encourage a culture where all team members can share in the responsibility of being a reviewer and be proactive in picking up a PR for review

  • Ensure there is a balance between your team’s speed and ensuring the quality of your team’s review, a balance best discussed in your team’s stand-ups or retrospectives

Resources

  1. Dias, H., The anatomy of a perfect pull request, 2018, <The anatomy of a perfect pull request >

  2. Osepchuk, B., Optimal pull request size, 2017, <https://smallbusinessprogramming.com/optimal-pull-request-size/>

  3. Riosa, B. The (written) unwritten guide to pull requests, 2016, <The (written) unwritten guide to pull requests - Work Life by Atlassian >

  4. Dias, H., The anatomy of a perfect pull request, 2018, <https://opensource.com/article/18/6/anatomy-perfect-pull-request>

  5. Hewa, G., How Big is Your Pull Request?, 2017, <https://hackernoon.com/how-big-is-your-pr-32c4d67ad76c>

  6. Yu, Y., Wang, H., Filkov, V., Devanbu, P. and Vasilescu, B., 2015, May. Wait for it: Determinants of pull request evaluation latency on GitHub. In Mining software repositories (MSR), 2015 IEEE/ACM 12th working conference on (pp. 367-371). IEEE.

Related Articles

Did this answer your question?