PR Cycle Time

PR Cycle Time

Understand the flow of a PR from commit to merge

PR Cycle time measures the median time your Pull Requests are in three different stages: Dev, Waiting, and Review. 

Phase 1: Dev

The first phase looks at how long the particular PR was in development. However, there are different lenses to look at software development. Some leaders prefer to see how quickly a commit makes it to the main branch (First Commit), others want to capture the time spent in doing development by looking at when work actually started, using Jira data (First Activity). In the Build page, this choice can be changed to explore the other option.



Info
Definitions:
First Commit to PR
Uplevel looks at the time period from the first commit to when the PR is submitted for review. If a PR is opened immediately after the first commit, your First Commit to PR time will be shown as 0 hours. If a PR is opened as a draft or work in progress, then this phase will end when it is converted to be ready for review.

First Activity to PR
To determine the first activity, Uplevel looks at linked Jira/ADO issues, it then looks for the first time that a linked issue moved to an "In Progress" state. Uplevel then chooses the first time this occurred, or the first commit - whichever came first. This phase is then the duration of time from the First Activity until the PR is submitted for review.  If a PR is opened as a draft or work in progress, then this phase will end when it is converted to be ready for review.

Phase 2: Waiting

The Waiting phase looks at how long a PR is waiting for a review. It captures the time from when the PR is opened (or converted from a draft) to the first action (e.g., commenting, request for changes, approval) from a reviewer. Keep an eye out for this section — it's common to see bottlenecks here.

Phase 3: Review

Review captures the time from the first review action from a reviewer to the time the PR is merged. If there is a lot of back and forth, this phase could be longer and might be an area to look into.

Start Time Configuration

Uplevel can now leverage Issue information to determine when development on a PR truly began. This is done by allowing users to select how to start calculating Cycle Time: by First Commit or by First Activity.

Which method should I use?
  • Choose First Activity if your team consistently links their PRs to Jira/ADO Issues, and tends to have a practice of keeping issue statuses in sync with reality. This will give a clear view into how long the coding and testing takes as part of the development process. 
  • Choose First Commit if your team doesn't consistently link PRs to issues or if the team has inconsistent hygiene and best practices around tickets. This selection will put all PRs on the same page regardless of behavior in Jira.
  • Note that the Wait and Review Phases are identical regardless of the selection.


Idea

Example Scenario:

Late Monday evening, a bug in production is detected. An issue gets created, triaged, and is assigned to a developer Tuesday morning at 9 AM during standup. The developer starts work and moves the ticket to "In Progress" at 10 AM, but isn't able to finish by end of day Tuesday. Development and testing continues on Wednesday morning until 11AM. The developer commits at 11:00 AM, pushes their local branch to Git and opens the PR at 11:05 AM and passes it off for review. It's ultimately approved and merged at noon Wednesday.

When using First Activity, the Cycle Time for this PR is 26 hours. This includes the 25 hours and 5 minutes spent in the development phase, and the 55 minutes spent in the review phase. This shows how long the work took from beginning to end including development

When using First Commit, the Cycle time for this PR is 1 hour, with just 5 minutes between first commit and the PR being opened. This shows that the review process was quite efficient with just 55 minutes from the PR being opened until when it was merged.


Opportunities 

 Uplevel captures a number of the most important contributing factors of PR Cycle Time as component metrics.

Each component metric has a benchmark based on Uplevel customer and industry data. When component metrics don't meet the benchmark, they are surfaced as opportunities: 

Opportunities are the first place you should focus when hoping to reduce your organization's PR Cycle Time and overall increase your effectiveness in this part of the software development lifecycle. 


Export Data

All the underlying data for PR Cycle time is available for export. Note that not all columns are available by default.
 

    • Related Articles

    • Lead Time for Changes

      How does Uplevel define Lead Time for Changes? The DORA metric Lead Time for Changes is measured as the median duration of time from first commit until the Pull Request is deployed to a production environment using CI/CD Data. This differs from Cycle ...

    • How to decrease your team's unallocated time

      Tips and best practices to get a more complete picture of your organization's investments in Time Allocation Uplevel's Time Allocation metric combines signals from calendar, chat, project tracking (Jira) and version control systems (git) to estimate ...

    • PR Throughput

      Learn about your organizations code delivery practices and how they've changed over time. What is PR Throughput? PR Throughput counts the number of merged PRs a group has collectively authored in a given time period. It is an indication of how ...

    • Time Allocation

      How does Uplevel calculate Time Allocation for my teams? What is Time Allocation? Time Allocation is a specific Uplevel insight that provides an automated, up-to-date breakdown of where your organization’s time and efforts are spent. As a pivotal ...

    • Epic Lead Time

      Understand the bottlenecks in your planning process by looking at your Epic Lead Time phases Overview Epic Lead Time is defined as the median epic duration, which is calculated as the difference in time from when the epic is created, through to when ...