#All #Project management #Task Management #Document management #Reporting #Analytics #Integration #monday #How To #AI #News #Confluence Tutorial #Confluence #Jira #Bitbucket #Case Study #Learning Management #Collaboration

Pull Request Analytics: How to Get Pull Request Cycle Time / Lead Time for Bitbucket

May 2, 2024

#How To#Bitbucket#Reporting

14 min

In this article, we’ll describe two ways to get pull request Cycle Time / Lead Time for Bitbucket Data Center using the Awesome Graphs for Bitbucket app.

What Pull Request Cycle Time is and why it is important

Pull Request Cycle Time / Lead Time is a powerful metric to look at while evaluating the engineering teams’ productivity. It helps track the development process from the first moment the code was written in a developer’s IDE and up to the time it’s deployed to production.

Please note that we define Cycle Time / Lead Time as the time between the developer’s first commit and the time it’s merged and will refer to it as Cycle Time throughout the article.

The Cycle Time is commonly composed of four metrics:

Time to open (from the first commit to open)
Pickup time (from open to the first non-author comment)
Review time (from the first comment to approval)
Time to resolve (from approved to merge or decline)

With this information, you can get an unbiased view of the engineering department’s speed and capacity and find the points to drive improvement. It can also be an indicator of business success, as controlling the pull request Cycle Time can increase output and efficiency and deliver products faster.

How to find Cycle Time in Bitbucket

Using Awesome Graphs for Bitbucket, you can track the average Cycle Time of pull requests at the project and repository levels. Additionally, you can find the specific Cycle Time of a single pull request.

For each Bitbucket project and repository, the app displays the average time it takes to resolve pull requests as well as the breakdown of the average time by stage. You can also configure the report to see the average Cycle Time of a particular team or user in a chosen project or repo.

Below the report, you can find the list of all pull requests included in it, along with their Cycle Time.

Clicking on a value in the Cycle Time column against a particular pull request allows you to see the breakdown of the Cycle Time and analyze each metric.

How to export Time to Open, Time to Review, Time to Approve, and Time to Merge metrics

Another way to track Cycle Time is to export pull request data from Bitbucket and build a custom report. You can get all the necessary statistics from the Awesome Graphs for Bitbucket app in two different ways: via REST API and into a CSV file from Bitbucket UI.

Export Cycle Time data from Bitbucket UI

Using Awesome Graphs, you can obtain data directly from Bitbucket. Here is an example of a file you’ll get:

To get this report, go to the People page and select All users from the People dropdown menu in the header.

By default, you’ll see an overview of developers’ activity based on the number of commits. To check pull request contributions, select pull requests as the activity type in the configuration. It not only filters the data visible on the GUI but also determines what is exported, ensuring you receive a CSV file containing the needed data. To export pull requests, choose the Export menu at the top-right corner of the page and select CSV.

Get Time to Open, Pickup time, Review time, and Time to resolve via REST API

Another option to get Cycle Time metrics from Bitbucket is to use Awesome Graphs REST API. It allows exporting pull request statistics on user, repository, project, and global levels in JSON format as well as in a preformatted CSV file.

To find all available REST API resources, visit our documentation website or select REST API from the Export menu at the top-right corner of the People page in Bitbucket.

To retrieve Cycle time and its four phases in JSON format, simply add the withCycleTime=true parameter to any Get pull requests resources.

Here is an example of a curl request to export pull requests of a specific repository:

curl -X GET -u username:password "https://%bitbucket-host%/rest/awesome-graphs-api/latest/projects/{projectKey}/repos/{repositorySlug}/pull-requests?withCycleTime=true"

While exporting to a CSV file, you don’t need to add extra parameters to get pull requests Cycle time. An example of a curl request to retrieve data on a user level will be as follows:

curl -X GET -u username:password "https://%bitbucket-host%/rest/awesome-graphs-api/latest/users/{userSlug}/pull-requests/export/csv"

After running the request, the report you’ll get will look the same as the one we showed above, explaining how to export directly from Bitbucket UI. By default, it exports the data for the last 30 days. However, you can set a timeframe for exported data up to one year with sinceDate / untilDate parameters.

How to build a Cycle Time report

After you generated a CSV file, you can process it in analytics tools such as Tableau, PowerBI, Qlik, Looker, visualize this data on your Confluence pages with the Table Filter, Charts & Spreadsheets for Confluence app, or integrate it in any custom solution of your choice for further analysis.

An example of the data visualized with Table Filter, Charts & Spreadsheets for Confluence.

In this article, you will find more details on how to build a Cycle Time report in Confluence using the Table Filter, Charts & Spreadsheets for Confluence app.

By measuring Cycle Time, you can:

See objectively whether the development process is getting faster or slower.
Analyze the correlation of the specific metrics with the overall cycle time.
Compare the results of the particular teams and users within the organization or across the industry.

With Awesome Graphs for Bitbucket, you can gain more visibility into the development process and facilitate project management. Using the app as a data provider tool will help build tailored reports and address your particular needs. Plus, exclusively for our Data Center clients, we now offer a Premium Support subscription where our technical team having in-depth knowledge of Bitbucket data is on hand to write custom scripts and swiftly resolve your specific use cases.

Feel free to contact us if you’d like to discover whether our app can address your specific needs.

Pull Request Analytics: How to Visualize Cycle Time / Lead Time and Get Insights for Improvement

March 30, 2021

#Reporting#How To#Bitbucket

12 min

Cycle Time / Lead Time is one of the most important metrics for software development. It can tell a lot about the efficiency of the development process and the teams’ speed and capacity. In the previous article, we showed you how to get a detailed report with the pull request statistics and Cycle Time / Lead Time calculated on the repository level.

Today we’ll tell you how to use this report:

How to visualize the pull request data.
What things to pay attention to.
What insights you can get to improve performance.

Please note that we define Cycle Time / Lead Time as the time between the developer’s first commit and the time it’s merged and will refer to it as Cycle Time throughout the article.

Analyzing your codebase

First, you need to understand the current state of affairs and how it compares to the industry standards. According to the Code Climate’s research, the industry-wide median for Cycle Time is 3.4 days, with only the top 25% managing to keep it as low as 1.8 days and the bottom 25% having a Cycle Time of 6.2 days.

© Code Climate

To get a better understanding of the development process, it might be helpful to look at the teams’ dynamics and monitor the changes over time. The following chart shows how the average Cycle Time changes month after month with a trend line, so you can see objectively whether the development process is getting faster or slower and check how your rates compare to the industry average. Follow the instructions to build this chart.

For a more precise analysis and evaluation of the current code base, you can also use the Cycle Time distribution chart that provides pull request statistics aggregated by their Cycle time value, making it easy to spot the outliers for further investigation. Learn how to build this chart.

In addition to the Cycle Time, Awesome Graphs for Bitbucket lets you analyze the pull request resolution time out-of-the-box. Using the Resolution Time Distribution report, you can see how long it takes pull requests to merge or decline, find the shortest and longest pull requests, and predict the resolution time of future pull requests with the historical data.

While Cycle Time serves as a great indicator of success and, keeping it low, you can increase the output and efficiency of your teams, it’s not diagnostic by itself and can’t really tell what you are doing right or wrong. To understand why it is high or low, you’ll need to dig deeper into the metrics it consists of. The chart below gives you a general overview of the pull requests on the repository level and shows the Cycle Time with the percentage of the stages it’s comprised of (which we’ll discuss in detail in the following paragraphs). You can build a chart like this using the Chart from Table macro, available in the Table Filter and Charts app.

Breaking down the Cycle Time

We break down Cycle Time into four stages:

Time to open (from the first commit to open)
Time waiting for review (from open to the first comment)
Time to approve (from the first comment to approved)
Time to merge (from approved to merge)

Now we’ll go through each of these stages, discussing the things to pay attention to.

Time to Open

This metric is arguably the most important of all, as it influences all the later stages and, according to the research, pull requests that open faster tend to merge faster.

Long Time to Open might indicate that the developer had to switch tasks and/or that code was rewritten, which might also result in large batch sizes. In one of the previous articles, we described how you can check the size of your pull requests in Bitbucket, so you can also use it for a deeper analysis.

One of the things you can do to improve your Time to Open is to decrease the pull request size to be no more than 200 to 400 lines of code. Thus you’ll influence each stage of the cycle, as the smaller pull requests are more likely to be reviewed more thoroughly and be approved sooner.

Time to Review

Time to Review is a great metric to understand if your teams adopted Code Review as part of the daily routine. If it’s high, then it might not be part of their habit, and you’ll need to foster this culture. Another reason might be that the pull requests are not review-friendly and the reviewers procrastinate dealing with them. You can change this, once again, by keeping the pull request size small and by writing a reasonable description so it’s easier to get started with them. If the long Time to Review rate is caused by organizational issues, then it might require reprioritization.

Time to Approve

This is the stage you don’t really want to minimize but rather make it consistent by reducing inefficiencies in the code review process. While there are many strategies for Code Review, there is hardly any industry standard for Code Review metrics, so you’ll need to focus on the organization of the process and try to find a way to get constructive feedback.

Time to Merge

Long Time to Merge might be an indicator that there are obstacles in the delivery workflow. To improve it, you need to find out if there are any blockers in the process, including manual deployment, and check if your tooling satisfies your current needs.

Wrapping up

Cycle Time’s importance is difficult to overestimate, as this metric can tell a lot about the way you work, and controlling it, you can optimize the development process and deliver faster.

Once again, we built the initial pull request report with the help of the Awesome Graphs for Bitbucket app as a data provider and used the Table Filter and Charts for Confluence app to aggregate and visualize the data.

These are just a few examples, but you can get much more even from this one report. Check out the other guides for charts based on data from Bitbucket. Share your feedback and ideas in the comments, and we’ll try to cover them in future posts.