When delivery slows, the instinct is to speed up every stage by asking engineers to code faster, adding reviewers, buying more CI capacity, or tightening release targets, yet that response can create a longer list of initiatives without improving the result customers experience.
A software delivery bottleneck is the constraint that most limits the outcome the team cares about now, which may be different from the stage that looks slowest. DORA's guidance on improving software delivery performance and mapping the value stream follows the same logic: begin with the outcome and the end-to-end flow, then test one bounded intervention before measuring again because the constraint can move.
This is a system question that ranking people will not answer, because delivery data can show where work waits while the people doing the work supply the context needed to understand why.
How a bottleneck constrains software delivery
A bottleneck is the part of a delivery system that constrains the chosen outcome, so the boundary depends on what the team is trying to improve. For urgent fixes, the relevant flow may begin when an issue is ready for engineering and end when the change is live, while predictable feature delivery may require a boundary that starts earlier, with discovery or committed work.
The distinction matters because local efficiency and system throughput are not the same thing: a team can shorten coding time while pull requests wait for review, a security check returns work late, or releases remain bundled behind a manual approval. In that system, more completed code simply becomes more work waiting downstream.
Use a cycle time view to establish where time is spent, but resist treating one average as a verdict because a high number identifies a place to investigate without proving a root cause. The guide to cycle time phases explains how to read those stage-level signals against the team's actual flow.
Why faster coding can leave delivery unchanged
AI-assisted development and better tooling can increase local output, but the 2025 DORA report describes AI as an amplifier of the strengths and weaknesses already present in a system. DORA's guidance on platform engineering adds that testing and security review can absorb gains in coding speed, as can deployment.
The better question, then, is not “Which team is slow?” but “Which outcome is underperforming, and where does work wait on the path to it?” Whether the answer appears technical, organizational, or tied to demand and capacity, treat it as a hypothesis until the evidence and the team's experience agree.
How to find the constraint that matters now
1. Choose the outcome and the value stream
Pick one outcome that warrants attention, such as a long lead time for changes, unpredictable release dates, delayed fixes, or a growing queue of aging work, then name the value stream that produces it. Keeping unrelated work out of the same average, whether it comes from different services, work types or teams, makes the result easier to interpret.
Lead time for changes is useful when the question includes the path to production, whereas cycle time may be more useful when the concern begins with active work. DORA recommends defining the outcome and the value stream before choosing what to improve.
2. Map the real path work takes
Write down the flow as it actually operates, not as the process diagram says it should operate, and include ready, in progress, review, CI, security, approval, deploy and verification along with waits between teams, dependencies, return loops and work that is blocked but still open.
Value stream mapping makes invisible intervals discussable because DORA's mapping instructions ask teams to capture wait times and handoffs while calling out where work piles up. Add any repeated return to an earlier stage, so the resulting map becomes a shared boundary for deciding what to inspect next rather than a compliance exercise.
3. Compare signals instead of trusting one average
For each stage, compare stage time with waiting time, then add work age, work in progress (WIP), throughput, rework and the shape of the distribution. This wider view matters because a queue that is small on average may still produce unacceptable waits for urgent changes, while a steady average can hide a rising tail.
Use flow metrics to ask better questions, not to manufacture certainty. If PR pickup time rises while review duration is stable, investigate who owns assignment and whether reviewers are available. For CI queues that rise with retry rates, inspect runner capacity and the slowest suite while checking flaky tests separately. The metric tells you where to look, but it does not tell you whom to blame.
4. Validate the hypothesis with the team
Bring the pattern to everyone who works in that part of the flow, including engineers and reviewers as well as security and release partners, then ask what changed, which kinds of work are represented and what the aggregate view hides. A dependency or an unclear policy can produce the same visible delay as a large batch, so the numbers need operational context.
This conversation keeps a dashboard from becoming surveillance, especially when the workflow is measured at team or service level, comparable work is examined together, and the numbers are read alongside the team's account of what happened.
5. Run one bounded experiment
Choose an intervention that has the clearest link to the outcome and enough evidence behind it, while preserving a safe way back if it fails and a scope small enough to learn from the result. A team might trial a reviewer rotation, isolate one unreliable CI check, define ready criteria for a work type, or reduce one release batch.
Rather than pausing safety or incident-response work to protect an experiment, state the guardrails in advance so quality and stability remain acceptable while customer impact stays within agreed bounds. DORA's improvement cycle follows a direct sequence: identify the most significant constraint, improve it and check progress before repeating the cycle.
6. Measure the result and find the next constraint
Recheck the original outcome alongside the signals that could reveal a trade-off by comparing throughput, cycle or lead time for the same class of work, and any change in failures, rework, or instability. A favorable movement in one local stage is not enough when the outcome stays flat.
When an experiment works, the constraint may move, which is progress rather than failure because the next round starts with the new flow instead of the prior assumption. A continuous improvement loop makes that repeated diagnosis an operating habit rather than a one-off optimization.
A diagnostic matrix for common delivery bottlenecks
Use this matrix to form a first hypothesis. It is not an automated diagnosis: the same symptom can have different causes in different systems.
| Observed symptom | Signal to inspect | Plausible constraint | First low-risk experiment |
|---|---|---|---|
| Work ages before coding starts | Backlog age, blocked time, priority churn | Unclear priorities or dependency wait | Define ready criteria and limit new starts for one team |
| PRs wait for a first review | Pickup time, PR age, reviewer load, PR size | Reviewer capacity, ownership, or oversized changes | Trial a reviewer rotation and a smaller PR boundary |
| CI feedback is late or repeatedly fails | Queue time, run duration, retry or failure rate | Runner capacity, slow suite, or flaky checks | Isolate the longest or least reliable step before parallelizing or repairing it |
| Security returns work late | Approval wait and rejection/rework rate | Late manual gate or unclear policy | Move one check earlier or trial a pre-approved path |
| Merged work waits for production | Merge-to-deploy time, batch size, deployment rework | Release windows, manual approval, or coupling | Automate one handoff or reduce one release batch |
How to prioritize the first fix
Prioritize the hypothesis with the clearest connection to the outcome, enough evidence to make a decision, and a reversible experiment. Do not simply choose the largest number on a dashboard.
Check four things before acting:
- The expected effect of easing the constraint on the chosen outcome.
- The evidence that would disprove the hypothesis.
- Whether the team can test the change without unacceptable risk.
- The quality and stability signals that must remain within bounds.
This approach connects flow and DORA metrics: delivery outcomes show whether the system improved, while flow signals guide the investigation.
Separate a constraint from a local symptom
An obvious delay is not automatically the constraint: a review queue that grows every Friday may point to reviewer capacity, but it could also be the visible result of large changes arriving late in the week, an upstream dependency that releases work in batches, or a policy that requires a particular approver. Adding more reviewers before understanding that pattern could increase interruptions without changing the delivery outcome.
Check whether the suspected stage limits the flow over time and for the class of work that matters by looking at arrival patterns, the age of items in the queue, return loops and what happens immediately before and after the stage. Ask the people involved what they see when the data changes so the first experiment tests a possible cause instead of merely reacting to a number.
The same discipline applies to healthy-looking averages, since a team may report acceptable cycle time while release windows consistently delay urgent fixes. Segment the work before deciding that the system is healthy or that a single intervention is working, document why the team chose its response and what should change, then set a review date because the aim is to reduce uncertainty enough to choose the next safe action and preserve what the team learns.
Use delivery data without turning it into surveillance
The unit of analysis is the system, whether that means a team, service, workflow, or class of work, because individual rankings turn diagnostic signals into incentives to game the process, make the conversation less honest, and confuse a symptom with a person.
Review patterns with the people closest to the work, preserving incident load, dependency changes and work type in the analysis because a bottleneck may come from policy, a handoff, or an architectural constraint that no individual can solve alone. DORA also warns against turning delivery metrics into competition between teams, which would distort the data the team needs for diagnosis.
Put the method into practice
Start with one value stream and one underperforming outcome, then map the path and inspect the signals before discussing the hypothesis, running one bounded experiment and measuring the result.
If you need a shared vocabulary while doing that work, DevStats’ software delivery metrics glossary and guide to measuring lead time for changes can help teams frame the flow before they decide where to intervene.
If the part of the flow under investigation is the pull request, teams can use the DevStats PR Cycle Time dashboard to compare Coding and Pickup with Review and the later Merge and Deploy stages, then see where elapsed time accumulates. The breakdown starts the investigation rather than determining the cause, which still requires the team to examine the pattern before choosing an experiment.