Khrystyna Dzhus

Posted on Jul 21

Your Jira Workflow Is Generating Data You’re Probably Ignoring

#jira #agile #productivity #programming

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.