VeloWiseengineering delivery intelligence

How to Find Bottlenecks in Software Delivery

When delivery slows, the instinct is to ask engineering to go faster. Often the constraint is somewhere else: work waiting for review, for testing, for a release window. Finding it takes two simple views — where work accumulates, and how long it stays.

Part of Engineering Delivery Intelligence: better planning and fewer surprises

For: Engineering managers, directors and delivery leadsUpdated

This guide answers

  • Where is work accumulating?
  • Is that unusual for this team?
  • Is the work moving, or stuck?
  • What should we investigate first?

Where work is accumulating

Mid-sprint · started, unfinished work by stageExample delivery data
  • Development8usual 10
  • Code review19usual 7
  • QA21usual 9
  • Released this sprint6usual 14

now usual for this point in a sprint

Code review and QA each hold more than twice their usual queue. Development is below normal.

The bars show how many issues are in each stage right now; the marker shows this team’s usual level at the same point in a sprint. Development is below its usual level. Code review and QA are far above theirs. Meanwhile fewer issues than usual have been released.

This is the classic shape of a downstream bottleneck: engineering keeps finishing work, and it piles up waiting to be reviewed and tested. Asking developers to go faster would make the queues longer.

Seeing this depends on the workflow itself. If review and testing share one “In Progress” status, or waiting and active work share one status, the queue is invisible. See software delivery workflows for which stages make bottlenecks visible — and which only add overhead.

Compare each stage with its own history

A queue of 19 issues in code review is not large or small in the abstract. For a team that usually has 20, it is normal; for one that usually has 7, it is a warning. That is why fixed red/amber/green thresholds mislead: they flag teams with naturally large queues and miss real build-ups in teams with small ones.

StageNowUsualReading
Development810Within normal range
Code review197Well above usual — investigate
QA219Well above usual — investigate
Released this sprint614Below usual

Is the work moving, or stuck?

Count vs ageExample delivery data

Code review · Team A

0–2 days6
3–5 days4
6–10 days8
10+ days11

29 issues — and 19 of them older than 5 days.

Code review · Team B

0–2 days18
3–5 days4
6–10 days1
10+ days0

23 issues — nearly all fresh and moving.

A short queue of old work can matter more than a long queue that is flowing.

Queue size says how much is waiting. Aging says whether it is moving. Look at how long each item has been in its current stage compared with the team’s usual time in that stage. A review queue where every item is a day old is busy; one where several items are a week old is stuck.

Where the time goesExample delivery data

ABC-204 · one issue’s journey

Cycle time · 10 days
Lead time · 16 days

The longest single segment is code review (4 days) — more than development itself.

Where the time goes: in many teams, work spends longer waiting between stages than being actively worked on.

From signal to fix: an investigation path

Investigating a bottleneckExample delivery data
  1. AccumulationWhich stage is above its usual level?
  2. AgingIs the work there old, or just arriving?
  3. QuestionAsk the team what is holding it
  4. ChangeCapacity, policy or process
  5. CheckDid the queue return to normal?

Move from a number to a conversation to a change — and check it worked.

  • Code review bottleneck: agree a review-before-starting rule; limit work in progress; spread review load beyond one or two senior engineers.
  • QA bottleneck: move testing earlier; pair developers with testers; invest in test automation and stable environments.
  • Release bottleneck: shorten release cycles; reduce manual approval steps; release behind feature flags.
  • Blocked work: find the shared dependency and escalate once, with a named owner.

The fix that makes bottlenecks worse

Responding to a QA bottleneckExample delivery data

Common response

Push development harder

  • More work finishes development
  • QA queue grows further
  • Carryover moves from development to QA
  • Nothing more reaches production

Better response

Relieve the constraint

  • Pause new starts until QA catches up
  • Developers help test and fix environments
  • Oldest items first
  • More work reaches production

Pushing more work into a constrained stage lengthens the queue. Relieve the constraint instead.

The counter-intuitive part of bottlenecks is that the rest of the system should slow down to match the constraint, not speed up. Starting more work than the bottleneck can absorb only creates inventory — issues that are “almost done” and deliver nothing.

Bottlenecks are also one of the main hidden causes of carryover and of late delivery surprises.

Reporting a bottleneck to leadership

Example · Bottleneck note

Code review and QA are both more than twice their usual size (19 vs 7, and 21 vs 9), while development is slightly below normal. Fewer issues than usual have been released this sprint.

Engineering output is not the problem; work is waiting after development. We are pausing new starts for two days, pairing developers with QA on the oldest items, and spreading reviews beyond two senior engineers.

If the QA queue is still above 15 on Thursday, we will need to discuss testing capacity for next quarter.

A good bottleneck note does three things: it shows the comparison with normal (so the reader knows it is unusual), it says where the constraint is not (so nobody pushes the wrong team harder), and it states what will happen next and when it will be checked. Leadership does not need to solve the bottleneck; it needs to know the team has seen it, and when to step in.

Bottlenecks outside the board deserve the same treatment: slow approvals, shared test environments, another team’s API. They often show up as “blocked” work — which is why blocked issues should always say what they are waiting on.

See this in VeloWise: Bottleneck analysis

Current queues in each stage compared with their own history, plus aging and blocked issues — so a growing review or QA queue stands out early.

Open Bottleneck analysisHow bottleneck analysis works

Works with the sample project or your own data. VeloWise currently imports delivery data from delivery data exports.

Go deeper

Frequently asked questions

What is a bottleneck in software delivery?
A stage — often code review, QA or release — where work arrives faster than it leaves, so a queue builds up and slows everything behind it.
How do I measure bottlenecks without time tracking?
Count work in each stage and compare it with that stage’s usual level, then check how long items have been there using status-change history. No hours are needed.
Should I add people to the bottleneck stage?
Sometimes, but first look for cheaper fixes: limiting new work, spreading reviews, automating tests. Adding capacity elsewhere in the system usually makes the queue longer.

All engineering delivery guides