DEV Community: Khrystyna Dzhus

[Boost]

Khrystyna Dzhus — Mon, 24 Aug 2026 12:51:08 +0000

Khrystyna Dzhus

Aug 24

Your Developers Are Coding Faster. So Why Is Delivery Still Slow?

#ai #webdev #programming #productivity

9 min read

Your Developers Are Coding Faster. So Why Is Delivery Still Slow?

Khrystyna Dzhus — Mon, 24 Aug 2026 12:27:23 +0000

More and more developers are using AI assistants to write code. With these tools, teams can move from an idea to implementation much faster than before. Logically, overall delivery should speed up as well — but often not as much as we would expect.

A team might reduce implementation time by 30% or even 50%, while the time it takes for a feature to actually reach production changes only slightly.
The reason is that other stages of the workflow — waiting for code review, QA, testing, approvals, and release — do not automatically speed up just because coding does.

That’s why it’s important to ask: if AI has significantly accelerated coding, why isn’t overall delivery time improving at the same pace?

Coding time is only one part of delivery time

Let’s imagine a typical workflow in a development team:

To Do → Development → Code Review → Awaiting QA 
→ Testing → Ready for Release → Done

By breaking down the time in the status in more detail, you can see the following picture:

2 days in Development
2 days waiting for review
3 days waiting for QA
1 day in Testing
2 days waiting for release

Development time: 2 days. Total delivery time: 10 days.

With AI becoming part of the development process, it’s entirely possible to cut implementation time in half. In our example, that means cutting it from 2 days to 1.

That's a 50% improvement in Development.

But if everything else stays the same, the total delivery time drops from 10 days to 9, which is only a 10% improvement.

The team really did get faster at writing code — the improvement just happened in one part of a much larger delivery system.

Faster coding can expose the next constraint

Think of the workflow as a sequence of stages, each with its own capacity.
When Development becomes faster, more work can reach downstream stages sooner.

If Code Review, QA, Testing, or Release have enough capacity to absorb that work, delivery improves.

If they don't, some of the productivity gain turns into queue time.

The delay hasn't necessarily disappeared. Part of it has moved downstream.
That can show up in several places.

Code Review. Developers open PRs faster, but reviewer availability stays the same. Development gets shorter while the review queue gets longer.
QA. More work becomes ready for QA, but QA capacity, test environments, and test data haven't changed. Items begin to accumulate in Awaiting QA.
Testing. More changes reaching Testing can increase regression scope, environment contention, or coordination work.
Release. The feature is implemented and tested but still sits in Ready for Release, Approved, or Pending Deployment, waiting for a release window, approval, dependency, or another team.

This doesn't mean faster coding is useless.

It means the next opportunity for improvement may no longer be in Development.

Don't measure the stage you optimized in isolation

Suppose a team starts using AI coding tools and sees this:

Before
Development: 4.0 days

After
Development: 2.0 days

A 50% reduction looks impressive.

And it is.

But now look at the full path.

Before
Development 4.0 days Code Review 1.0 day Awaiting QA 1.5 days Testing 1.5 days Ready for Release 2.0 days

Total: 10 days

After
Development 2.0 days Code Review 1.5 days Awaiting QA 2.0 days Testing 1.5 days Ready for Release 2.0 days

Total: 9 days

Development improved by 50%.

Overall delivery improved by 10%.

That's still a real improvement. But it tells a very different story from looking at Development alone.

It also gives the team a much better question to investigate:

What is limiting the other 90% of the delivery path?

Overall cycle time isn't enough either

Looking only at Development can hide downstream delays.

But looking only at total cycle time has the opposite problem: it tells you that delivery is slow without telling you why.

Suppose your average cycle time is 11.5 days.

That gives you the end-to-end number.

But those 11.5 days might consist of very different things:

Active Development Code Review Waiting for QA Testing Blocked time Approval delays Waiting for deployment

Each one has a different cause and a different fix.

So if you want to understand why delivery isn't improving as quickly as coding productivity, you need to break the total down by workflow stage.

Break delivery time down by status

Here's an example for 50 recently completed Jira work items:

Workflow stage Average time Development 1.8 days Code Review 1.2 days Awaiting QA 3.4 days Testing 1.5 days Ready for Release 2.7 days

Development takes 1.8 days.

Awaiting QA and Ready for Release together take more than six.

At this point, reducing Development from 1.8 days to 1 day would certainly help.

But it would not transform delivery.

The bigger questions are:

Why does work spend 3.4 days waiting for QA?
and:

Why does tested work spend another 2.7 days waiting for release?

That's where the difference between developer productivity and delivery performance becomes visible.

How to check this in Jira

Jira already stores the underlying history.

Every status transition is recorded in the issue changelog with a timestamp.

The challenge is aggregation. Looking at the history of one issue tells you what happened to that issue. It doesn't tell you whether the same pattern exists across a sprint, release, project, or team.

There are two basic approaches.

1. Build the calculation yourself.

For individual issues, Jira provides:

GET /rest/api/3/issue/{issueIdOrKey}/changelog

For multiple issues, you can use:

POST /rest/api/3/changelog/bulkfetch

From there, you can extract status transitions and calculate how long each item stayed in each status.

The basic calculation isn't especially complicated. The edge cases are.

You also need to decide how to handle:

non-working hours
weekends and holidays
work items that enter the same status multiple times
open items that haven't completed yet
different work schedules
outliers

2. Use a Time in Status report.

Another much simpler way is to use Time in Status app by SaaSJet.

It aggregates Jira status history across multiple work items and shows how much time they spend in different workflow stages without requiring you to calculate the changelog manually.

Whichever approach you use, the analysis itself matters more than the tool.

Start with a meaningful comparison

If you're trying to understand whether faster Development is translating into faster delivery, don't just compare one sprint with another randomly.

Use comparable periods or groups of work.

For example:

several sprints before and after introducing AI tooling
similar releases
the same team over two comparable periods
similar issue types or work categories

For cycle-time analysis, completed items give you a defined start and endpoint.

But don't ignore current WIP entirely.

If ten open tickets have already been sitting in Awaiting QA for two weeks, excluding them can make your completed-item numbers look healthier than the process really is.

Use completed work for consistent cycle-time comparisons, then inspect long-running open work separately.

Look at average and median together

Status-duration data is rarely perfectly distributed.

Imagine most work items spend one or two days waiting for QA, while three items wait for two weeks.

The average can move dramatically.

The median may barely move at all.

So don't rely on one aggregate.

If average and median are close, the pattern may be relatively consistent across the sample.

If they're far apart, investigate the underlying items. You may be seeing a small number of long-running cases, different types of work behaving differently, or a genuinely uneven process.

The aggregate tells you where to look.

It doesn't automatically tell you why.

Separate active time from waiting time

This distinction becomes especially useful as coding gets faster.

Compare:
Development: 2.5 days

Awaiting QA: 2.0 days

The numbers are similar.

Their meaning can be completely different.

Two and a half days in Development may represent active work.

If your workflow uses Awaiting QA as a true queue state, two days there represent time before QA begins.

Reducing active execution time through better tools, automation, or AI is useful.

But once waiting becomes a significant share of total cycle time, further optimizing execution produces diminishing returns unless the queues improve too.

That's why a useful metric to watch is the relationship between:

active time / total delivery time

and:

waiting time / total delivery time

If Development gets faster but waiting consumes a larger percentage of the cycle, you know where the next constraint is appearing.

Check whether the delay is systemic

Finding one status with a large number isn't enough.

Suppose Awaiting QA averages 3.4 days.

Before concluding that QA is the bottleneck, ask:

Is the wait high for most items?
Is the average being driven by a few extreme cases?
Does the pattern appear across several sprints?
Is one team responsible for most of it?
Is it concentrated in certain issue types?
Did the queue begin growing after Development throughput increased?

The answers matter.

A consistent three-day QA wait across most items suggests one kind of problem.

Five items waiting two weeks while everything else flows normally suggests another.

The longest status gives you a place to investigate.

It isn't automatically the bottleneck.

Compare the whole flow before and after

This is where you can see whether local productivity improvements are translating into system-level gains.

Imagine the following.

Before
Development 3.5 days Code Review 1.0 day Awaiting QA 1.2 days

After
Development 2.0 days ↓ Code Review 1.8 days ↑ Awaiting QA 2.6 days ↑

Development improved by 1.5 days.

Review and QA became 2.2 days slower.

In this example, total delivery time actually increased.

That doesn't prove AI caused the downstream slowdown. Workload, team composition, scope, release policies, or other factors may have changed too.

But it immediately tells you something important:
the gain in Development did not translate into a gain for the whole delivery system.

In another team, the result might look like this:

Development 3.5 → 2.0 days Code Review 1.0 → 1.1 days Awaiting QA 1.2 → 1.2 days

Now total delivery really did improve.

The point isn't that faster coding never improves delivery.

It does.

The point is to measure how much of that improvement survives the rest of the workflow.

What to investigate when the gain doesn't carry through

Once you know where the additional time sits, the investigation becomes much more concrete.

Code Review is growing

Look at:

reviewer availability
PR size
code ownership
how reviews are distributed
review policies
context switching

If developers produce changes faster than reviewers can absorb them, review becomes the new constraint.

Awaiting QA is growing

Look at:

QA capacity
handoff rules
environment availability
test data
automation coverage
work arriving in batches at the end of the sprint

Testing is growing

Look at:

regression scope
flaky tests
environment setup
unclear acceptance criteria
dependencies between changes

Ready for Release is growing

Look at:

deployment frequency
release batching
approval steps
change windows
cross-team dependencies

The goal isn't to move optimization away from Development permanently.

It's to improve the stage that currently limits the whole system.

Measure productivity where the customer feels it

AI coding tools can produce meaningful productivity gains.

But implementation speed is not the same thing as delivery speed.

If Development falls from four days to two, that's worth measuring.

Then ask what happened to the rest of the workflow.

Did total cycle time fall by two days?
One day?
Half a day?
Did the gain disappear into Review or QA queues?
Did throughput increase?
Did more work actually reach production?

Those questions show whether a local productivity improvement became a delivery improvement.

So instead of asking only:

Are developers coding faster?

Ask:

How much faster is work reaching the customer?

And if the answer is “not nearly as much as Development improved,” the next step isn't necessarily to make developers even faster.

It's to find where the rest of the time is going.

The takeaway

Faster coding should make delivery faster.

But the relationship isn't one-to-one.

If Development represents only part of your total cycle time, a 50% improvement in Development cannot automatically produce a 50% improvement in end-to-end delivery.

And as Development gets faster, Review, QA, Testing, and Release become a larger share of the remaining delivery time.

That's why the real productivity question isn't:

How much faster can we write the code?

It's:

How much faster can we move work through the entire system?

Because that's the improvement the customer actually experiences.

Your Jira Workflow Is Generating Data You’re Probably Ignoring

Khrystyna Dzhus — Tue, 21 Jul 2026 11:11:04 +0000

The ticket went to Done in 12 days. That seems like the most important fact.

But it isn’t.

The total duration tells you that the work was slow. But it doesn’t tell you what was actually happening during those 12 days.

Was the issue technically difficult?
Was the developer overloaded?
Did testing take too long?
Was the ticket blocked?
Or was it simply sitting idle?

These differences matter because each explanation points to a completely different problem.

And the data needed to understand that problem already exists in your Jira workflow.

Before Looking at the Data, Make a Guess

Imagine this ticket:

PROJ-184
Bug: Users cannot update billing details

Started: Monday, June 1
Completed: Friday, June 12
Total cycle time: 12 calendar days

What is your first assumption?

A. The bug was technically difficult
B. The developer had too much work
C. QA became the bottleneck
D. The ticket spent most of its time waiting

Without more information, all four explanations are plausible.

That is the problem with looking only at total cycle time.

A 12-day ticket could represent 12 days of difficult engineering work. Or it could represent two days of work surrounded by ten days of queues, handoffs, and waiting.

The final number does not tell you which one happened.

The First Breakdown Changed the Story

Now let’s break those 12 days down by workflow stage.

Workflow stage	Time spent
In Progress	2d 3h
Waiting for Review	3d 6h
Code Review	5h
Changes Requested	1d 2h
Waiting for QA	2d 4h
QA	6h
Ready for Release	1d

The ticket was not actively developed for 12 days.

It spent more time waiting for review than it spent in development.

It spent more than two additional days waiting for QA.

The review itself took only five hours. QA took six.

The slowest parts of the workflow were not necessarily the parts where people were actively working.

They were the queues between them.

That creates a very different story:

The ticket was not primarily delayed by execution. It was delayed by waiting and re-entry.

This is where Time in Status becomes useful.

Instead of treating delivery as one large block, it shows how that block was distributed across workflow stages.

Cycle time tells you that delivery was slow.

Time in Status helps explain where it was slow.

“Why Did This Take 12 Days?” Was the Wrong Question

The original question was:

Why did this ticket take 12 days?

But after seeing the breakdown, better questions appear:

Why did review begin more than three days after development finished?
Was a reviewer assigned when the issue entered the queue?
Why did the ticket return to development?
Did the team have enough information before starting the work?
Why did QA begin more than two days later?
Why did the completed ticket wait another day for release?

The metric did not give the root cause.

It gaves something more useful first: a better place to investigate.

That is an important distinction.

Good metrics do not always give you an answer. Sometimes their real value is showing that you were asking the wrong question.

Looked at the Path, Not Just the Duration

Duration alone still does not show the full picture.

The ticket did not move cleanly from development to review to QA.

Its actual path looked like this:

First pass:
In Progress → Waiting for Review → Code Review → Changes Requested

Second pass:
In Progress → Waiting for Review → Code Review → Waiting for QA → QA → Ready for Release → Done

The Code Review status itself was not especially long.

But the ticket entered the review flow twice.

That meant it also entered the review queue twice.

A report that showed only “Code Review: 5 hours” could make the review stage look healthy.

The transition path tells a different story.

The issue returned to development, then waited again.

This is why status duration becomes more useful when combined with status and transition counts. Time in Status reporting can show not only how long work remained in a status, but also how often it entered statuses or moved between them.

A repeated transition does not automatically mean something went wrong.
Iteration is normal.

A reviewer may catch an important problem. QA may return a ticket because the acceptance criteria were incomplete. Requirements may legitimately change.

But repeated movement is a signal.

It gives the team a reason to ask:

Are pull requests too large?
Are requirements unclear?
Are developers entering review before checks are complete?
Does the Definition of Done match what reviewers expect?
Is the same type of rework happening repeatedly?

One loop is a story. A recurring loop across dozens of tickets is a process pattern.

A Jira Workflow Is Full of Queues

When a system slows down, engineers do not look only at the final response time. They trace where latency accumulated, check queues, examine retries, and identify slow or failing dependencies.

A delivery workflow can be analyzed in much the same way. A ticket waiting for review is work sitting in a queue, a return from Review to In Progress is a retry, an assignee change is a handoff, and a blocked ticket often points to an external dependency.

Yet delivery is often judged using only two numbers: how many tickets reached Done and how long they took overall. Those numbers describe the outcome, but they do not explain where the delay came from.

A ticket may have a cycle time of 12 days while only two of those days were spent in active development. The rest may have accumulated in review queues, QA waiting, rework, or release approval.

Looking at the workflow as a system changes the question from:

Why is this team slow?

to:

Where is work accumulating faster than it can move forward?

That is a much more useful place to start.

The Three Views You Should Use

When looking at workflow data, these three views are especially useful.

1. Duration

How long did the issue remain in each stage?

This can reveal:

long review queues;
prolonged blocked periods;
slow approvals;
release delays;
inconsistent QA time.

Duration tells you where time accumulated. But it does not always tell you why.

2. Re-entry

How many times did the issue return to the same stage?

This can reveal:

rework;
failed reviews;
unclear requirements;
repeated QA failures;
workflow loops.

A status that appears short may still create a large delay if the issue repeatedly returns to it.

3. Handoffs

How often did ownership or responsibility change?

This can reveal:

ticket ping-pong;
unclear ownership;
external dependencies;
missing expertise;
context loss.

Reassignment is not inherently bad. Complex work often requires collaboration.

The pattern worth investigating is repeated reassignment without meaningful progress.

Together, these three views provide more context:

A long duration tells you where to look. Re-entry and handoffs help you understand what kind of problem may be hiding there.

But “Long” Does Not Automatically Mean “Bad”

Time in Status data needs context.

A long security review may be appropriate for a high-risk change.

A support ticket may spend several days waiting for a customer response.

A release item may remain ready for deployment because the team follows a fixed release schedule.

A task may stay in QA because the test environment is unavailable.
The duration is evidence, not a verdict.

It should not be used to declare that a team, reviewer, or individual is slow.

It should be used to ask what conditions produced the delay.

The same principle applies to averages.

A single old or blocked ticket can distort the average time for an entire status. Median values and outliers may provide a better picture of what is typical, especially when the data is skewed. Time in Status guidance distinguishes between averages and medians for this reason.

The goal is not to turn workflow analytics into employee surveillance. The goal is to move the conversation from:

Who is slow?

to:

Where is the system slow?

What You Should Investigate Next

For this specific ticket, you should not redesign the entire workflow. You should start with six questions.

1. Why was there a three-day delay before the first review?

Was no reviewer assigned?
Was review treated as secondary work?
Did work arrive in a large batch?

2. What caused the Changes Requested transition?

Was it a bug, missing requirement, style issue, or architecture concern?

Different causes require different fixes.

3. Could the issue have been checked before entering the review queue?

Would a checklist, automated test, or smaller pull request have prevented the return?

4. Why did the ticket wait for QA?

Was QA overloaded?
Was the environment unavailable?
Did the team use a batch handoff?

5. Why did the issue wait after QA?

Was the delay caused by release policy, approval, or unclear ownership?

6. Is this a one-off ticket or a recurring pattern?

This is the most important question.

One ticket may simply be unusual.

If 40% of completed tickets wait three or more days for review, that is a process issue.

One ticket can produce a hypothesis. A larger dataset can confirm whether the pattern is real.

One Ticket Is a Story. Twenty Tickets Are a Pattern.

The next step is to stop looking at one issue and compare a group of recently completed tickets.

Start examining:

median waiting time before review;
average time in active review;
number of returns from review;
waiting time before QA;
blocked duration;
assignee changes;
extreme outliers.

A useful exercise is to ask the team for its prediction before opening the report:

Where do you think work spends the most time?
People may say development.
The report may show review queues.
Or release approval.
Or waiting for customer feedback.

The gap between perception and data is often the most interesting part of the analysis.

Time in Status can calculate durations for individual workflow stages, compare them across issues, and group statuses into broader metrics such as cycle time and lead time.

Working calendars also matter. A ticket that entered review on Friday and left on Monday may show nearly three calendar days, although the team worked only a few business hours. Time in Status calendars can exclude weekends, holidays, breaks, and non-working hours when calculating durations.

Without that context, two teams may appear to have different performance simply because they use different schedules.

Try the Same Investigation

Open one Jira ticket that took longer than expected.

Do not start by asking who worked on it.

Ask three questions:

Where did it wait?
Where did it move backward?
Where did ownership change?

Then check whether the same pattern appears in ten or twenty other completed tickets.

You may discover that the slowest part of delivery is not coding.

It may be the queue before review.

It may be repeated rework.

It may be a forgotten approval.

It may be a handoff nobody owns.

Your Jira workflow is already generating these signals.

You may simply be looking at the final status instead of the journey that produced it.

What is the longest queue in your workflow: review, QA, approval, or release?