Time in Status: Why Workflow Metrics Become Confusing — and Why Raw Data Is the Only Truth

[#1]

If you work with Jira long enough, you’ll repeatedly hear terms like Cycle Time, Lead Time, and even “Time Between Statuses.”
Agile literature offers conceptual definitions, but when these ideas hit real Jira workflows with many statuses and many local conventions, the meaning of any metric becomes determined almost entirely by:

Which statuses you choose to include or exclude.

This is why two companies can both claim to measure "Cycle Time" while calculating completely different things.

Instead of starting from terminology, the most reliable approach is to start from what Jira actually records:

An issue always has exactly one status. The key questions are:
– How long did it have that status?
– How many times did it have that status?

Everything else is a derived metric.

---

1. Why “Cycles” Are Volatile in Real Jira Setups

Standardizing workflows looks attractive in theory, but in practice:

• teams add their own statuses,

• Company-managed and Team-managed projects coexist,

• workflows diverge over time,

• one team’s “In Progress” equals another team’s “Dev + Review + Testing.”

Large enterprises that tried to enforce uniform workflows through committees still ended up allowing exceptions — because work patterns differ.

So when we say “Cycle Time” in Jira, what we are really saying is:

“The sum of the time spent in whichever statuses this particular team considers part of the cycle.”

There is no universal cycle.
There are only team-defined cycles.

---

2. Lead Time and Cycle Time Depend Entirely on Status Choices

Conceptually:

• Cycle Time = time from when work actually starts until work is finished.

• Lead Time = time from when the request appears until the requester receives or accepts the result.

But in Jira, both depend on which statuses you choose.

A more practical framing for Jira is:

Lead Time =     Time before work starts   + Cycle Time   + Time until the requester receives or accepts the result

And each of these segments corresponds to different sets of statuses.

Because workflows differ, the same named metric produces different results across teams and tools.

---

3. The Misleading Idea of “Time Between Statuses”

An issue is always in a status.
There is no literal “between.”

When tools say “time between statuses,” they usually mean:

“Time in statuses that this calculation treats as outside the main cycle.”

Examples:

• Backlog excluded from some Cycle Time definitions

• “Waiting for Customer” excluded from Lead Time

• QA included or excluded depending on team culture

This terminology makes simple filtering look like a sophisticated formula.
In reality, it is just adding and excluding statuses.

---

4. The Only Solid Foundation: Raw Time-in-Status Data

Instead of relying on vague cycle definitions, the cleanest and most accurate approach is:

1. Determine every status the issue has had over its life.

2. Calculate the total time it had each status, across all occurrences.

3. Count how many times the issue entered each status.

From there, every meaningful metric is simply a sum of the statuses your team selects:

• Cycle Time = sum of work statuses

• Lead Time = sum of all statuses from request to delivery

• Wait Time = sum of statuses representing blocked or idle time

• QA Cycle = sum of QA/UAT statuses

• Rework = statuses where the issue appeared multiple times

Simple math.
Complexity comes only from deciding which statuses matter.

---

5. How Time in Status Dashboard for Jira Enables This Approach

Time in Status Dashboard for Jira, a Forge App developed by our company, is designed around one principle:

Provide clean time-in-status data, and let teams define their own cycles.

It presents data in two formats:

---

Columns Format (One Row per Issue)

Each status is represented by:

• Time in Status (total)

• Times in Status (loop count)

Ideal for:

• building Cycle Time, Lead Time, Wait Time

• grouping statuses with Excel formulas

• comparing teams or projects

• identifying rework tendencies immediately

---

Rows Format (Normalized Issue–Status View)

Each row = one issue + one status, aggregated over the issue’s life:

• Total Time in the Status

• Number of Times in the Status

Ideal for:

• pivot tables

• grouping statuses into cycles

• discovering patterns

• sending structured data to AI for analysis

This export focuses strictly on status behavior, which is the foundation for all cycle metrics.

---

6. Practical Excel Examples

Cycle Time (your Work Time):

=SUM(F2:H2)

Lead Time (Request → Delivery):

=SUM(B2:H2)

Wait Time:

=SUM(C2:D2)

Rework:
A status with:

Times in Status > 1

indicates back-and-forth activity.

---

7. Why Loop Counts Matter (and Why They Reveal Hidden Problems)

Two issues can have the same total Cycle Time but behave completely differently.

Example:

• Issue A entered In Progress once

• Issue B entered In Progress four times

• Both spent 10 hours in total in that status

They look identical if you only look at time.
But they are not identical in process quality.

Multiple transitions into the same status can indicate:

• requirements not being clear or ready,

• interruptions in development,

• testing sending the item back repeatedly,

• inconsistent acceptance criteria,

• general workflow instability.

The interpretation depends on how the team defines its cycle —
but the signal itself is priceless.

Time alone cannot reveal rework.
Loop counts do.

This is why the "Times in Status" column is one of the most powerful metrics your app exposes.

---

Conclusion

Lead Time, Cycle Time, and similar terms are useful concepts — but in Jira, their values depend entirely on:

Which statuses your team includes in each calculation.

Workflows differ.
Teams differ.
Cycles differ.

The only universal truth is:

A Jira issue always has a status.
If you know how long it had that status and how many times,
you can build any metric your team needs.

Time in Status Dashboard for Jira provides exactly that foundation — in two practical formats — enabling teams to define cycles and metrics that reflect how they actually work.

In the next article, we will explore how to construct your own cycle definitions using simple Excel formulas or AI prompts.

[Petru Simion _Simitech Ltd__]

Thanks everyone for reading. In a follow-up article I’ll go deeper into the practical side: how teams can group statuses into their own cycles and derive metrics like Cycle Time, Lead Time, QA Cycle, or Wait Time using simple Excel formulas or pivot tables. The idea is to show how flexible and transparent these calculations become when you start from raw status durations instead of predefined interpretations.
More on that soon.