Software delivery: the six phases and where each one stalls

Software delivery stalls in one phase at a time, and the phase is findable. Delivery covers six measurable stages between the first commit and a running release: coding, pickup, approve, merge, review, and deploy. LinearB's 2026 Software Engineering Benchmarks Report, built from more than 8.1 million pull requests from 4,800 teams across 42 countries, puts elite pickup time under one hour and elite cycle time under 25 hours at the 75th percentile, while pull requests created by AI agents wait 17.6 hours for review alone. A cycle time total cannot tell you which stage to change. This page gives you the band for every phase and the four steps that isolate your constraint.

Cycle time is the sum of the six phases, and decomposition is what makes it actionable. See cycle time.

Software delivery is the movement of a code change from first commit to production, measured phase by phase. Cycle time is the total, and the phase breakdown is what tells you where the delay lives.

Six phases describe the path from commit to release, and each has a distinct failure mode. Coding time runs from first commit until a pull request is published, and a long coding time correlates with high work in progress, large pull requests, and unclear requirements. Pickup time is how long a pull request waits before someone starts reviewing it. Approve time runs from first comment to first approval, and merge time runs from first approval to merge, which together form a granular view of review time. Deploy time runs from merge to release.

The phase names matter because they separate two problems that look identical in a total. A four-day cycle time caused by pickup delay needs routing rules, and the same four days caused by deploy delay needs pipeline work. For the related distinction between end-to-end lead time and cycle time, see lead time vs cycle time.

What to do next: Break your cycle time into the six phases before your next planning meeting. A single total number cannot tell you which team to talk to.

Elite delivery keeps pickup time under one hour and review time under three hours at the 75th percentile, according to LinearB's 2026 Software Engineering Benchmarks Report. The table gives the full set. Time values are in hours unless minutes are shown.

Deploy time carries the widest spread of any delivery metric, from under 16 hours at elite to over 277 hours in the lowest tier, which makes it the phase where a comparison against the aggregate can mislead. Compare against the band for your organization size instead. Enterprise teams above 1,000 employees reach elite deploy time under 25 hours and elite cycle time under 27 hours. Full tables by size are in the 2026 Software Engineering Benchmarks Report.

What to do next: Place each of your six phase values in a band, then rank the phases by how far each one sits from elite. The worst gap is your constraint for the quarter.

AI raised the volume entering the delivery pipeline without changing the pipeline's capacity to review and release, and the 2026 data shows the result at three points. Pull request size grew, with AI-assisted pull requests reaching 408 lines at the 75th percentile against 157 for unassisted work. Waiting grew, with agentic pull requests sitting 17.6 hours before pickup against 3.4 hours. Acceptance fell, with AI pull requests merging within 30 days 32.7% of the time against 84.4% for unassisted pull requests.

Review speed moved in the opposite direction to review depth. Once review starts, AI-assisted pull requests clear in 3.2 hours against 4.2 hours for unassisted work, which means larger changes are being reviewed in less time. LinearB's 2026 AI in Engineering Leadership Survey found reviewer confidence sits low, with 39.4% somewhat confident in AI-generated code quality and 6.4% extremely confident. These relationships are correlational and align with LinearB's qualitative research over the past year.

Review is where the delivery conversation now happens. For the practices that hold up when review volume climbs, see code review best practices. The 2025 DORA State of AI-assisted Software Development report reaches a compatible conclusion, finding that AI amplifies the capability an organization already has rather than creating it, and its companion AI capabilities model sets out the seven capabilities that decide which way the amplification runs.

What to do next: Measure pickup time separately for agentic, AI-assisted, and unassisted pull requests. If agentic pull requests wait longest, the fix is routing and ownership rules rather than reviewer effort.

Efficiency is one of the four pillars in APEX, LinearB's operating model for engineering productivity, and its purpose is to show where work stops rather than how fast it moves. The four steps below apply the pillar to a delivery pipeline. The full model is in the APEX framework.

1. Decompose cycle time into coding, pickup, approve, merge, and deploy. Totals hide constraints, phases expose them.
2. Compare each phase against the benchmark band for your organization size, and record the gap in hours rather than in adjectives.
3. Isolate the phase with the largest gap, then segment it by team, repository, and pull request type to find where the pattern concentrates.
4. Automate the handoff inside that phase, such as reviewer routing, safe-change approval, or labeling, then re-measure after one full sprint.

Order matters in those four steps. Automating before isolating produces rules that fire on the wrong pull requests, and isolating before comparing produces a target with no threshold to hit.

What to do next: Run the four steps on one repository rather than the whole organization. A single pipeline with a proven fix is a better internal case than a broad analysis with no change attached.

Speed without reliable commitments creates a different problem, which is why predictability sits alongside efficiency. Elite planning accuracy runs above 82% and elite capacity accuracy sits between 85% and 115% at the 75th percentile. The 2026 data shows the direction of the common error, with 73.1% of teams under-committing their iteration plans against 14.7% landing in the range where commitments match delivery.

Change failure rate is the guardrail that keeps a cycle time improvement honest, with elite under 1% and the lowest tier above 17%. A cycle time that falls while change failure rate rises is not an improvement, it is a shift of cost into production. For the wider metric set behind both, see the software delivery metrics guide and delivering software predictably.

What to do next: Pair every delivery speed target with change failure rate and rework rate in the same report. Two numbers make the trade-off visible before it reaches production.

Syngenta cut cycle time by 81%. Yum! Brands automated 321 developer hours per month. Expedia Group ran more than 3 million automations, including over 200,000 pull request automations, and reinvested 2,000 developer hours per month. Each result followed the same order, which is measure the phases, isolate the constraint, then automate the handoff instead of asking people to work faster. Workflow automation is where the fourth step happens.

What to do next: Pick the single handoff a human repeats on every pull request in your slowest phase, and automate that one first.

What is software delivery?

Software delivery is the movement of a code change from first commit to running in production, covering coding, review pickup, approval, merge, and deployment. Cycle time measures the total, and the phase breakdown identifies where delay accumulates.

What are the phases of software delivery?

The phases are coding time, pickup time, approve time, merge time, review time, and deploy time. Approve time and merge time together form a granular view of review time, and the sum of the phases is cycle time.

What is a good software delivery cycle time?

Elite cycle time is under 25 hours and good is 25 to 72 hours at the 75th percentile, according to LinearB's 2026 Software Engineering Benchmarks Report. Enterprise organizations above 1,000 employees reach elite under 27 hours.

Why has AI not improved software delivery speed?

AI increased the volume and size of code entering the pipeline without increasing review and release capacity. AI-assisted pull requests run 2.6x larger than unassisted ones at the 75th percentile, agentic pull requests wait 17.6 hours before pickup, and AI pull requests merge within 30 days 32.7% of the time. The constraint moved downstream rather than disappearing.

How do you find a software delivery bottleneck?

Decompose cycle time by phase, compare each phase against the benchmark band for your organization size, isolate the phase with the largest gap, then segment that phase by team, repository, and pull request type. The segment that concentrates the delay is the bottleneck.