Cycle time vs. lead time (30 seconds)
- Cycle time: first transition into In Progress → Done. Measures your process.
- Lead time: created → Done. Measures what your customer experiences, queue included.
Both come from the issue's change history — neither is a field in Jira, which is exactly why reporting on them is awkward.
Why the median and p85 beat the average
One rewrite-everything ticket makes your average cycle time useless. Flow metrics use percentiles instead: p50 (median) — half your work finishes faster than this; p85 — the honest promise number. “85% of similar items finish within 9 days” is a forecast you can give a stakeholder without estimating anything.
What native Jira gives you
Company-managed boards have the Control Chart (Reports → Control Chart): cycle time per issue over time with a rolling average. Real limitations: it's scoped to one board, it can't be added to a dashboard, the rolling-average band is famously hard to read, and there are no p50/p85 KPIs to track against.
Team-managed boards have a simpler cycle time report with similar constraints.
The recurring community question — “how do I get cycle time onto a Jira dashboard?” — has no native answer. That's the gap.
The dashboard answer
Spectra computes cycle time (and time-in-status, WIP aging, and more) from each issue's change history and treats it as a first-class chart dimension. The Cycle time & flow template gives you, in one click:
- p50 and p85 KPI tiles — the two numbers worth tracking sprint over sprint
- A cycle-time distribution — see the shape, spot the long tail
- A control chart with p50/p85 lines — every completed item plotted, outliers obvious
- Lead-time KPIs alongside, so process time and customer time never get conflated
Two things the native reports can't do:
- Any scope, on a real dashboard. Point it at a project, a board, a saved filter (cross-project), or raw JQL — and place it as a native gadget on the Jira dashboard your team already opens.
- Click to investigate. Every chart is a filter: click the long tail of the distribution and every other widget refilters to those slow issues — by assignee, component, priority. “What do our slowest 15% have in common?” is two clicks, not an export.
Reading the chart: three patterns worth acting on
- p85 far above p50 → high variance; your process is unpredictable even if the median looks fine. Usually a few blocked-and-forgotten items — click the outliers and look at their time-in-status.
- p50 creeping up across periods → systemic slowdown (WIP too high, review bottleneck). Check WIP aging next.
- Tight cluster, occasional extreme outlier → healthy process with exception cases; fix the exceptions, don't reorganize the team.
Want the raw JQL for stuck issues instead? How to query time in status with JQL covers the one-line Argon function — same intent, from the query side.
FAQ
How does Jira calculate cycle time?
Natively, only inside board reports (the Control Chart on company-managed boards): elapsed time between status transitions on that board's issues. There is no cycle-time field, and the report can't be placed on a dashboard.
How do I add cycle time to a Jira dashboard?
Not possible with native gadgets. Apps like Spectra compute cycle time from change history and provide a dashboard gadget with distribution, control chart, and p50/p85 KPIs.
What's a good cycle time?
There's no universal number — trend and predictability matter more than the absolute value. Track p50 and p85 per team; improvement means the percentiles come down (or variance narrows) over time.
Cycle time vs. velocity — which should we track?
Velocity measures how much you finish per sprint; cycle time measures how long each item takes. Cycle time works without estimates and is harder to game. Most flow-oriented teams track both.
Does computing cycle time send my Jira data anywhere?
Not with Spectra — it's built on Atlassian Forge and replays change history entirely inside Atlassian's infrastructure. No external servers. Why Forge-native matters for reporting on data you make decisions against.