Why Lead Time for Changes gets distorted in reports
The Lead Time for Changes metric from the DORA set almost never comes from a single source. Change lead time is composed of timestamps in at least three systems: the issue tracker, the repository, the build pipeline, and the release system.
Each records its own time, and already at the junctions between them, the metric's accuracy begins to degrade.
The main source of distortion is manual timestamps in the issue tracker. A developer moves an issue to the next status not at the moment of the event, but when they remember: before a status discussion, at the end of the day, or when closing the iteration.
A delay of several hours at each step accumulates, and there can be five to seven steps along the path of a change — the result diverges from the actual change lead time by a multiple.
Then data discrepancy comes into play.
Urgent fixes go directly into the repository, their issues are created retroactively or not at all; configuration changes live entirely outside the issue tracker; distributed teams have different time zones, and a release timestamp falls on the neighboring day.
A metric assembled from such traces describes not the release process but the habits of filling in fields.
The practical cost is decisions made based on a distorted number. Capacity is planned incorrectly, the bottleneck is sought where it is not, and real acceleration of releases is not visible in the report.
We'll break down how this is closed: how to tie measurements to system events instead of manual input and get a number you can trust.
What end-to-end measurement of change lead time provides
End-to-end measurement collects events across the entire chain of a change's journey: the first commit to a branch, passing automated checks, review, artifact build, deployment to staging, release to production.
Each event is tied to a single change identifier — and instead of a set of local numbers per team, a unified delivery metric appears. The DORA report describes the same logic: what matters is the duration of the entire path, not the time of an individual stage.
The metric works only when it is collected automatically. Waiting for review, build queue idle time, repeated test runs, the pause between a built artifact and deployment — all of this is recorded from the systems where the work actually happens.
Then Lead Time for Changes answers the question "how long does the customer wait for the result", not "how long does the developer spend writing".
Next, flow bottlenecks become visible: if the median stays at hours, while the longest changes take days, the blockage sits in a specific step — most often waiting for review or manual release approval. This is analysis based on facts, not on participants' feelings.
And most importantly, the report arrives regularly and without manual reconciliation. No one exports issues into a spreadsheet or reconciles data from two systems manually: the number updates itself, and a change in it is matched to a specific process adjustment.
Methods for collecting change lead time data
The metric is collected in one of four ways, and the choice affects not the look of the report but what decisions are made from it. Below are the options among which a real choice is made, and their limitations.
Measurement options and their limitations
| Option | When it fits | Limitations |
|---|---|---|
| Automatic collection: issue tracker, version control system, continuous build, release tags | Work takes place in a single tracker, commits are linked to issues | A missed link means the change drops out of the sample; discipline in commit messages is required |
| Hybrid: automatic collection plus manual timestamps at boundaries — approval, release window, handover to operations | Part of the process is outside systems: manual approvals, scheduled windows | Accuracy depends on timeliness of timestamps — an owner and a policy are required |
| Manual log: engineers record start and completion themselves | There are no integrations or the process is only being established | Labor-intensive, the estimate is biased, does not scale — a measure for the launch period |
| Measurement only by build stages, without accounting for release | The speed of development itself is needed; release depends on external windows | Waiting between a finished build and release is not visible — the metric is understated |
Limitations are not important in themselves — comparability is important. If the definition of start and end changes from report to report, comparing periods loses meaning: the measurement method and metric boundaries are fixed in one place and changed only deliberately.
Implementation order: from flow analysis to policy
The Lead Time for Changes metric from the DORA set cannot be connected to reporting right away: first you need to make sure it measures exactly what the team agreed on. The order of work is the same for any toolchain — only the methods of exporting events change.
Implementation stages
- Analysis of event sources. We list the systems where a trace of a change remains: repository, build system, issue tracker, release registry, production environment. For each, we record the factual event — being taken into work, commit, successful deployment.
- Flow diagram and measurement boundaries. We draw the path of a change from idea to production environment and mark two points: the start and end of the measurement. Separately, we describe exceptions — canceled changes, hotfixes, manual configuration edits outside the common pipeline.
- Collection setup. Events are exported to a metrics store, commits are matched to a work issue by key. We calculate the median and the 90th percentile: the long tail shows the spread that the average hides.
- Historical validation. We run the calculation over past releases and compare it with a manual sample of major changes. Discrepancies reveal a forgotten source, a gap in matching keys, or changes that never reached production.
- Metric policy. We establish who is responsible for data correctness, who investigates deviations, and what threshold is considered a signal. The rule is written: when tools change, the measurement is revisited.
- Handover and support. We set up the dashboard and alerts, teach the team to read the chart, and compare the calculation with a manual sample quarterly. We support it ourselves for the first weeks; afterward, targeted adjustments are enough.
What we hand over: configurations, schemas, and policies
We hand over not a set of scripts but a reproducible measurement loop: any number on the dashboard can be broken down to the source events and explained where it came from. Below is the package that remains with your team and allows you to maintain the metric without us.
- Collection configurations — event sources (version control system, build pipeline, deployment orchestrator), polling intervals, binding of repositories and environments to services, rules for replaying data for past periods.
- Event schema and matching rules — which events are considered the start and end of the interval, how we join them by change identifier, how we handle rollbacks, parallel branches, and releases without code changes.
- Data access policies — access separation by team and service, anonymization of authorship where the metric is used for management decisions rather than incident analysis.
- Metric documentation — a dictionary of definitions, measurement points, known limitations, and a list of decisions that are deliberately not covered by measurement.
- Ownership policy — the person responsible for the metric, the procedure for changing definitions, the deviation threshold that triggers investigation, and the frequency of reconciliation with a manual sample.
- Exports and dashboards — ready-made views by team and service, as well as an API if the metric needs to be pulled into your internal portal.
- Calibration log — recorded discrepancies between the automated calculation and manual verification, with causes: this is what protects the metric from becoming decorative.
Case study: metric discrepancy reduced from a week to hours
The customer released changes in several streams and could not answer how much time passed from a finished fix to production. Data was collected manually: every two weeks, an engineer exported the merge history from GitLab and matched it with the issue tracker.
The discrepancy between sources reached one third of values, and some changes did not make it into the report at all.
The cost of such reconciliation is not only the engineer's hours. Bottlenecks within the process were discussed based on feelings, decisions were made using outdated snapshots: while the report was being assembled, the bottleneck had time to move to another stage.
The reaction came with a delay — when the problem had either already resolved itself or led to a failure in production.
What was changed
Event collection was set up at every stage — branch, code check, build, automated tests, rollout — and tied to an individual change rather than to the entire release.
The metric is calculated automatically and updates once a day, manual reconciliation has been removed, and source discrepancies are caught by matching identifiers.
What the result was
Report preparation time decreased from two weeks to several hours, and data discrepancies disappeared. The breakdown by stage showed where time accumulates: the share of changes reaching production in less than a day grew from 40 to 80%.
Bottleneck analysis became regular and relies on numbers for each stage, so reaction to deviation decreased from weeks to days.
How Lead Time differs from Cycle Time and Delivery Lead Time
Lead Time for Changes answers one question: how much time passes from a change entering the main branch to it working for the user. The start is code merge, the end is successful deployment to production.
Between them are build, checks, release, and enabling for real traffic: this is a flow metric; it measures the path of one change, not people's workload.
Cycle Time is counted earlier — from the moment an issue is taken into work. It includes requirement clarifications, queue waiting, and rework returns, so it is always greater.
Cycle Time shows team workload, while Lead Time for Changes shows the cost of turning code into a working result.
Delivery Lead Time starts even earlier — from a request or idea — and ends with value for the user. It includes prioritization, planning, and waiting in the development queue: this is a product-level metric, sensitive to priorities rather than to pipeline state.
Substituting boundaries breaks the metric. If issue creation is considered the start, queue growth masks slowdowns in build and checks; if the end is deployment to a test environment, the figure is understated and the release looks faster than the user experiences it.
A fixed definition is the only way to compare periods and link deterioration to a specific change in the pipeline.
In the DORA set, the metric works together with deployment frequency, change failure rate, and time to restore. By collecting all four from the same pipeline events, you can see where time is lost: in check queues, manual approvals, or waiting for a release window.
Common technical questions about setting up the metric
The Lead Time for Changes metric is calculated from events: a code change is recorded, enters the build, and is released to production. As soon as part of this path goes outside automation, the same value in two reports stops matching — and the metric stops being trusted.
Below are the questions that most often come up during setup, and the solutions built into the calculation scheme by default.
How should manual stages between build and release be accounted for?
We neither discard nor zero out the manual interval: it is marked with a separate attribute and placed in the "waiting" breakdown.
This makes it visible where the bottleneck is — in the pipeline or in approval — and the metric is not understated because of the manual step.
Events are stored in several accounting systems. How do we link them?
A single linking key is needed, usually the issue identifier, by which events from the tracker, build, and monitoring are stitched into one chain. We cut duplicates by first appearance time, and bring time zones to one before any calculations.
An event arrives late — does the metric drift?
We calculate with a catch-up window: the value for the day is marked preliminary and recalculated when late events arrive. Closed periods do not change in this case, so week-to-week comparison remains correct.
The team changed the policy: branches, statuses, release moment. What happens to the metric?
Interpretation rules are versioned together with the effective date: before the change we calculate by the old scheme, after — by the new one. Otherwise the chart shows a change in conventions, not a change in release speed.
Should history be recalculated after editing the scheme?
Yes, if the edit changes the meaning of an event, not just its name. We recalculate from the raw event log, not from ready-made summaries, and keep both versions — you can see what the edit produced, and the past is not rewritten unnoticed.
Let's discuss the task: what is needed to start measurement
Measuring Lead Time for Changes starts not with a monitoring dashboard but with access to the systems where a change leaves a trace: version control, issue tracker, build pipeline, release system. Until this data is consolidated, any number is a rough estimate. Therefore, at the start, a minimal but sufficient set is needed from the customer.
- Access to systems. A read-only token or account: commit history, issue transitions, build and release logs. Write permissions are not required.
- List of change journey stages. From issue creation to production rollout: where being taken into work, the first commit, a successful build, and the actual release are recorded.
- Metric owner. A person on your side who confirms calculation rules and investigates discrepancies — otherwise disputed cases stall.
- Sample of the current report. How it is calculated now: sample, frequency, what is taken as the starting point. This allows continuing the history rather than starting it from scratch.
- Exclusion rules. What to do with fixes without an issue, emergency releases, and rollbacks: include them in the common flow or count them separately. We agree before writing queries.
- Reconciliation window. A couple of business days: we calculate the metric manually for several recent releases and compare it with your report, and investigate discrepancies.
After that, the calculation scheme is agreed upon and fixed as a policy: one formula, one data source, automatic recalculation. Then the metric lives without manual edits, and all that remains is to ensure that some work does not bypass the tracker.