Yes, you can measure PR cycle time without monitoring your team. A small number of process data points from the pull request itself are enough, such as creation, first response and completion. The key is to use this data as a process signal rather than to assess individual people.
This article looks at Azure DevOps Services with Azure Repos. A pull request is a proposed change in the repository that is reviewed before it is merged. Precisely for that reason, timestamps can be read from the normal review workflow without screen activity, keystrokes or similar forms of personal monitoring.
At its core, you only need three perspectives:
- start of the pull request
- first identifiable response
- completion of the process
If you also want to distinguish the process from policies and automated checks, the articles on AI code review for Azure Repos, what machines check and using PR status as a policy are helpful.
Which flow metrics actually help
For a starting point, three flow metrics are usually enough:
- time to first review response
- PR cycle time
- pull request size
Time to first review response is an early indicator. It shows how quickly a pull request gets attention from the team. It does not tell you whether the change was good or whether a person is working “quickly enough”. As a response, you might count the first comment, the first reviewer vote or a first formal check.
PR cycle time is the end-to-end metric. This means the time from creating the pull request to completing it, whether by merging it or closing it without a merge. End-to-end here means you look at the whole process from start to finish, not just one individual step. This metric is particularly useful for making waiting times between handovers visible.
Pull request size is the context metric you need. It can be described, for example, by changed files or the overall scope of the changes. It often explains why two pull requests have very different lead times even though the same process applies. Small bug fixes and larger restructurings should therefore not be judged against the same expectation.
What matters is this: read these three metrics together. A long cycle time is not, by itself, a problem. The pull request may have been large, needed an additional build or been waiting for a reviewer with business-domain knowledge. Pure counts such as number of comments or number of reviewers are also often of limited value on their own, because they depend heavily on policies, codebase and team habits. For typical review checkpoints, a checklist in the PR text or a business review checklist can structure the process better than simply adding more comments.
Then there are the policies in Azure Repos. Branch Policies can enforce, among other things, a minimum number of reviewers, comment resolution, linked work items, build validation, status checks, merge types and automatically included reviewers; all are off by default. Source: Microsoft Learn, “Branch policies overview”, accessed on 01/11/2026, and “Branch policies”, accessed on 01/11/2026. If, for example, you use mandatory reviewers selectively, use builds as a quality gate or reset reviewer votes on new pushes, that changes the process immediately.
However, more mandatory steps do not automatically mean more quality. What they change first is the process, and that is exactly what you will later see in your metrics.
Where the data in Azure DevOps comes from
For robust PR metrics, you do not need additional monitoring, but a clean event source. In Azure Repos, that source is the pull request itself: timestamps for creation and completion, review comments, votes, build results, status messages and changes between iterations. Here, iteration means a new version of the same pull request after further pushes.
The key is to separate events by their function. For analysis, these groups are especially useful:
- responses from people, such as a comment or vote
- technical check results from a build or status check
- changes to the state of the pull request, such as completed or closed
- new iterations after a further push
In Azure DevOps, this is more than a detail. Branch Policies can enforce a minimum number of reviewers, linked work items, comment resolution, build validation, status checks, merge types and automatically included reviewers; all are off by default. Source: Microsoft Learn, “Branch policies overview”, accessed on 01/11/2026, and “Branch policies”, accessed on 01/11/2026.
Just as importantly, not every AI signal counts like an approval. Microsoft states for Azure Repos that Copilot code review in Public Preview leaves a Comment Review so that no mandatory reviewer policy is satisfied and no merge is blocked. Source: Microsoft Learn, “Review pull requests”, accessed on 01/11/2026, and “Copilot code reviews”, accessed on 01/11/2026. You should keep that separate in your measurement logic.
If you are evaluating new tools, keep assumptions and open status visible: on the page about security and data status, in the public changelog and later with measurements from real runs.
Use metrics for the process, not for people
Process metrics are most valuable when used to steer the process. They make visible where pull requests are waiting, where time is lost in handovers, where responsibilities are unclear and at what point changes simply become too large for a smooth review flow.
That is why you should mainly look at this data at team, repository or service level. If you publish metrics at individual level, the purpose quickly shifts: a signal for bottlenecks easily becomes a tool for interpreting performance. For managing the review process, that is usually the wrong focus.
Questions like these are more useful:
- When do pull requests typically remain untouched?
- Which Branch Policy creates additional waiting time?
- From what PR size does cycle time increase significantly?
- Where do repeated loops arise between author, review and build?
Pull request size in particular should be analysed separately. Large architectural changes often need different review paths from small bug fixes. If both end up in the same expectation class, the figures can quickly look worse than the process really is.
The “time to first review response” also needs context. On-call models, time zones or a small number of domain-specific reviewers can strongly shape this metric. So always note the conditions under which the data was produced. Otherwise, you appear to be comparing the same metric while actually describing different working realities.
There are also settings in Azure Repos itself. Policy options such as “Require at least one approval on the last iteration”, “Reset all approval votes” or “Reset all code reviewer votes” on new pushes directly affect the measured time. Source: Microsoft Learn, “Branch policies”, accessed on 01/11/2026.
What matters is how you interpret this: such options can lengthen metrics without your process having become worse. Often, only the number of mandatory steps per iteration increases. A longer cycle time may then reflect a deliberately stricter review process rather than a weaker team.
So use target values as a starting point for discussion rather than as rigid requirements. Otherwise, teams can easily learn to optimise the metric instead of conducting reviews in a technically meaningful way. If you later add metrics for new tools or future package and sign-up routes, the same principle applies: read the process first, then the number.
Common questions
Which starting metric gives useful indications quickly?
If you start with just one metric, use time to first review response. It shows whether pull requests become visible or initially sit untouched. For early decisions, that is often easier to use than a single end-to-end figure.
Add PR cycle time early on as well. Otherwise, you only see the start of the review, not where the rest of the time goes.
What counts as a first review response?
Define it in advance and keep that definition stable. Otherwise, time series become noisy even though the process has hardly changed.
In practice, these events are usually candidates:
- first comment
- first reviewer vote
- first technical check signal from build validation or status check
Do not mix human and technical responses without noticing. A status check is a process event, not business feedback.
Should I include pull requests that are closed without merge?
Yes, as a rule you should. Otherwise, you leave out part of the actual process. Pull requests that are discarded or replaced in particular often show where uncertainty arises in scoping, responsibility or preparation.
It makes sense to separate by completion type:
- completed with merge
- closed without merge
That way, it remains clear whether long lead times come from successful review or from abandoned processes.
How should I deal with new pushes to the same pull request?
Treat new iterations consciously as a separate influencing factor. An iteration is a new version of the same pull request after a further push. Several iterations can be sensible, but they often lengthen the process.
What matters here is your policies. In Azure Repos, settings such as “Require at least one approval on the last iteration”, “Reset all approval votes” and “Reset all code reviewer votes” on new pushes can measurably change the time. Source: Microsoft Learn, “Branch policies”, accessed on 01/11/2026.
Is a median enough, or do I need more?
A median is a good starting point because individual outliers affect it less strongly. For steering discussions, though, a single value is rarely enough.
At a minimum, also include:
- number of pull requests in the period
- separate view by size classes
- separate view by completion type
That helps you avoid deriving a general process diagnosis from a small number of special cases.
When does measurement become legally relevant or subject to co-determination?
This question arises as soon as PR data could be analysed at individual level or used to interpret behaviour and performance. For works councils in Germany, § 87 para. 1 no. 6 and § 90 BetrVG are especially relevant. In regulated companies, DORA or the NIS2UmsuCG may also be relevant.
What that means in your case should be checked with the works council, the data protection officer and, where appropriate, with a lawyer.
Next step
Start with a small, clear set of measurements in a limited area, for example for a main repository branch or one product team:
- time to first review response
- PR cycle time
- PR size
Then always read these values together with the applicable Branch Policies. Derive only process measures from them, such as smaller pull requests, clearer reviewer responsibilities or more cleanly defined status gates.
If you are evaluating AI support for Azure Repos, keep four points clearly separate: preview status, data paths, policy effects and the difference between a comment and a blocking check.
If the path from work item to pull request in Azure DevOps Services is relevant for you: Polier from ballmüller solutions is in development and not yet available. It is intended to turn Azure Boards work items into reviewed pull requests in Azure Repos, without merging itself and under the customer’s Branch Policies.