Delivery
Finding delivery bottlenecks with lead time and cycle time.
When work slows down, the cause is rarely where people first point. I use lead time, cycle time and a few flow metrics to find exactly where stories get stuck, check the pattern over several sprints, and confirm the root cause with the engineers before changing anything. AI tools make the analysis faster, and they also create a new bottleneck to watch. On my own team, it moved from clarifying requirements to code review.
Lead time is how long a request takes from the moment it is asked for until it is delivered. Cycle time is how long it takes once someone starts working on it. A big gap between them means work is waiting, not being worked on. Measure both per stage, confirm the pattern with the team, change one thing, and measure again.
Four numbers that describe flow
| Metric | What it measures |
|---|---|
| Lead time | From request to delivery, including all the waiting |
| Cycle time | From starting work to delivery |
| Work in progress (WIP) | How many items are open at the same time |
| Throughput | How many items are finished per week or sprint |
They are connected. Little's Law says that, on average, cycle time equals work in progress divided by throughput. In practice: if a team starts more work than it finishes, everything takes longer, even if everyone is busy. Reducing work in progress is often the fastest way to speed up delivery.
A fifth number, flow efficiency, is the share of cycle time when someone is actively working on an item. On many teams it is surprisingly low, because most of the time is spent waiting for review, testing, a decision or another team.
The five steps
- Measure both times for every story. Break cycle time into the stages of your workflow, such as in progress, in review, in testing and waiting to deploy.
- Find the deviation. Look for the stage where time grows most compared with normal.
- Check it is a pattern. Compare across the sprint or release. One slow story is noise; the same stage slowing down every sprint is a bottleneck.
- Talk to the engineers involved. The data shows where; people explain why. Common causes are dependencies on other teams, unclear requirements and slow code reviews.
- Change one thing and measure again. Adjust priorities, the workflow or the review process, then check whether the numbers move.
Common causes and fixes
| Where time grows | Likely cause | What usually helps |
|---|---|---|
| Before work starts | Unclear requirements | Refine stories with product before the sprint, with clear acceptance criteria |
| In progress | Waiting on another team | Surface dependencies in planning, agree on API contracts early |
| In progress | Too much work in progress | Set WIP limits and finish work before starting more |
| In review | Reviews pile up | Smaller pull requests, agreed review times, AI-assisted first-pass review |
| In testing | Manual testing | Automated tests in CI, with AI assistants helping write them |
Where AI helps, and the new bottleneck it creates
AI tools help at both ends of this process:
- Analysis. Export your ticket history from Jira or your pull request data from GitHub, and an AI assistant can compute time per stage, spot outliers and suggest patterns in minutes. Treat its findings as hypotheses to check, not conclusions.
- Fixes. AI coding assistants help write the missing tests, and AI review tools can do a first pass on pull requests, so human reviewers focus on design and risk.
But when a team adopts AI coding assistants, writing code gets faster, and more of it arrives at review and testing at once. The bottleneck moves downstream. If cycle time doesn't improve after adopting AI, look at the review and testing stages first. The fix is usually smaller pull requests, clear review expectations and better automated testing, not more code generation.
Where the bottleneck moved on my team
At Cedar Planters we have a small team with a lot of experience. We still work in Scrum, and we now use AI throughout the process: Claude, Visual Studio Code and open-source models. One of the most useful changes was in Jira itself. We use AI to pull the details scattered across emails and Slack threads into the Jira tasks, so each story carries its full context instead of a one-line title.
| When | Where work waited most |
|---|---|
| Before AI | Clarifying requirements, and testing |
| After AI | Reviewing pull requests that had grown much bigger |
Richer tasks meant less back-and-forth before work could start, and the assistants made writing code faster. But the pull requests grew, and reviewers had to check everything at once. We don't skip that step: keeping a human in the loop is what makes AI-written code safe to ship. So the time moved from the start of the process to the review.
We noticed it through complaints in stand-ups and retrospectives, which is a reminder that the team often feels a bottleneck before a dashboard shows it. We are still working on it, adjusting our agile practices and our AI tools, with the goal of bringing everything together into one workflow. If you see the same pattern, the review row in the table above is where I would start.
Why validate with people
Numbers without context lead to the wrong fix. A long review stage might mean reviewers are overloaded, or that pull requests are too big to review, and each needs a different change. Asking first keeps the fix targeted and keeps the team's trust.
See the full set of metrics I track: How I measure engineering team health.
Get my next case studies and articles in Google Search.