Multiple Sprints Overview- Lead Time and Cycle Time

Question

Average cycle time

This chart displays the average cycle time in days for issues completed in the sprints. The cycle time is only calculated for completed issues.

Average lead time

This chart displays the average lead time in days for issues completed in the sprints. The lead time is only calculated for completed issues.

Help me understand ,  cycle time is calculated from the day story is created till its completed or Marked Done ?

Lead Time - it track the time when the story moved to In progress state till its marked completed ?

Danut M _StonikByte_ · Accepted Answer

Hi @Hamsa Ranganathaiah,

The short definitions of these two key metrics are:

* Cycle Time = the processing time from the team's perspective
* Lead Time = the processing time from the customer's perspective.

So it's the other way around, if I look at the definitions in your post. I haven't checked in Atlassian Analytics, but it most likely follows the standard definitions of these metrics.

If you can't figure it out, you can try other good alternatives, such as, for example, our Great Gadgets app, which offers all the gadgets you need to track process indicators. More details in these articles:

* https://community.atlassian.com/forums/App-Central-articles/How-to-measure-Cycle-Time-and-Lead-Time-in-Jira-or-Confluence/ba-p/2841286
* https://community.atlassian.com/forums/Jira-articles/Building-a-powerful-Kanban-dashboard-in-Jira-with-Great-Gadgets/ba-p/1664331

Danut.

Birkan Yildiz _OBSS_ · Accepted Answer

Hello @Hamsa Ranganathaiah

Great question and you’re definitely not alone! Understanding the difference between Lead Time and Cycle Time, and then visualizing them correctly in Jira, is a common challenge for many teams.

Let’s quickly clarify the concepts:

Cycle Time is the time it takes to complete a task once work has actually started.
Why it matters? Because cycle time reveals how efficiently your team executes work. Shorter times mean smoother processes. Tracking it can help spot slowdowns during execution.

Lead Time, on the other hand, is the total time from when a task is added to the ‘'backlog’' until it’s fully completed. The critical part is that it includes both waiting and working time. It is crucial because Lead Time shows how long it takes to deliver value. If it’s long, it could signal bottlenecks or overloaded teams. Breaking it down can reveal exactly where delays happen help you to identify bottlenecks.

This is usually the point where most teams grab an app from the Atlassian Marketplace.

If you’re looking for more accuracy and flexibility, I’d recommend checking out Timepiece - Time in Status for Jira, developed by our team at OBSS.

Here is how it can help you:

-See your average cycle time sprint-over-sprint to spot trends. This is great for tracking performance over time.

-Define what "Cycle Time" means for your team by picking any start and end statuses you want. This is crucial because every team's workflow is different, and you can customize reports without changing your project setup.

-Use real working calendars (exclude weekends, holidays, non-business hours)

-Also, since Timepiece gets data from your Jira history, you can see all the reports you want from day one, even for past issues.

We even wrote a detailed article on Lead Time vs. Cycle Time to explain how these metrics impact team performance and where Jira alone might fall short.

If you'd like to explore this solution further, feel free to check out Timepiece - Time in Status for Jira on the Atlassian Marketplace page.

Hope it helps, please let me know if you have any further questions.

Valeriia_Havrylenko_SaaSJet · Accepted Answer

Hi @Hamsa Ranganathaiah  👋

The distinction between Cycle Time and Lead Time often causes confusion. Here’s how they are typically defined in Agile and in Jira reporting

Lead Time

Start point: When the issue is created (or added to the backlog, depending on your setup).

End point: When the issue is completed/Done.

What it shows: The total time the issue spent in the system — including waiting, analysis, development, reviews, and testing.

Cycle Time

Start point: When the issue moves into an active working status (commonly “In Progress”).

End point: When the issue is completed/Done.

What it shows: How long the team actively worked on the issue, excluding backlog/waiting time.

So in your example:

If you want to measure from the day the story was Created → Done, you’re looking at Lead Time.

If you want to measure from the day the story moved to In Progress → Done, you’re looking at Cycle Time.

If you’d like even more flexibility (e.g. tracking time between specific custom statuses like “In QA” → “Ready for Release”), you might consider an add-on like Time Metrics Tracker | Time Between Statuses (developed by my team), which allows you to define your own start and end points and visualize Cycle Time, Lead Time, or any other time metric across sprints.