Pull request bottleneck analysis

Pull request bottleneck analysis breaks the time a change spends from open to merge into distinct stages, then identifies the stage where time accumulates fastest. Instead of reporting that a request takes three days to merge, it tells you that two of those days are spent waiting for a first review and the rest is split between active review and the final merge. The bottleneck is the stage holding the largest share of total lead time.

This matters because a single blended duration hides where the problem actually lives. Two teams can both average three days to merge, yet one is slow because reviews are thorough and the other is slow because requests sit untouched in a queue for two days before anyone looks. The fix is completely different. Bottleneck analysis exists to separate these cases so that effort goes to the stage that is genuinely holding work back.

The analysis is most useful as an ongoing diagnostic rather than a one-off audit. The bottleneck moves. Solve the first-review wait and the constraint shifts to active review, or to a slow check suite, or to the merge step. Tracking the share of time in each stage over time shows the constraint migrating and confirms whether a change actually relieved it.

There is no single formula, because the analysis is about decomposition. You split total lead time into ordered stages, measure the time spent in each, and express each as a share of the whole. The stage with the largest share is the current bottleneck. The inputs below are the stages most teams should measure.

1. 1

   Wait for first review

   Time from the request opening to the first reviewer engaging. This stage is almost always pure queue time, and on most teams it is the largest hidden delay.

2. 2

   Active review time

   Time spent in back-and-forth review, including the author addressing comments. Long durations here can be legitimate scrutiny or unproductive churn, so it is read alongside the number of review rounds.

3. 3

   Wait for merge

   Time between final approval and the request actually merging. Delays here usually come from check suites, merge queues, or branch conflicts rather than from people.

4. 4

   Check suite duration

   How long automated tests and builds take to complete on each push. Slow checks inflate both active review and wait for merge, and a slow suite can be the real constraint hiding behind two other stages.

Measuring shares rather than raw durations is what makes the analysis actionable. If wait for first review is 60 percent of lead time, the constraint is reviewer assignment, and speeding up the check suite will barely help. If wait for merge dominates, the people are fine and the pipeline is the problem. This stage view is the missing layer beneath blended metrics like cycle time, which tells you the total but not where it was spent.

A metric tree decomposes total pull request lead time into the stages that make it up and then into the operational causes of delay within each stage. This is what turns a blended duration into a clear answer about where to act.

The first level splits lead time into wait for first review, active review, and wait for merge. Each stage then decomposes into the specific causes of delay. Wait for first review breaks into reviewer availability and assignment clarity. Active review breaks into request size and the number of review rounds. Wait for merge breaks into check duration and queue contention. Every leaf is a lever a specific owner can pull.

The tree makes the constraint visible and the response unambiguous. It shows not only which stage is the bottleneck but the cause inside that stage, so the team acts on the assignment process, the request size, or the check suite rather than on the symptom.

The useful benchmark is the distribution of time across stages, not a single target duration. A healthy pipeline spends most of its lead time in active review, because that is the stage where value is added. When waiting stages dominate, the pipeline has a constraint to remove.

As a rough target, a healthy team keeps the wait for first review under a quarter of total lead time and spends most of the remainder in active review with one or two rounds. When this profile holds, sprint velocity and deployment frequency tend to follow, because completed work is reaching the main branch without sitting idle in a queue.

Improving flow means relieving the current bottleneck, confirming it moved, and then attacking the next one. Effort spent anywhere other than the constraint produces almost no improvement in total lead time, which is why naming the bottleneck first is the whole point.

The metric tree approach makes this disciplined. You find the stage with the largest share of lead time, act on its dominant cause, and then watch the tree to confirm the constraint has shifted somewhere else. Solving the first-review queue only to find active review is now the bottleneck is success, not failure, because the total has dropped and the next target is clear.

KPI Tree lets you model lead time this way by connecting each stage to the part of the team that owns it. The engineering lead owns reviewer assignment and queue depth. Authors own request size and response time. Platform owns the check suite and merge queue. With RACI ownership on every node and a verified impact loop that checks whether a change actually moved the stage it targeted, bottleneck analysis stops being a chart and becomes a closed loop from constraint to action to confirmed result.

1. 1

   Optimising total lead time blindly

   Pushing on the whole duration without finding the constraint wastes effort. Improving a stage that is not the bottleneck barely moves the total. Always locate the dominant stage first.

2. 2

   Confusing long review with delay

   A long active-review stage can be healthy scrutiny of a complex change. Treating all long durations as waste leads teams to rush review, which trades delay for defects.

3. 3

   Ignoring the wait for first review

   The queue before a reviewer engages is often the largest stage and the easiest to miss, because blended metrics fold it into review time. Measure it on its own.

4. 4

   Assuming the bottleneck is fixed

   The constraint moves once you relieve it. Treating bottleneck analysis as a one-off audit means the next constraint goes unnoticed. It is an ongoing measurement.

5. 5

   Blaming people for pipeline delays

   A slow merge stage is usually checks or queue contention, not reviewer effort. Attributing pipeline delay to individuals points the response at the wrong owner entirely.