Why should you measure your pull requests?
Tags: Pull Request, Github, SaaS, Tech, Slack

Measure your pull requests

Pull requests help developers to notify their peers that they have finished a particular piece of work, it could be a feature or a fix. This gives a chance to share your work and get feedback. It builds a context for the whole team that helps them understand what the other one is working on. I have seen some engineering teams that are very rigid with their code review processes and are very skeptical about it. They don’t want to push something to production which is not reviewed or understood correctly.

A typical software delivery pipeline would include the following steps :

Requirement analysis

Design

Development

Testing

Deployment

However, I have noticed that code review is also an important step in the process and is often included after development is complete or testing is on going.

Having said that, if code review’s are delayed, your release cycles would also get delayed. Often, engineering managers are in a dilemma. They are not too sure what is clogging their code review cycles. It could be that your pull requests are way too long to be reviewed in a short span of time, or may be their are long open discussions, or may be your team is not quite serious about open pull requests. Reasons could be many, but this explains that your team is not in sync.

The point that needs to be understood is that code reviews require a collective effort, it’s not one person’s job. The whole team needs to be in sync in order to make sure that your review cycles are functioning smoothly. Now in order to understand what is exactly clogging your review cycles, you need to dig a little deeper and understand your team’s dynamics. Basically, you need to start driving insights and measure your pull request metrics.

What are Pull Request Metrics?

Well, metrics in general are numbers that tell you important information about a process under question. They tell you accurate measurements about how the process is functioning and provides a base for you to suggest improvements. With the same analogy, Pull Request Metrics help you to understand your software engineering teams dynamics. Using a couple of metrics together you can measure the effectiveness of the process. Have your releases been delayed because of long lying open pull requests? Why do you think your team is not able to squash those pull requests in time? Why are those pull requests not able to seek attention of your team? Why ….? Why and Why?

Let’s take a look at two pull request metrics:

Lead Time : The lead time metric tells you on an average how many days pull requests take to be merged or closed.

: The lead time metric tells you on an average how many days pull requests take to be merged or closed. Flow Ratio : It is the ratio of sum of pull requests opened in a day with respect to the sum of pull requests closed in that same day. This metric tells you whether your team works in a healthy proportion.

Using the above two metrics collectively you could spot trends and behaviours effectively.

This would initiate the process of measuring your pull requests. Access to such metrics would help you to understand where exactly the problem lies so that you can take actionable steps.

CodeKickBot is a GitHub and Slack integration that helps you to drive insights from your pull requests right within your workspace. It makes collaboration on pull requests easy and fun!