Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents
minLevel1
maxLevel6
outlinefalse
styledefault
typelist
printabletrue

Metric

Panel
panelIconId1f4e2
panelIcon:loudspeaker:
panelIconText📢
bgColor#FFFFFF

The main condition for calculating the Cycle and Lead Time is that the issue should have the “Done” (you can customize which statuses to count as “Done” - read more here) status at least once during the selected Time frame.

Cycle Time

The Cycle Time metric measures the duration from when work starts (issue moved to the “In Progress” status category) to when it’s completed (issue moved to the “Done” status category).

image-20240912-142637.png
  • You can customize which statuses to count as “In progress” - read more here.

  • You can customize which statuses to count as “Done” - read more here.

Lead Time

The Lead Time metric tracks the time from when an issue is created to when it’s finished (the issue is moved to the “Done” status category).

image-20240912-142805.png
  • You can customize which statuses to count as “Done” - read more here.

Absent metric

If there was no transition from “In Progress” to “Done” status within the specified period, the issue will be present in the Issue list, but the Cycle/Lead Time will not be calculated for such an issue.
It allows to align the issues scope between the Histogram Cycle Time and Time in Status Cycle Time Charts as the issue will have the “In Progress” statistic but have not the Cycle or Lead Time metric.

image-20241112-154236.pngimage-20241112-120819.png
Expand
titleImagine, that the issue was reopened...

Imagine, that the issue was reopened during the same Time frame. The issue was moved through the "In Progress" and "Done" statuses (default or custom) and at the end of the selected Time frame it is remains not "Done".

In this case, the Cycle/Lead Time metric calculates part of the workflow till the status “Done”. Set the Timer control to specify when to pause the calculation:

image-20241112-154313.png

Exception: the “Metric” selection is unavailable for the Time in Status Cycle Time Chart because this chart focuses solely on the time tasks spent in each status rather than tracking the overall cycle or lead time. The goal is to analyze where tasks are held up within the workflow, not to measure the total duration from start to finish.
The option is available for the Cycle Time Histogram and Cycle Time Trend Charts.

Issue state

Define the issue state you want to include in the chart building.

The default “Done” issue state means that the issue was in the “Done” (default “Done” status category or selected custom “Done” statuses) status at least once during the selected Time frame.

image-20240912-143439.pngImage Removed
image-20240912-143224.pngImage Removed

You can select the exact issue state scope from the following:

  • Done: issues were in the “Done” status at least once during the selected Time frame.
    Please note:

    • ”Done” in Jira also means “Updated”.

    • It does not have to be “Created” in the same Time frame.

  • Updated (any status change): any status changes to the issue from the start of the selected Time frame.
    Please note:

    • ”Updated” also means any status change even within the same status category (for example, change from one to another status of any status category).

    • In Jira, "Created" counts as "Updated," so this option will include newly created issues as well.

  • Created: issues that were created during the selected Time frame.

  • Any: includes all issues within the selected Time frame, regardless of their state.
    The application uses the following JQL request to get the issue list for the “Any” issue state selected:
    (created >= start AND created <= end) OR (status WAS IN (...in progress statuses) DURING (start, end)) OR (status CHANGED TO (..

    .

    done statuses) DURING (start, end))image-20240918-084438.pngImage Removed

    In Progress statuses

    The In Progress Statuses option allows you to customize which statuses are considered "In Progress" for all your charts, whether it's Cycle Time Histogram, Time in Status Cycle Time, or Cycle Time Trend Charts.

    This flexibility lets you redefine what "In Progress" means for your workflow by including statuses that are typically categorized as "To Do" or "Done".

    By default, all statuses of the “In Progress” status category are predefined.

    Exception: when the “Lead Time” metric is selected, the “In Progress” field disappears for the Cycle Time Histogram and Cycle Time Trend Charts because for the Lead Time the progress between the date of creation and completion is not important.

    Done statuses

    The Done Statuses option allows you to customize which statuses are considered "Done". This flexibility lets you redefine what "Done" means for your workflow by including statuses that are typically categorized as "In Progress" or even "To Do".

    By default, charts take all statuses from the “Done” status category.

    Expand
    titleLet see how to tailor your process using the "In Progress" and "Done" statuses fields on practical examples

    Imagine your team includes Developers Team and QA Team with the following statuses of the workflow.

    image-20240917-145857.png

    For the Developers Team, work starts from “In Progress”, passes the “In Code Review” status, and can be considered “Completed” when the issue moves to “Ready for QA” status. The setting of the fields will look like this:

    image-20240917-150101.png

    For the QA Team, work starts from the “Ready for Test” status, passes the “In Testing” status, and can be considered “Completed” when the issue moves to the “Done” status. The setting of the fields will look like this:

    image-20240917-150307.png

    Timer control

    The Start timer on and Pause timer on options allow you to precisely define when the clock starts and stops on your issues, which is particularly useful when issues move through the same statuses multiple times. By customizing these settings, you can focus on the specific part of the issue’s lifecycle that matters most to your analysis.

    Available options:

    • First transition to status: starts or pauses the timer the first time the issue transitions to a selected status. This option is a default for the “Start timer on” field, meaning the timer starts when an issue first enters an “In Progress” status.

    • Last transition to status: starts or pauses the timer the last time the issue transitions to a selected status. This option is the default for the ”Pause timer on” field, meaning the timer stops when an issue last enters a “Done” status.

    • First transition from status: starts or pauses the timer the first time the issue transitions from a selected status.

    • Last transition from status: starts or pauses the timer the last time the issue transitions from a selected status.

    image-20240912-143820.pngImage Removedimage-20241213-102304.pngImage Added
    Panel
    panelIconIdatlassian-info
    panelIcon:info:
    bgColor#FFFFFF

    The Timer is available only for one status. If the “In Progress” or the “Done” status category includes a few statuses and you did not clarify which one status you want to track exactly, all “Timer” options are blocked.

    image-20240912-144003.pngImage Removedimage-20241213-102429.pngImage Added
    image-20240912-143915.pngImage Removedimage-20241213-102521.pngImage Added

    Expand
    titleWhen and why should I use the Timer?

    There are a few scenarios to help identify what this setting is about.

    • Managing reopened issues:
      Imagine an issue that gets reopened several times during a sprint. By using the “Start timer on: First transition to status” and the “Pause timer on: Last transition to status”, you ensure that the timer only tracks the time from the first moment the issue starts progressing to the final moment it is marked as Done, giving you an accurate measure of the total active work time.

      image-20240917-152530.pngimage-20240917-151225.pngImage Removedimage-20241213-102653.pngImage Added
    • Tracking revisions in Ready for Test:
      Consider an issue that bounces back and forth between "In Progress" and "Ready for Test" multiple times. Setting “Start timer on: Last transition from status” and “Pause timer on: First transition to status” allows you to focus on the cycle time in the final round of work before it was last sent for testing, ensuring you capture the most critical work phase.

      image-20240917-153200.pngimage-20240917-152948.pngImage Removedimage-20241213-102736.pngImage Added
    • Focus on the final push:
      Suppose you’re interested in how long it takes to complete the final phase of work on an issue. In that case, you might set “Start timer on: Last transition from” one “Done” status (for example, "Ready for Release") and “Pause timer on: Last transition to” another final “Done” status (for example, "Released"). This setup tracks only the last, decisive push to move the issue from being ready to actually being released, giving you a clear view of the final effort required to get the issue over the finish line.

      image-20240917-153633.pngimage-20240917-153650.pngImage Removedimage-20241213-103001.pngImage Added

    Calculation method

    Calendar: this option calculates the total calendar units (days, weeks, months) an issue remains in the "In Progress" status, including weekends and holidays. For example, if an issue enters "In Progress" on Wednesday and leaves it on the following Thursday, the Cycle Time will be 8 calendar days.

    The calculation takes into account time zone settings, holidays and weekends based on your Work schedule.
    The default duration of the “one day” for the Calendar option is 24 hours.

    Duration: this option only calculates the actual working time when the issue was in "In Progress," excluding weekends, holidays, breaks, and non-working hours which you can setup in the Work schedule. In the same example, from Wednesday to the following Thursday, the Cycle Time would be 6 working days, as Saturday and Sunday are weekends (by default) and are excluded.

    image-20240912-144421.png
    Panel
    panelIconId1f4a1
    panelIcon:bulb:
    panelIconText💡
    bgColor#FFFFFF

    Set the Work Schedule during the Calculation method selection ensures that time-based metrics accurately reflect either calendar days or actual working hours, including breaks and holidays. It helps avoid misleading results.

    Expand
    titleLet's see the Calendar and Duration calculation methods on practical examples

    The default Work schedule is the next:

    • Workdays: Monday, Tuesday, Wednesday, Thursday, Friday

    • Weekends: Saturday, Sunday.

    • Work hours: 09:00 AM - 06:00 PM

    • Breaks: 01:00 PM - 02:00 PM

    By default, the work week has 5 days, and the work day has 8 hours.-

    Case

    Dates in period

    Calendar

    Duration

    🔵 - “In Progress”; 🟢 - “Done”; 🔴 - Weekend

    Case 1:

    Issue starts: Friday, 06 September, 03:00 PM.

    Issue completed: Tuesday, 10 September, 11:00 AM.

    *during the same month

    06 September

    03:00 PM-00:00 AM= 9 hours

    03:00 PM-06:00 PM= 3 hours

    image-20240917-133930.png

    07 September

    0 hours

    0

    08 September

    0 hours

    0

    09 September

    24 hours

    8 hours

    10 September

    00:00 AM-11:00 AM= 11 hours

    09:00 AM-11:00 AM= 2 hours

    Total

    44 hours/2 days/1 week/0 months

    13 hours/1 day/0 weeks/0 months

    Case 2:

    Issue starts: Tuesday, 30 July, 10:00 AM.

    Issue completed: Monday, 05 August, 04:00 PM.

    *issue included in two months

    30 July

    10:00 AM-00:00 AM= 14 hours

    (10:00 AM - 01:00 PM) +
    (02:00 PM - 06:00 PM) = 5 hours

    image-20240917-134737.png

    31 July

    24 hours

    8 hours

    01 August

    24 hours

    8 hours

    02 Augustr

    24 hours

    8 hours

    03 August

    0 hours

    0 hours

    04 August

    0 hours

    0 hours

    05 August

    00:00 AM-04:00 PM

    (09:00 AM - 01:00 PM) +
    (02:00 PM - 04:00 PM) = 6 hours

    Total

    102 hours/4 days/1 week/1 month

    35 hours/4 days/0 weeks/0 months

    Case 3:

    Issue starts: Sunday, 08 September, 05:00 PM.

    Issue completed: Tuesday, 10 September, 01:00 PM.

    *during the same month

    08 September

    0 hours

    0 hours

    image-20240917-140224.png

    09 September

    24 hours

    8 hours

    10 September

    00:00 AM-01:00 PM = 13 hours

    09:00 AM-01:00 PM = 4 hours

    Total

    37 hours/1 day/1 week/0 months

    12 hours/1 day/0 weeks/0 months

    Case 4:

    Issue starts: Sunday, 28 July, 10:00 AM.

    Issue completed: Friday, 02 August,

    06:00 PM.

    “24 hours per day” is enabled

    image-20240917-140810.png

    *issue included in two months

    28 July

    0 hours

    0 hours

    image-20240917-141155.png

    29 July

    24 hours

    24 hours

    30 July

    24 hours

    24 hours

    31 July

    24 hours

    24 hours

    01 August

    24 hours

    24 hours

    02 August

    00:00 AM-06:00 PM = 18 hours

    00:00 AM-06:00 PM = 18 hours

    Total

    114 hours/4 days/1 week/1 months

    114 hours/4 days/0 weeks/0 months