Your Jira board can show where time accumulates. It cannot tell you why.

A delivery review opens with a familiar chart. Cycle time has risen. The board shows tickets sitting in “In Progress” for days, so the proposed remedy seems obvious: ask engineers to close work faster.

That conclusion outruns the data.

A ticket can remain in the same state while someone codes, waits for a review, answers an incident, needs a product decision, or simply forgets to update the board. The timestamp measures elapsed time between recorded transitions. It does not observe effort, attention, or cause.

This distinction matters because the intervention depends on the mechanism. More focus may help interrupted work. It will not shorten an approval queue. Smaller batches may reduce review delays. They will not resolve a missing specialist. A cleaner dashboard can make the picture easier to read while leaving the constraint untouched.

State history is still useful. Treat it as a map for investigation, not a verdict.

State-transition data can locate long elapsed states, but it cannot establish that the time was waiting or explain its cause. Validate workflow semantics, inspect one candidate delay with the team, and test one system-level change before interpreting the metric.

First, decide what the clock means

Before calculating flow efficiency, take one service and write down its clock. What event starts cycle time? What event finishes it? Which work belongs in the service, and which items follow a different policy?

Then translate each workflow state into an operational meaning. This is harder than matching “In Progress” with active work and everything else with waiting. A development state may contain coding, blocked time, handoffs, and interruptions. A review state may contain both active review and a queue before the reviewer begins.

If the data cannot distinguish those periods, say so. You can still measure elapsed state duration. You cannot honestly label all of it touch time or waiting time.

Direct software evidence supports this caution. Coremans et al. (2023) reconstructed workflows from Jira histories across 24 teams in one large company. The method exposed differences in the paths followed by teams and work types, along with states where issues remained for a long time. It also found automated transitions that did not always work as intended.

The study shows that issue histories can reveal the process actually recorded rather than the tidy workflow people expect. It does not show that every status accurately represents the work being done. Local semantics and data hygiene are part of the measurement system.

A long state duration is a location, not an explanation

Once the clock is defensible, build a state-duration map. Use distributions rather than one average. Look for states that accumulate substantial elapsed time, items that age far beyond the usual range, and paths that behave differently for distinct service policies.

The longest elapsed state tells you where to look. It does not tell you whether the time was active work, waiting, interruption, or stale recording.

That warning is consistent with a systematic review by Ali et al. (2025). Across the process-mining literature, waiting time has been defined and measured in different ways. The authors found a fragmented field with limited empirical validation of integrated methods that distinguish several causes at once.

One useful causal vocabulary comes from Lashkevich et al. (2024). Their event-log method separates waiting linked to batching, resource contention, prioritization, resource unavailability, and factors not visible in the data. This is a more productive starting point than calling every delay “slow execution.”

But it is not an automatic diagnosis for a software board. The method needs information about when work became enabled, when processing started and ended, who or what resource handled it, and when that resource was available. Jira and Azure DevOps may contain only imperfect proxies for those events.

The evaluation also found false positives. Sparse activity histories could make availability calendars misleading, while unobserved factors could resemble prioritization. Its real-life demonstration came from manufacturing, not software delivery. The categories travel better than any claim of proven accuracy in a software setting.

Use them as questions:

• Did work wait so several items could be reviewed or released together?

• Was the required person or environment busy with earlier demand?

• Did expedited work move ahead of this item?

• Was a specialist unavailable?

• Did an external decision, dependency, or unrecorded activity hold the item?

• Is the apparent wait a recording error?

Keep “unknown” available. A forced explanation is worse than an honest gap.

Validate the map with cases and people

A practical diagnosis does not require a major analytics programme. Start with one long elapsed state in one service and inspect a small, varied sample of completed items.

For each item, compare the tracker history with other traces that already exist: pull-request events, review comments, deployment records, incident timelines, and decision logs. Ask the people involved what had to happen before the next transition. Look specifically for stale statuses, silent queues, automated updates, and work that happened outside the board.

This step is not an anecdotal substitute for data. It tests whether the event log means what the analysis assumes. If five items in “In Progress” represent five different combinations of coding, interruption, and waiting, a precise flow-efficiency percentage would hide the problem rather than clarify it.

When one mechanism appears repeatedly, change one system condition. Reduce an approval batch. Clarify the policy for entering review. Protect capacity for a constrained specialist. Make an external dependency visible before commitment. Limit work entering a queue that cannot absorb it.

Then review the result over time. Track the targeted state duration alongside overall cycle-time distribution, ageing work, demand mix, and quality. A shorter queue is not an improvement if defects rise or work merely waits somewhere else.

Keep flow measures away from individual scorecards

The same data becomes less trustworthy when it shifts from learning to judgment.

Flournoy et al. (2025) analysed more than 55,000 observations across 216 organizations. Common work factors had modest associations with cycle time against substantial unexplained variation. The authors also note that ticket interpretation depends on recording practice, assignment, collaboration, task content, and organizational context.

That makes one ticket’s cycle time weak evidence about a person. Even a monthly number combines work allocation, queue policy, dependencies, interruptions, collaboration, and the reliability of the timestamps. Ranking engineers by that outcome gives apparent precision to a system-shaped measure.

There is a broader governance risk. Franco-Santos and Otley (2018) found that directive performance systems can produce selective attention, gaming, information manipulation, and changed relationships. The point is narrow: attaching personal consequences can change what the measure does inside the system.

Publish the metric definition, inclusion rules, known data gaps, and review cadence. Keep individual names out of the flow diagnostic. Do not connect state duration to appraisal, reward, or ranking. Invite teams to challenge classifications and explain missing context.

This is not an argument against measurement. It is an argument for protecting the purpose of measurement.

A Monday-morning test

Choose one service and one completed-item sample. Write down the cycle-time clock and the intended meaning of each state. Mark any state that can mix active work with waiting.

Now find the state where the most credible elapsed time accumulates. Review several cases with the team and classify the likely mechanism. Choose one system-level change that should affect that mechanism, and state what else you will watch so the problem cannot quietly move downstream.

The evidence does not support a universal flow-efficiency benchmark or automatic causal diagnosis from status names. It supports a disciplined sequence: validate the record, locate a long elapsed state, investigate what the time contains, test a change, and watch the service.

Your board can point to where time accumulates. The next useful question is what happened there.

References

Ali, M. A., Milani, F., & Dumas, M. (2025). Data-driven identification and analysis of waiting times in business processes: A systematic literature review. Business & Information Systems Engineering, 67(2), 191–208. https://doi.org/10.1007/s12599-024-00868-5

Coremans, B., Klomp, A. L., Rukmono, S. A., Krüger, J., Fahland, D., & Chaudron, M. R. V. (2023). Process mining from Jira issues at a large company. In 2023 IEEE International Conference on Software Maintenance and Evolution (ICSME) (pp. 425–435). IEEE. https://doi.org/10.1109/ICSME58846.2023.00055

Flournoy, J. C., Lee, C. S., Wu, M., & Hicks, C. M. (2025). No silver bullets: Why understanding software cycle time is messy, not magic. Empirical Software Engineering, 30(6), Article 174. https://doi.org/10.1007/s10664-025-10735-w

Franco-Santos, M., & Otley, D. (2018). Reviewing and theorizing the unintended consequences of performance management systems. International Journal of Management Reviews, 20(3), 696–730. https://doi.org/10.1111/ijmr.12183

Lashkevich, K., Milani, F., Chapela-Campa, D., Suvorau, I., & Dumas, M. (2024). Unveiling the causes of waiting time in business processes from event logs. Information Systems, 126, Article 102434. https://doi.org/10.1016/j.is.2024.102434

AI disclosure: AI was used to help create this article. Responsibility for the published content remains with Nico Thümler.