Log in Get started
Metric

What is lead time, and how do you measure it in Metabase?

Lead time is the elapsed time from when a work item is created to when it's done (completed_at − created_at). It captures the whole wait a request experiences — including time sitting in the backlog — which makes it the customer's-eye view of delivery speed. Measure it in Metabase from issue-tracker data synced into a database (Linear or Jira).

TL;DR — Lead time = created → done. It includes backlog wait. Cycle time = started → done (active work only). Report both as medians (p50) and p90, never averages.

Lead time vs. cycle time

Starts atEnds atAnswers
Lead timecreateddone"How long from request to delivery?"
Cycle timestarteddone"How long once we actually work on it?"

A big gap between the two means work waits a long time in the backlog before anyone starts it.

What data does lead time need?

  • created_at (always available) and completed_at / resolved (set when done).
  • A reliable "done" definition: state_type = 'completed' (Linear) or status_category = 'Done' (Jira).
  • No status history required for basic lead time — only created anddone timestamps.

SQL patterns

Median lead time by weekPostgreSQL
SELECT
  date_trunc('week', completed_at) AS week,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (completed_at - created_at)) / 86400.0
  ) AS median_lead_days,
  percentile_cont(0.9) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (completed_at - created_at)) / 86400.0
  ) AS p90_lead_days
FROM issues
WHERE state_type = 'completed'
GROUP BY 1 ORDER BY 1;

Pitfalls

Using averages.→ Lead time is right-skewed; use median + p90.
Counting canceled work.→ Exclude canceled items.
Confusing it with cycle time.→ Label charts explicitly; they answer different questions.
Backlog-heavy distortion.→ Old backlog items completed today produce huge lead times — segment by created date.

Where this metric applies

Dashboards

Software delivery dashboardSprint health dashboard

Metrics

Cycle time

FAQ

Is lead time the same as cycle time?
No. Lead time measures created → done and includes the whole wait a request experiences, including time sitting in the backlog. Cycle time measures started → done — only the active working period once someone picks the item up. Lead time is almost always longer, and the gap between them is queue/backlog time. Report both: lead time for customer-facing expectations, cycle time for team flow.
Do I need status history to measure lead time?
No. Basic lead time needs only two timestamps — created and done (completed_at/resolved) — so it works even when you don't have a status-change history. That's a key advantage: if you can't compute cycle time because there's no reliable started_at, lead time is the honest fallback. History is only required for cycle time, time-in-status, and burndown.
Should I report the median or the average lead time?
Report the median (p50) and p90, never the mean. Lead time is heavily right-skewed — a few old backlog items completed today drag the average far above what a typical request experiences. The median shows the common case; p90 shows the tail worth attacking. The average hides both.
How is this different from DORA lead time for changes?
They share a name but measure different things. Lead time here is an issue-tracker metric (created → done for a work item). Lead time for changes is a DORA delivery metric measured from first commit to production deploy, sourced from source control and CI/CD rather than the issue tracker.
Why is my lead time suddenly huge this week?
Usually because the team finally closed some long-stale backlog items — an issue created months ago and completed today produces an enormous lead time that skews the whole week. Segment by created date (or cohort by month created) so backlog cleanup doesn't distort your current delivery trend, and exclude canceled work.
How do I reduce lead time?
Lead time = backlog wait + cycle time, so attack whichever dominates. If the gap between lead and cycle time is large, work waits too long before anyone starts it — tighten intake, prioritize the backlog, and limit how much you accept. If cycle time dominates, reduce work-in-progress and break large items into smaller ones.
Where does lead time apply — Jira or Linear?
Both, and it needs no special setup. In Linear, measure created → the move into a completed workflow state. In Jira, measure created → status category Done. Model either onto a shared schema and you can report lead time across trackers in one dashboard.