DEV Community: Alina Chyzh

Jira Cycle Time vs Lead Time: What They Actually Measure

Alina Chyzh — Fri, 03 Jul 2026 07:28:23 +0000

"Cycle time" and "lead time" get used interchangeably in Agile retrospectives. They're not the same thing and using the wrong one to diagnose a delivery problem sends you in the wrong direction.

The practical difference, how to pull each from Jira, and when each one is actually worth tracking.

Lead time: total elapsed time from when a request enters your system to when it ships. In Jira: from issue creation to resolution.

Cycle time: time from when work actually starts to when it's done. In Jira: from the first transition to "In Progress" to "Done".

Everything that happens before work starts: backlog sitting time, prioritization, sprint planning counts in lead time but not cycle time.

Issue created ──────────────────────────────── Issue done
     │                    │                        │
     └──────── Lead time ─────────────────────────┘
                          │                        │
                          └──── Cycle time ────────┘
                        (work started)

Why the distinction matters

They answer different questions.

Cycle time answers: how fast does your team execute once work begins? If your average is 3 days and it jumps to 7, something in your delivery process changed, PRs sitting in review longer, issues scoped too large, a recurring blocker type.

Lead time answers: what's the full wait from request to delivery, from the outside? A team can have tight cycle time (fast once they start) but a 3-week backlog before anything gets picked up. Customers experience lead time, not cycle time. Promising a delivery window without knowing your lead time is promising something you can't verify.

Getting these from Jira

Neither metric is surfaced cleanly by default.

Control Chart (closest native option)

Available under Reports on Kanban boards. It plots time-in-progress per issue, an approximation of cycle time if your "In Progress" column maps accurately to when work starts.

The catch: it measures time in board columns, not workflow statuses. If your board doesn't map 1:1 to your actual statuses, the numbers are blurred.

Jira project → Reports → Control Chart (Kanban boards only).

JQL for lead time

Jira doesn't expose timeInStatus as a JQL field, but lead time is straightforward once you export to CSV:

project = MYPROJECT AND status = Done AND resolved >= -30d ORDER BY resolved DESC

In the export: resolutiondate minus created = lead time. You can do this in a spreadsheet in about five minutes.

REST API for cycle time

Cycle time requires the status change history, which doesn't appear in the standard CSV export. You need the changelog:

const response = await fetch(
  `${baseUrl}/rest/api/3/issue/${issueKey}?expand=changelog`,
  { headers: { Authorization: `Basic ${btoa(`${email}:${token}`)}` } }
);

const { changelog } = await response.json();

const inProgressTransition = changelog.histories
  .flatMap(h => h.items.map(i => ({ ...i, created: h.created })))
  .find(i => i.field === 'status' && i.toString === 'In Progress');

const doneTransition = changelog.histories
  .flatMap(h => h.items.map(i => ({ ...i, created: h.created })))
  .reverse()
  .find(i => i.field === 'status' && i.toString === 'Done');

if (inProgressTransition && doneTransition) {
  const cycleTimeDays =
    (new Date(doneTransition.created) - new Date(inProgressTransition.created))
    / (1000 * 60 * 60 * 24);
  console.log(`Cycle time: ${cycleTimeDays.toFixed(1)} days`);
}

One thing to watch: this finds the first transition to In Progress. If an issue bounced back from Done to In Progress and back again (which happens) you'll want to decide whether you want total active time or just first-to-last.

The number most teams ignore

The gap between lead time and cycle time is waiting time and that's usually where the actual problem is.

Average lead time:   15 days
Average cycle time:  4 days
─────────────────────────────
Waiting time:        11 days

If 11 of your 15 days are pre-work queue time, optimizing your development process won't move the number customers see. The problem is upstream, backlog grooming, prioritization, how long issues sit before anyone picks them up.

Teams that only measure cycle time tend to optimize the wrong thing. Execution looks fine on their dashboards. Meanwhile the backlog is 6 weeks deep.

When to use which

Cycle time: use this for internal process work. Did the new PR review policy make things faster or slower? Are bugs taking longer than features? Is there a particular engineer whose issues have much longer cycle times (sign of blocked work, not slow work)?

Lead time: use this for anything external. Setting delivery expectations with clients, tracking whether SLA commitments are realistic, understanding the actual experience of someone who filed a request.

Both together: use this when diagnosing a slowdown. Lead time up, cycle time flat: the problem is pre-development. Both up: it's in execution. Lead time flat, cycle time up: execution is slower but the backlog is moving faster, which might mean better prioritization is masking a process issue.

What Jira still won't tell you

Even with cycle time and lead time figured out, there's a gap: time per workflow status how long an issue sat specifically in In Review vs. In QA vs. Waiting for Deployment.

An issue with a 6-day cycle time might have spent 1 day in development, 4 days waiting for code review, and 1 day in QA. Without the per-status breakdown, you'd target the wrong stage.

Jira Cloud doesn't surface this natively. The Control Chart shows you the aggregate; the status-level view requires the changelog API (same approach as cycle time above, but aggregated per status) or a reporting tool that does the work for you. The Jira time tracking reports guide covers what's available natively, what needs JQL workarounds, and where the gaps are if you want a fuller picture of where time actually goes.

Summary

	Cycle time	Lead time
Starts at	Work begins (In Progress)	Issue created
Ends at	Issue done	Issue done
Answers	Is execution fast?	What does the customer wait?
Native in Jira	Approximated (Control Chart)	Not directly
Use for	Internal process improvement	Stakeholder commitments, SLAs

The JQL query and API snippet above cover the manual path. If you want this without writing extraction code, most reporting add-ons for Jira handle the aggregation, but knowing what the numbers actually count is still on you.

One last thing worth saying: most teams I've talked to who "track cycle time" are actually tracking something closer to calendar days in the sprint, not time from first status transition. That's not cycle time. It's a rough proxy that includes weekends, holidays, and all the time the issue sat assigned but untouched. Worth auditing how your tooling actually calculates it before drawing conclusions from the numbers.

How to Query Jira Worklog Data with JQL And Where JQL Falls Short

Alina Chyzh — Tue, 28 Apr 2026 13:32:47 +0000

Jira stores every worklog your team ever submits. Time spent, date, author, comment — it's all in there. The frustrating part is that most of this data is surprisingly hard to surface through the UI.

If you've ever tried to answer "how much time did the team log last week, grouped by user?" using native Jira tools, you've probably ended up in one of these places:

An Issue Navigator export that gives you issue-level time, not user-level totals
A spreadsheet with =SUMIF formulas pulling from a CSV dump
A dashboard gadget that kind of shows what you need but not quite

This post covers what JQL can and can't do with worklog data, some queries worth having in your toolkit, and where the Jira REST API becomes a better approach than JQL for anything more complex.

What JQL actually lets you filter on for worklogs

JQL has four worklog-related fields you can use in queries:

worklogAuthor
worklogComment
worklogDate
worklogDate >= "YYYY-MM-DD"

That's it. No worklogHours, no totalTimeSpent filter, no grouping by user. JQL can find which issues a person logged time on, within a date range — but it can't sum that time, filter by amount, or aggregate across users.

Here are the queries I find myself writing most often:

All issues where a specific user logged time this month:

worklogAuthor = "user@company.com" AND worklogDate >= startOfMonth()

All issues where anyone on the team logged time this sprint:

worklogAuthor in membersOf("team-name") AND worklogDate >= -14d AND sprint in openSprints()

Issues logged by the current user that are still open:

worklogAuthor = currentUser() AND worklogDate >= -30d AND statusCategory != Done

Issues with worklogs containing a specific keyword (useful for billing codes):

worklogComment ~ "billable" AND worklogDate >= "2026-04-01"

All of these return issue lists, not time summaries. To get total hours from the results, you export to CSV and sum the Time Spent column yourself.

The gap: what JQL won't tell you

A few things you'd expect to be queryable that aren't:

You can't filter by amount of time logged. There's no worklogHours > 2 equivalent in JQL. You can find issues where a user logged work, but you can't filter to only issues where they logged more than a threshold.

You can't group by user. JQL returns a flat list of issues. If three people logged time on the same issue, you get that issue once — not three rows, one per author.

You can't query worklogs directly. JQL queries issues, not worklog entries. If a user logged two separate entries on the same issue on different days, you can't distinguish those entries via JQL — the issue just shows the total Time Spent field.

timespent is queryable but limited. You can write timespent > 2h to find issues where more than 2 hours have been logged total, but this is total across all users, not per-user.

timespent > 7200  // time is in seconds in JQL
project = MYPROJ AND timespent > 7200

Where the REST API does what JQL can't

If you need per-user time summaries, the Jira REST API is the right tool. Two endpoints are worth knowing:

Get worklogs for a specific issue:

GET /rest/api/3/issue/{issueIdOrKey}/worklog

Returns all worklog entries for that issue, including author, timeSpentSeconds, started date, and comment. This is the granular data JQL never surfaces.

Search issues and get their worklogs:
The practical pattern is two-step: use JQL via the search endpoint to get a list of issues, then fetch worklogs per issue.

// Step 1: get issues with worklogs in the date range
const searchResponse = await fetch(
  `${baseUrl}/rest/api/3/search?jql=worklogAuthor="${userEmail}" AND worklogDate>="${startDate}"&fields=summary,timespent`,
  { headers: { Authorization: `Basic ${btoa(`${email}:${apiToken}`)}` } }
);

const { issues } = await searchResponse.json();

// Step 2: get worklogs for each issue
const worklogs = await Promise.all(
  issues.map(issue =>
    fetch(`${baseUrl}/rest/api/3/issue/${issue.key}/worklog`, {
      headers: { Authorization: `Basic ${btoa(`${email}:${apiToken}`)}` }
    }).then(r => r.json())
  )
);

// Step 3: filter by author and date, sum time
const userWorklogs = worklogs
  .flatMap(w => w.worklogs)
  .filter(w => 
    w.author.emailAddress === userEmail &&
    w.started >= startDate
  );

const totalSeconds = userWorklogs.reduce((sum, w) => sum + w.timeSpentSeconds, 0);
const totalHours = (totalSeconds / 3600).toFixed(1);

This gives you what JQL can't: actual per-user time totals, filterable by date range, groupable however you need.

One gotcha: the /worklog endpoint paginates at 20 entries by default. For issues with a lot of logged time, you'll need to handle the startAt parameter:

async function getAllWorklogs(issueKey, baseUrl, auth) {
  let allWorklogs = [];
  let startAt = 0;
  const maxResults = 100;

  while (true) {
    const response = await fetch(
      `${baseUrl}/rest/api/3/issue/${issueKey}/worklog?startAt=${startAt}&maxResults=${maxResults}`,
      { headers: { Authorization: auth } }
    );
    const data = await response.json();
    allWorklogs = [...allWorklogs, ...data.worklogs];

    if (startAt + maxResults >= data.total) break;
    startAt += maxResults;
  }

  return allWorklogs;
}

The updated worklogs endpoint (often overlooked)

There's a less-known endpoint that's useful for syncing or auditing worklog data:

GET /rest/api/3/worklog/updated?since={timestamp}

Returns all worklog IDs updated since a given Unix timestamp in milliseconds. Useful if you're building a sync process and don't want to re-fetch everything — just poll for updates since your last sync.

const since = Date.now() - (7 * 24 * 60 * 60 * 1000); // last 7 days
const response = await fetch(
  `${baseUrl}/rest/api/3/worklog/updated?since=${since}`,
  { headers: { Authorization: auth } }
);

const { values, lastPage, nextPage } = await response.json();
// values = array of { worklogId, updatedTime }

Then fetch the actual worklog details in bulk:

POST /rest/api/3/worklog/list
body: { "ids": [worklogId1, worklogId2, ...] }

This is significantly more efficient than querying per-issue if you're maintaining any kind of time tracking integration.

When to use what

Goal	Use
Find issues where someone logged time	JQL with `worklogAuthor`
Filter open issues by who's working on them	JQL with `worklogAuthor` + status filter
Get total hours per user	REST API `/issue/{key}/worklog`
Build a timesheet view	REST API, aggregate by `author` + `started` date
Sync worklog data incrementally	REST API `/worklog/updated` + `/worklog/list`
Show time trends across sprints	Reporting add-on (JQL and API both get complex fast)

For the last row — if you need ongoing time reporting inside Jira without building and maintaining your own API integration, Report Hub handles the aggregation layer. It's a Forge app so the data stays inside Atlassian's infrastructure, which matters if you're in a regulated environment. The full breakdown of what's possible with Jira time tracking reports — including the JQL workarounds and their limits — is on the Grandia Solutions blog if you want more depth on the reporting side.

Why Developers Hate Jira and How to Make It Dev-Friendly Again

Alina Chyzh — Thu, 11 Dec 2025 14:21:03 +0000

Most development teams have a love–hate relationship with Jira. On paper, it's a powerful work-management platform designed to bring structure and transparency. In reality, many developers experience it as a friction engine: slow interfaces, complicated workflows, noisy dashboards, too many fields, and processes that grow heavier with every sprint.

Developers often joke that updating a task in Jira takes longer than fixing the bug inside it and for many teams, that’s uncomfortably close to the truth. The is how teams configure and use it.

This article explains the real reasons developers become frustrated with Jira, what damage poorly designed workflows cause, and how to make Jira lighter, faster, and more supportive of engineering work.

The Real Reasons Developers Hate Jira
It becomes a management tool, not a developer tool

Teams often turn Jira into a system for tracking, reporting, and controlling people rather than enabling engineering flow. Every status change becomes a process step. Every update becomes an audit entry and every sprint feels like a reporting exercise instead of collaboration. When Jira starts representing bureaucracy instead of value, developers disconnect from it.

Too many fields, too many statuses

A simple quick update often turns into a miniature epic: mandatory fields, dropdown lists with 40 options, tabs full of unused data. The more clicks a task requires, the less likely developers are to keep it updated. Over-engineered workflows slow teams down and create frustration long before any development work even starts.

Slow performance breaks deep-work cycles

Jira can be sluggish, especially in large organizations. If every transition takes 3–5 seconds, and those transitions happen dozens of times per day, developers lose focus. Momentum disappears. Instead of supporting flow, Jira interrupts it.

Reporting chaos undermines trust

Teams accumulate dashboards the way projects accumulate technical debt. Different charts show the same metric with slightly different filters; multiple dashboards contradict one another, leaders reference graphs developers have never seen. Instead of clarity, reporting generates confusion and eventually nobody trusts the numbers.

Time tracking becomes a punishment, not a tool

Time tracking isn't bad by itself. But when it becomes a micromanagement mechanism (log every minute,hours = productivity), morale drops fast. Developers stop updating tasks accurately because the system feels punitive, not helpful.

Too many boards and fragmented visibility

A team might have a main board, a triage board, a PM board, a QA board, a roadmap board, and three experimental boards from old initiatives. Tasks get duplicated or lost. Developers stop knowing where work truly lives.

Notifications: either overwhelming or nonexistent

Some developers receive 40+ notifications per day. Others receive none when something critical changes. Poor notification hygiene reinforces the perception that Jira adds noise rather than value.

What Poor Jira Experience Does to Teams

A noisy Jira environment does more than annoy peopl, it slows teams down.
Developers lose focus because they constantly switch mental contexts, cycle time increases because flow is interrupted, engineers avoid updating tasks because the system feels heavy, managers lose visibility because data becomes outdated or unreliable.

Over time, frustration with the tool becomes frustration with the process itself and that leads to disengagement, friction, and burnout. When developers stop believing in the process, velocity suffers regardless of how many metrics you track.

Jira Can Be Developer-Friendly
Simplify workflows aggressively

Most teams only need a small set of core statuses: To Do → In Progress → In Review → Done. Anything beyond that should be justified, not assumed. Simplicity restores speed and reduces errors.

Reduce fields to the essentials

If a field doesn’t influence planning, reporting, or workflow logic, remove it or make it optional. The fewer cognitive steps a task requires, the more consistently developers will keep it updated.

Automate the boring parts

Jira Automation can eliminate dozens of manual actions: moving tasks when a PR is created, assigning reviewers, closing resolved issues, surfacing stale items. When Jira does the repetitive work, developers stay focused on engineering, not administration.

Build developer-centric dashboards, not management dashboards

Useful metrics for developers include cycle time, review latency, throughput, and WIP. Unhelpful metrics include tasks completed per developer or one-dimensional time logs.

Teams often introduce tools like Report Hub when they need clean, consolidated, developer-friendly dashboards without maintaining multiple native Jira gadgets. Such tools reduce reporting clutter instead of adding to it.

One team, one board

If everything is important, nothing is. A single, authoritative board per team reduces duplication and confusion while keeping sprint work visible and manageable.

Integrate Jira into the developer workflow

A great Jira setup lets developers interact with tasks without leaving their environment.
VSCode plugins, Git integrations, Slack updates and keyboard shortcuts reduce friction dramatically. The best Jira experience is one that minimizes the need to open Jira at all.

What a Healthy Jira Setup Looks Like

Here’s a typical “before vs after” transformation:

Before

11 workflow statuses
20 required fields
multiple boards per team
dashboards full of conflicting metrics
long load times
developers avoiding task updates

After

4–5 clear statuses
only critical fields
one board per team
a small set of meaningful metrics
automation supporting transitions
developers updating tasks effortlessly

With the right balance of simplicity and automation Jira stops being a burden and becomes a natural part of the development lifecycle.

Jira Isn’t the Problem — Overengineering Is

Jira becomes painful when teams over-customize it, misunderstand metrics, or treat it as a surveillance tool rather than a collaboration platform. But when teams streamline workflows, reduce noise, automate tedious steps, and design dashboards around developer needs, Jira becomes fast, intuitive, and reliable.

Fix the system and Jira becomes one of the most powerful allies an engineering team can have.