Lead Time
Lead time indicates how quickly changes move from development to production. It helps teams understand how efficiently work flows through their software delivery process and where delays may be occurring. Shorter lead times mean faster value delivery.
This article outlines how we calculate lead time and how each stage in the lifecycle of a pull request is measured.
How It’s Measured
Lead time is calculated as the time elapsed from when a pull request is started (first commit is made on a branch) to when it is complete (merged to a development branch).
If you set up deployment tracking for your organization, you can also measure the deploy stage (time elapsed between merging and deploying a pull request). Industry benchmarks exclude the deploy stage because of the differences in workflows across teams.
We calculate lead time by summing the time a pull request spends in each stage.
- Develop: first commit to pull request open
- Review: pull request open to first review
- Approve: first review to first approval
- Merge: first approval to merge
- Deploy: merge to deploy
Develop
The Develop stage begins with the first commit associated with a pull request and ends when the pull request is first opened (or marked ready for review, if it began as a draft). This stage reflects the time spent actively working on changes before they’re shared for feedback.
The first commit is based on the earliest commit in the pull request. We analyze all commits included in the pull request and select the one with the earliest author timestamp. If an author timestamp is unavailable (only affects organizations using Bitbucket), we use the commit timestamp.
Here is how common Git workflows can affect this metric:
| Workflow | Description | Impact |
|---|---|---|
| Cherry picking | When you cherry-pick a commit, you are creating a new commit on your current branch that applies the exact same changes. The new commit will have a new SHA, but it will preserve the original author timestamp. The commit timestamp, however, will be updated to the time of the cherry-pick. | Moderate. Cherry-picking preserves the original author timestamp of the commit being picked. If a cherry-picked commit is from before you started creating commits, it will extend lead time. |
| Squashing commits locally | When you squash commits, you are creating a single new commit with a new SHA. By default, the author timestamp of this new squashed commit is taken from the first commit in the series, but the commit timestamp is set to the current time. | Minimal to None. By default, the new squashed commit inherits the author timestamp from the earliest commit in the set. As long as this default is used, the time between the first author timestamp and the PR open time will not change. |
| Amending commits | Amending a commit keeps the original author timestamp by default, but updates the commit timestamp to the current time. | Minimal to None. Amending a commit preserves the original author timestamp by default. It will only change if you deliberately alter the author date (e.g., using git commit --amend --date=<new_date>). |
| Rebasing | If a pull request is rebased and then force-pushed, it rewrites the branch's history. This creates new commits with new SHAs for each original commit, but preserves the original author timestamps. | None. Rebasing creates new commits but preserves the original author timestamps for each of those commits. The time between the first author timestamp on the branch and the PR open time will not be affected. |
The open timestamp is set when the pull request is made visible for review. If the pull request started as a draft, we wait until it’s marked “ready for review” to set this timestamp. Otherwise, the timestamp is taken from when the pull request was initially created.
Review
Time to Review is calculated as the time between opening a pull request and the first review.
The first review timestamp marks when the pull request receives its first review or comment. Reviews from bots and open source contributors are excluded, but reviews from managers are included.
Approve
Approve is calculated as the time between the first review and first approval submitted. Like reviews, we ignore approvals from bots and open source contributors, but include those from managers.
The Approve stages counts any pull request that went through your approval process (including those that were closed, but not merged). It does not count additional approvals that happened after the pull request was approved, or approvals that happened after the pull request was merged or closed.
Coming Soon: Improved Definition
We are actively working on a change to account for the required approval count. The Approve stage will then be measured as the time between first review and the last approval meeting the required number of approvals.
Merge
Merge is the time between first approval and merge. Closed but unmerged pull requests do not count towards this stage.
Deploy
Deploy is the time between merge and deploy. Pull requests merged into repositories that do not deploy will be excluded from this stage.
The Deploy stage requires configuration and is not included in industry benchmarks.
Other Considerations
We automatically exclude pull requests in development workflows—such as dependency updates, back merges, and releases—that are not representative of developer productivity.
You can also manually exclude Git users from your metrics, including lead time. Excluding all activity by a user removes their pull requests, reviews, approvals, and merges from all calculations. Alternatively, you can choose to exclude only pull requests created by a user—useful for roles like product managers or designers—while still including their reviews and approvals to ensure metrics like Time to Review remain accurate.
Lead time includes weekends to capture the full duration from the start of development to when changes are delivered to users, providing a more accurate view of how quickly value is shipped to customers. This reflects the pace at which improvements and features become available to your users.