The Anatomy of Bottlenecks: Code Review vs. Testing

[#1]

If you’re an Engineering Manager, Delivery Manager in a software product team, you’ve probably seen this argument before:

“Delivery slowed down because the review took too long.”
“No, QA became the bottleneck.”
“Actually, dev finished on time — the handoff broke.”

The problem is that Jira workflows show where work is now, but not always where delivery time was actually lost.

Why is this bottleneck so hard to manage?

For most software teams, Code Review and Testing look similar from the outside: the ticket is moving, but not done yet.

In practice, they are very different bottlenecks.

A review bottleneck usually points to reviewer capacity, unclear ownership, rework, context switching, or approvals that depend on a small number of senior engineers.

A testing bottleneck usually points to QA bandwidth, unstable environments, regression load, missing acceptance criteria, or release-readiness issues.

If you only watch total Cycle Time, both problems get blended into one number. That makes retros vague and process fixes reactive. You end up debating symptoms instead of fixing the actual handoff.

A real use case

In many software product teams, the workflow often looks like this

In Progress → Code Review → Validation / Testing → Done

On paper, the workflow looks healthy. But in reality:

• some tickets move through review in hours, while others sit for days;
• some items enter testing and finish quickly, while others linger before release;
• sprint commitments start slipping, but nobody can clearly prove whether the delay lives in review or QA.
  
  

That is the real pain.

You are responsible for predictability, but you do not need another generic dashboard. You need evidence strong enough to answer questions like:

• Are reviewers overloaded?
• Is QA becoming a queue?
• Are a few outliers distorting the whole sprint?
• Is the problem systemic or team-specific?

That is exactly where Time Metrics Tracker|Time Between Statuses becomes useful.

Time Metrics Tracker is built to measure how long Jira work items spend moving between specific statuses, not just how long they exist in the workflow overall. The app supports custom transition-based metrics, work schedules, warning and critical thresholds, export, and dashboard visualizations such as Agile Metrics Gadget and Scatter Plot. It can be used for metrics like Time in QA, Review Lag, or any custom handoff you want to measure.

That matters because the question here is not just “How slow are we?”
It is: “Is the real bottleneck in Code Review or in Testing?”

How to set up “Code Review vs. Testing” in practice

Open Time Metrics Tracker, go to the app’s configuration area, create a new time metric, choose the project, apply a work schedule, and then define the status transitions you want to measure. Work schedule settings can include working days, time zone, hours, breaks, and holidays, so the final numbers reflect actual working time rather than raw calendar time.

 

1) Create a Review Time metric

• Metric name: Review Time
• Start status: Code Review
• Stop status: In QA, Testing, Validation, or Ready for Testing
• Optional pause statuses: Blocked, On Hold, Waiting for Author, or any status where review is intentionally paused
• Warning / Critical limits: start with your review SLA

This isolates the time work spends in the review stage — from entering Code Review to moving into QA, Testing, or Validation. As an example, you might start with a simple SLA such as: “Review Time should stay under 5 days.

2) Create a Testing Time metric

• Metric name: Testing Time
• Start status: In QA, Testing in Progress, or Validation
• Stop status: QA Passed, Ready for Release, Done, or Rejected
• Optional pause statuses: On Hold, Waiting for Environment, Waiting for Requirements
• Warning / Critical limits: match your team’s testing SLA
  
  

3) Keep one anchor metric for context

To make the comparison useful, also keep one broader delivery metric in the same view, for example:

• Cycle Time: In Progress → Done

This helps you answer a more strategic question: Are review and testing the true drivers of end-to-end delay, or are they just where the delay becomes visible?

 

How the app helps you see the difference

Once those metrics are configured, the most practical setup is to use the two dashboard gadgets together.

Agile Metrics Gadget gives you a detailed table view of the selected metrics and lets you configure the view by project, work item type, status, assignee, sprint, label, works filter, date range, and time format.

Scatter Plot Gadget visualizes work items as dots over time for a selected time metric, helping teams detect trends, anomalies, and outliers.

Together, they answer two different questions:

• the Agile Metrics Gadget tells you which work items are slow;
• the Scatter Plot Gadget tells you whether the slowness is isolated or systemic.

Why is this better than a generic Jira report?

A generic report can tell you that work is slow. But it usually does not tell you which handoff is damaging predictability.

Time Metrics Tracker is useful here because it is built around transition-based metrics, work schedule-aware calculations, threshold-based highlighting, and Jira dashboard visualizations that help teams spot bottlenecks and slow-moving work before they become release problems. 

Final thought

For software delivery teams, the most frustrating bottlenecks are rarely the loudest ones. They are the hidden handoffs that quietly stretch delivery time until a sprint slips or a release gets delayed.

Code Review and Testing may both look like “work is still moving,” but they create very different types of delay — and they need different fixes.

If this sounds like your workflow, try the free trial of Time Metrics Tracker. Start with just two custom metrics — Review Time and Testing Time, and you will quickly get a much clearer answer to where your delivery bottleneck actually lives.

🔐 Built on Atlassian Forge – secure, compliant, and permission-aware