Change Lead Time

‍What it is: This is DORA's Change Lead Time (previously called Lead Time in the app), a metric that shows how long it takes the team to write code, request and give feedback, make revisions, merge the PR, and then deploy into production. It’s an indicator of how long it takes to deliver value to customers.‍

Why it matters: Change Lead Time is one of the top four indicators of software team performance, according to Google’s DORA unit (the DevOps Research and Assessment unit). Their research shows that a faster Change Lead Time is correlated with better business outcomes. Specifically, teams with a faster Change Lead Time do work that is better, more stable, and more secure. If you want to dive deeper into this, check out the Accelerate book. Note that this is closely related to Cycle Time; we measure Change Lead Time since that's recommended by DORA.

How we calculate it: To calculate Change Lead Time, we measure the number of hours from the first new commit on a pull request’s (PR’s) branch to a successful attempt of deployment to production for that PR, or to PR merged if there is no deployment data.‍

Additional calculation notes for Change Lead Time & subsets

Here are a few additional notes that affect the calculations for Change Lead Time and/or its components, Coding Time, Review Wait Time, Editing Time and Deploy Time.

These exclusions apply to Coding Time, Review Wait Time, and Editing Time :

• Our focus is on PRs that the team collaborated on, so we exclude bot merges and selfie-merges (PRs merged by the PR author, with no comments or reviews by other collaborators).

• If you like, you can choose to exclude weekend hours from these calculation; simply toggle on “Exclude Weekend Hours”.

For just Change Lead Time and Coding Time, please note:

• When you first join Multitudes, your historical data (the first 6 weeks) will show a lower time metric if your company does a lot of rebasing. This is because we can’t get original commits from the historical data in GitHub, so the rebased commit is taken as the first commit.

• Once you integrate, we get events data from GitHub. This means we will get the original commits that are pushed to GitHub, even if your teams rebase or squash the commits later. Therefore, you might notice that your metrics are higher after the time that you onboard onto Multitudes, compared to your historical data.

For just the separate Deploy Time line chart:

• If you’re using the GitHub Actions integration…

  • We do include selfie PRs (non-collaborative PRs) in this metric.

  • This is because we want to provide the most comprehensive view of how long your deployment pipeline takes, which means incorporating all relevant data.

  • Whether a deploy is of a collaborative PR or a selfie PR, this should not normally influence how long the deploy takes, therefore selfie PRs are a relevant segment of your team’s data on how long things take to deploy.

• If you're using the Deployments API, we only look at what you POST, so you can decide how you want to treat selfie PRs

• For Change Lead Time we intentionally include all merged PRs, even if they are not yet deployed (or if deployment metrics aren’t available), so that you are getting insights across all repositories, even if some of them are not set up with GitHub Actions deploy pipelines or the Deployments API.

How Change Lead Time is broken into its subsets

Change Lead Time is broken up into its four components, Coding Time, Review Wait Time, Editing Time, and Deploy Time. Where these start and end can depend on the events in each PR's life cycle. Here is a typical PR timeline. Click the dropdown below it for more scenarios.

More PR life cycles scenarios

Scenario 1

Scenario 2

Scenario 3

Scenario 4