Where the hours go: mapping human wait time in a delivery pipeline

A feature took three weeks. Ask the team how much of that was actual work and the honest answer is usually two or three days. The rest was a ticket waiting for a product decision, a pull request waiting for a reviewer, a build waiting for QA, a release waiting for someone with the right permissions to press a button.

AI coding tools attack the two or three days. The three weeks stay. If you want delivery to get faster, you need to see where the other days went, and that means mapping wait time, not just work time.

Lead time is mostly waiting

Lean manufacturing has a name for this: flow efficiency, the share of total lead time in which someone is actually working on the item. In factories and in software, it is routinely low, because each hand-off between people adds a queue.

The survey data points the same way. Atlassian’s 2025 State of Developer Experience report, based on 3,500 developers and managers, found developers spend only 16% of their time coding, and half lose more than 10 hours a week to organisational friction. Faros AI’s 2025 telemetry found that on teams using AI heavily, review time per pull request rose 91%. Coding got faster; the waits around it got longer.

Here is what one feature can look like when you split each stage into work and waiting.

One feature, work vs waiting by stage

• Work
• Waiting for a person

Data as a table

	Work	Waiting for a person
Clarify the ticket	1 h	16 h
Write the code	6 h	2 h
Code review	1.5 h	20 h
Fix review comments	1 h	6 h
QA	2 h	12 h
Release approval	0.5 h	24 h

In this model, an agent that writes the code ten times faster saves about five hours out of 92. Removing the wait in front of release approval alone saves 24.

How to map wait time in your own pipeline

You don’t need a consultant or a tool to do this. You need ten recently finished tickets and an afternoon.

1. List the stages a ticket actually goes through, not the ones in the process document. Include the informal ones, such as “waiting for the designer to answer in Slack”.
2. For each ticket, pull timestamps from what you already have: tracker status changes, pull request events, CI runs, deployment logs.
3. For each stage, split elapsed time into work (someone or something actively on it) and wait (sitting in a queue or on someone’s to-do list).
4. Mark every step that needs a person, and write down what that person actually does there: decide, judge, or just confirm.
5. Add up wait time per stage across the ten tickets. Sort descending.

The top two or three rows of that sorted list are your real backlog. They are almost never “coding”.

Three kinds of human gate

Step 4 is the important one. When you look closely at the gates where work waits for a person, they fall into three kinds.

A decision gate is where a person chooses something nobody else can: what the product should do, whether a trade-off is acceptable, whether to spend money. These are real work. They should stay, but they should come early and be batched.

A judgement gate is where a person assesses quality: code review, design review, exploratory QA. These matter, but much of the judgement can now be done by an independent model with the person sampling or handling only the risky cases.

A confirmation gate is where a person checks that something already true is true: that tests passed, that the build is green, that the ticket matches the template, that a release has its changelog. These are pure wait. A check can do them with better consistency, and nobody needs to wake up for them.

Most teams find that a surprising share of their wait time sits in front of confirmation gates.

A pipeline with fewer people in the middle

Once the gates are sorted, the redesign follows. Decisions move to the start, where they block nothing yet. Confirmation becomes checks. Judgement becomes a machine review first, with a person where the risk is real.

Moving people to the ends of the pipeline

• Person
• Agent
• Automated check

Steps as text

Step	What happens
1. Ticket and criteria	Person — person decides up front
2. Writer agent	Agent — plans and codes in small slices
3. Checks	Automated check — build, tests, criteria commands
4. Reviewer agent	Agent — different model reads the diff
5. Risk router	Automated check — low risk merges on green
6. Person	Person — high-risk changes only
Loop	findings go back: back from step 4 to step 2

The person hasn’t disappeared. They moved to the two places where they add the most: defining what done means, and owning the changes that can hurt users. Everything between those points runs without anyone waiting for anyone. If you want the details of writing criteria an agent can’t argue its way around, see acceptance criteria for AI agents.

Which waits to remove first

Not every wait is worth attacking. Rank them by two questions: how many hours does this wait cost per month, and what does a person actually contribute at this gate? A high-cost confirmation gate is the obvious first target. A low-cost decision gate is best left alone.

Wait	Gate kind	Typical fix
Ticket waiting for clarification	decision	write acceptance criteria before the ticket enters the queue
Pull request waiting for a reviewer	judgement	machine review first, person only by risk class
Review comments waiting for the author	judgement	the writer agent fixes findings immediately
Build waiting for manual QA	judgement and confirmation	checks written from the criteria, QA samples
Release waiting for sign-off	confirmation	release on green for low-risk changes
Work waiting overnight	none	let agents run while people sleep

The last row deserves a note. A pipeline that only moves while people are at their desks wastes roughly two thirds of every day. If the confirmation gates are checks, there is nothing stopping work from progressing at night, and I cover what has to be true before that is safe in running coding agents overnight.

Mistakes teams make when they try this

Automating the work and leaving the waits. Buying a faster coding tool is the easiest purchase to approve and the one with the smallest return. The Amdahl’s law argument explains why.

Removing a judgement gate without replacing it. Dropping code review because it is slow, with nothing independent in its place, swaps a wait for a stream of incidents. The fix is to replace the person with a different check, not with nothing.

Keeping review batch sizes huge. If the machine-written diff is 1,500 lines, the human gate will stay slow no matter what. SmartBear’s study of a Cisco team found defect detection drops beyond 200 to 400 lines at a time.

Measuring activity instead of flow. Pull requests opened and lines written will all look better after AI. Lead time per stage is the number that tells you whether anything improved.

Treating every gate as sacred. Many approvals exist because of one incident years ago. Ask what the person at the gate actually catches. If the answer is “nothing a test couldn’t”, the gate is a candidate.

What this looks like when it’s done

The end state is a pipeline where waits are rare and deliberate. People make decisions at the start, own risk at the end, and are not in the loop for anything a check can prove. Feature lead time drops from weeks to days, not because anyone typed faster but because the work stopped queueing.

That is the real promise of AI in software delivery, and it is mostly an exercise in process design rather than model choice. If you want help mapping your own pipeline and deciding which gates to automate first, write to me.

Questions

What is human wait time in software delivery?

It is the time a ticket or pull request spends waiting for a person to answer, review, test or approve it, as opposed to time anyone spends working on it. In most teams it is the largest part of lead time.

How do I find the bottleneck in my delivery pipeline?

Take ten finished tickets, split each stage’s elapsed time into work and waiting using tracker and pull request timestamps, and sort stages by total wait. The top rows are your bottlenecks.

Which approval steps can be automated safely?

Steps where a person only confirms something a check can prove, such as passing tests, a green build or a complete changelog. Steps where a person makes a product or risk decision should stay human, but can be moved earlier and batched.

What is flow efficiency in software development?

It is the share of total lead time in which someone is actively working on an item. A low flow efficiency means most of the time is spent in queues, so removing waits helps more than speeding up the work.