Lead time is the elapsed time for a change from a defined start point to a clearly defined end point. In Azure DevOps, you measure lead time meaningfully when you define the start and end unambiguously for each team and always read the figure in the context of your pull request workflow.
In practice, that means first defining what kind of change you are measuring at all. Otherwise, you will end up comparing different journeys and get a number that looks precise but explains very little.
A short, fixed definition per repository is useful, for example:
- start at a business event
- end at integration via the pull request
- the same rule for all reporting
In Azure DevOps, that also includes the framework within which pull requests are reviewed and completed. Branch policies in Azure DevOps influence which stages lie between creation and completion and should therefore be part of your definition from the outset.
Which flow metrics actually help
Anyone searching for lead time often means a single number. In Azure DevOps, however, that metric only becomes reliable when you define the start and end points in the workflow properly: for example, from the point when a work item moves into active implementation to the completion of the related pull request.
For teams driven by pull requests, three sub-metrics are especially helpful:
- Time to first review: This shows whether changes are being noticed promptly. For CTOs and engineering managers, that is useful because bottlenecks often do not lie in coding, but in attention, ownership or insufficient reviewer coverage.
- Time to merge: This means the time from opening the pull request to integration. It includes questions, revisions, build waiting times and policy checks.
- Size of the change: Large pull requests distort almost every time-based metric. You should therefore always read lead time together with size context, for example by number of files changed or scope of the change. A separate view is particularly worthwhile for draft pull requests.
Important in practice: do not report averages alone. Also look at distributions and outliers. An average can hide the fact that many small changes move quickly while a few large pull requests block the flow.
The interpretation matters just as much: these metrics describe the flow of the system, not the performance of individual people. As soon as they are turned into a ranking of individuals, both data quality and behaviour in the process usually deteriorate.
Other metrics still matter, but in a different role. Build duration, waiting time for approvals or the number of open comments do not replace lead time; they are more useful for explaining causes.
If branch policies are active in your environment, they are part of the system being measured. Microsoft lists typical policies as a minimum number of reviewers, linked work items, comment resolution, merge types, build validation, status checks and automatically included reviewers; all are disabled by default (Microsoft Learn, “Branch policies overview”, accessed on 01.11.2026). For practical implementation, branch policies as code, bypass permissions and PR status as a policy are often helpful.
Where the data in Azure DevOps comes from
For lead time in Azure DevOps, you will usually need measurement points from three sources: Azure Boards for the start of the work, Azure Repos for pull requests and commits, and Pipelines and policy results for review and waiting times.
Consistency matters here. Define exactly one event source for each metric. Otherwise, you may measure the same stretch once via work item states and another time via PR timestamps. That sounds minor, but it quickly creates contradictory values in reports.
Typical timestamps are:
- creation of a work item
- status change into implementation
- creation of the pull request
- first reviewer activity
- successful builds
- status checks
- completion of the pull request
In Azure Repos, the history of a pull request is also shaped by branch policies. Microsoft states that policies can be set via “az repos policy” or via the REST API (Microsoft Learn, “Branch policies” and “Securely use Git and pull requests in Azure Repos”, accessed on 01.11.2026). That is relevant if you want to build metrics across the organisation using the same rules.
One further point matters for analysis: according to Microsoft, the merge type is more a matter of history governance than a direct security mechanism. Squash simplifies the target history, but does not fully preserve the order of source commits. If your audit model depends on the exact commit sequence, Microsoft recommends merge-commit strategies rather than squash (Microsoft Learn, “Securely use Git and pull requests in Azure Repos”, accessed on 01.11.2026).
That affects your measurement as well. If you derive rework or commit sequences from the history, you need to know whether squash is allowed in the repository.
That is why a small data model is practical at the start: measure only a few clear events first, then check samples in real pull requests before rolling out dashboards widely. If you want to automate collection, the deeper dives into pull requests via REST API and service hooks for pull requests are helpful.
Use metrics for the process, not for people
Anyone searching for lead time usually wants not just to measure in the end, but to steer more effectively. This metric is most useful when you read it as a signal for process questions: where work is backing up, which rules are creating waiting time, and at what point a small change unnecessarily turns into a long-running task.
Useful analyses are those that support decisions in the workflow, for example:
- by repository or team context,
- by the size and shape of the change,
- by the type of approval in the pull request process,
- by waiting phases between review, build and completion,
- by recurring patterns in questions or rework.
That way, you are more likely to see system effects than isolated cases. A metric is helpful when it triggers a concrete follow-up question, such as whether reviewers are being brought in too late, whether builds are blocking for too long, or whether changes are going into review too large.
Caution is sensible as soon as new automation or AI support is introduced. More comments, additional status messages or a different way of slicing work do not in themselves amount to proven improvement. If you want to assess impact, you need a fixed baseline, a clearly defined period and the same measurement logic before and after the change.
To classify planned approaches, it helps to look at selection criteria for coding agents. If you later want to assess specific product information, keep current status, changes and future evidence clearly separate: what applies today and what does not yet apply, public changes to the current status, reliable metrics later on and the planned route to sign-up.
A brief note on works councils and governance
As soon as lead-time data can be traced back to individuals, teams or working behaviour, it is no longer only about clean measurement points. Co-determination, transparency and the permitted use of the analysis also become important.
For works councils in Germany, two reference points are especially typical:
- Section 87(1) no. 6 BetrVG: in simplified terms, this concerns technical systems that are capable of monitoring behaviour or performance.
- Section 90 BetrVG: in simplified terms, this concerns information about work processes and the use of AI.
In regulated environments, further questions arise. These include DORA, NIS2 and data protection. In practice, this concerns points such as:
- which data flows where,
- who the processor is,
- what logging is предусмотрed,
- which controls and approvals are expected.
This article deliberately does not provide legal advice on these matters. It makes sense to review the specific arrangement with your legal department, data protection officer and, where applicable, the works council.
Preview features can also make it relevant where data is processed. In its FAQ for Copilot code review, Microsoft states that data residency is not tied to the Azure DevOps organisation and that processing may also take place in another geography such as the USA (Microsoft Learn, “Copilot code reviews FAQ”, accessed on 01.11.2026).
If you want to assess the governance framework for AI-supported PR processes in more depth, it is worth looking at that separately.
Frequently asked questions about lead time in Azure DevOps
Which end definition is best for lead time in Azure DevOps?
Anyone searching for lead time usually wants to know when a change in Azure DevOps is truly “done”. For teams driven by pull requests, an end point at the completed pull request is often practical, because that is where review, policies and integration come together.
Different definitions make sense if you deliberately want to measure something else:
- completion of the pull request for the path to integration
- successful production step for the path to delivery
- completion of a linked work item for the business view
What matters is that the end point fits both the business and technical perspective.
How should I deal with reopens and multiple PR iterations?
A reopen means opening a pull request again after it has already been closed. You should define such cases in advance as a separate category rather than quietly counting them as normal cases.
Simple rules help with measurement:
- count the original PR as one continuous process,
- report reopen cases separately,
- do not treat iterations as a new lead time.
Otherwise, you end up comparing straightforward changes with returns without seeing that in the report.
What should I do if a work item is assigned to several pull requests?
This happens regularly in Azure DevOps, for example in rework, partial implementations or separate repositories. Your analysis then needs a priority rule. Without one, the same work will be counted multiple times.
Two practical options are, for example, to take either the first completed pull request as the end point or the last one, if that is when the business change is only finally integrated. Choose exactly one rule.
Do auto-complete and queue times belong in lead time?
Yes, if they are part of your actual workflow. Auto-complete means Azure DevOps completes the pull request only once the required conditions have been met. If a pull request is waiting for build validation, status checks or required reviewers, that is part of the system’s elapsed time.
This view is particularly useful for engineering decisions: not every delay is active work, but every delay shapes the flow.
Next step: start small and tighten definitions
For the start, set up a short measurement cycle. Not with a large dashboard, but with a small sample from a clearly defined workflow.
At first, the following is enough:
- one repository,
- a fixed start definition,
- a fixed end definition,
- a short period,
- a manual plausibility check.
A plausibility check means comparing whether the measured timestamps fit the actual workflow. Only once that is working cleanly is automation worth the effort.
If you later want to assess AI support in the PR process, keep the question of measurement separate from the question of the tool. Polier by ballmüller solutions, Berlin, is a coding agent for Azure DevOps that is in development and not yet available as of 01.11.2026.