How to measure cycle time in Jira

“What’s our cycle time?” is a simple question with an awkward answer in Jira. To measure it properly: pick a clear start status (usually In Progress) and a done status, count the time between them in real working hours rather than raw calendar time, and break the total down by status so you can see where it actually goes. Jira’s native Control Chart gets you partway there — a cycle-time scatter chart on company-managed boards — but it gives one blended number, not a per-status breakdown, and its working-time handling is basic. Here’s how to measure cycle time so the result is actually useful.

What Jira gives you natively

On company-managed boards, Jira has a Control Chart that plots cycle time for completed issues. It’s a genuine starting point, but it has three limits that trip teams up:

• It’s a scatter plot, not a clear number. You get a cloud of dots and a rolling average, which is hard to quote in a review or track week over week.
• Its working-time handling is basic. There’s a toggle to exclude non-working days, but no custom holiday calendar and no partial-day handling — so unless you remember to flip it, nights and weekends count as elapsed time, and even when you do, holidays and partial days still don’t.
• It’s not everywhere. Team-managed boards and cross-project views don’t give you the same thing, so there’s no single consistent figure across your work.

So the native answer is directional, not decision-grade — and left on its defaults, it tends to overstate cycle time.

How to measure it so it’s useful

• Define start and done explicitly — usually “entered In Progress” to “reached Done” — so you’re measuring active work, consistently.
• Measure in working hours. Skipping weekends and holidays stops a Friday-afternoon handoff from looking like a three-day delay, and makes week-to-week comparisons fair.
• Separate cycle time from lead time. Lead time (request → done) includes the wait before work started; cycle time (start → done) is the doing. The gap between them is often where the real delay hides — see cycle time vs lead time.
• Break it down by status. The single end-to-end number hides where time goes. Time-in-status shows the bottleneck — the status issues pile up in — which is the thing you can actually fix.

Doing it without spreadsheets

Linger computes this from the issue changelog in your tenant: cycle and lead time across a project or board, counted in real working hours, with a per-status breakdown that flags the bottleneck — no exporting changelogs into a spreadsheet. The per-issue time-in-status view is free. For how this differs from Jira’s native chart, see control chart vs time in status.

The takeaway

Jira’s control chart gives you a cloud of calendar-time dots; a useful cycle-time measurement is a clear number in working hours, split by status so you can see where work waits. Define start and done, measure in working hours, and break it down by status — then the metric stops being a vanity chart and starts pointing at the bottleneck to fix.