Change Lead Time
Last updated
Was this helpful?
Last updated
Was this helpful?
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.
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.
What good looks like
Google's DORA research shows that elite performers have a Change Lead Time of less than 24 hours.
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:
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.
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.
Why it matters: Change Lead Time is one of the top four indicators of software team performance, according to (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 book. Note that this is closely related to Cycle Time; we measure Change Lead Time since that's recommended by DORA.
This means some of the PRs included in this chart will not yet be deployed. This is so that you can get insights for all repositories, even ones that don’t have workflows configured. You can get a breakdown of how long PRs are taking to merge vs. deploy with the Change Lead Time subsets chart or the specific line charts (like .
If you’re using the …
If you're using the , 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 ), 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.
Note: this metric is only shown at a team level, not an individual level.