Cycle Time — how long active work actually takes

"It's in progress" tells you nothing about how long it'll take

A ticket moves to In Progress and… time passes. Is that normal? Slow? You don't know, because "normal" was never measured. Some tickets fly through in two days; some grind for three weeks, and the only signal is a vague sense that this one's been open a while. By the time it's obviously stuck, the sprint has already absorbed the hit.

Cycle time — the clock from first active work to done — is the cleanest read on how fast work moves once it starts. It's sitting in your transition history, unmeasured.

How teams approximate cycle time today

The common proxies all measure the wrong thing:

• Days between "created" and "closed" — which includes all the backlog-sitting time and isn't cycle time at all.
• A control chart per board — fine for one team, one board, and useless the moment you want it across teams or filtered by issue type.
• Story points as a stand-in for time — but points aren't time; a 3-pointer and a 5-pointer routinely take the same week.
• No outlier visibility — the average looks fine while a handful of multi-week tickets quietly define your release risk.

How Avium measures cycle time

Avium clocks only the active span, from your real history:

• The clock starts at first active work — the first transition into an in-progress status, not ticket creation — so backlog-sitting time doesn't pollute the number.
• The clock stops at done — canonical resolution, with a Done-category fallback — and reopened work is counted honestly.
• P50 and P90 distribution per team / issue type, so the slow tail is visible, not hidden behind an average.
• Derived from your real transition history (Jira today, or any work management tool) automatically — recomputes as work moves, no manual tracking.

Who reads this Signal

Related Avium Signals