Time in status

You can measure how long bugs or incidents remain in a given status to identify deviations from expected resolution times, especially when filtering by creation date.

For example, you can use this JQL query as a report source to filter issues created in the previous week: created >= startOfWeek("-1w") AND created < startOfWeek()

Time in Status Group measurement is recommended when a project contains more than three statuses. If you use the Time in Status metric instead, every individual status appears in the stacked bar, which can make it difficult to identify the related status category.

By comparison, the Time in Status Group metric groups statuses by category, making the chart easier to interpret, as shown in the following example.

The screenshot above shows when Time in Status is used as a value within the Pivot Report tab type when a project contains more than three statuses.

Based on the tooltip shown, it may be unclear whether the Ready for Launch and Launched statuses represent issues that are still active or already delivered.

You can measure how long issues remain in a status to help identify potential overruns while planning future sprints.

For example, in the screenshot above, the sub-task stayed in the In Progress status for more than four weeks after it was created, while only one week of work was logged during that time. This may suggest that some hours were not recorded over several weeks, which could indicate a possible overrun.

You can also enable the Time Budget column to assess whether an overrun is likely or has already occurred.

In the screenshot below, the sub-task is shown as 77% (177% shown), or three days over budget (3d 30m shown), based on the comparison between the original estimate, time spent, and remaining estimate.

If you reopen an issue that was previously marked as Done and change its status to To Do, the value in the Time in To Do column increases until the issue moves to either In Progress or Done.

Similarly, if you change the status to In Progress, the value in the Time in Progress column continues to increase until the issue is marked as Done.

No. Columns are limited to the To Do and In Progress status categories to show how long an issue stays in each status.

If this restriction did not exist, all statuses from your Jira environment would be displayed, including statuses from projects that use different workflows. In that case, you could not distinguish between issues that use a particular status and issues from projects where that status does not exist.

For example, a Waiting for Customer status may exist in a project used to track the development of custom features. However, the same status may not exist in an internal project used to track the development of features available across all products.

Yes. You can change how the four Time in Status fields appear by using the report sidebar. For example, you can switch between Jira’s default time-tracking format (such as 1w 3d 2h 15m) or display values in hours, days, weeks, or months.

Yes. You can change the Complete Date/Time format for the Created date field in Jira by navigating to Jira administration → User Interface → Look and feel.

This allows you to change the display format from dd/MMM/yy h:mm a (for example, 23/May/07 3:55 AM) to dd/MMM/yy (for example, 23/May/07).

No. For example, if a bug remains in the To Do status and its remaining estimate is unchanged while worklogs continue to be added, an estimate overrun is likely. However, the Time in To Do field will remain empty because the issue has not transitioned to an active status.

Time in Status measurements show how long an issue remained within a specific status or status category during its lifecycle.

By comparison, the Issues Lifetime measurement shows how much time has passed since an issue's Created date and time until the current date and time. The value continues increasing until the issue is moved to Done (Resolved). Any other changes to the issue's status are not measured.

Also, the Issues Lifetime field is not affected by calendars that define working hours or working days, nor by time zone configurations.

In the example above, the Time in Status Group indicator shows that issues spent a combined total of more than 569 weeks in the In Progress status category. This total includes issues that are currently In Progress, issues that have since been completed, and issues that later returned to the To Do category.

By comparison, Issues Lifetime is displayed as a Value in the Summary section of the Pivot tab type. For the In Progress column, it measures the combined lifetime of only those issues that are currently in progress (Unresolved). These issues have existed for a total of 568 weeks since their creation.

Time tracking settings

Changing the Working days per week or Working hours per day in Jira's Time tracking settings does not affect Time in Status in reports.

Board settings

Changing the working days defined in a board's settings does not affect Time in Status in reports, even when those reports use the board as their data source. Time in Status calculations are based on the report's calendar settings rather than the board's working-day configuration.

Yes. The number of working days selected in the report calendar affects Time in Status.

For example, if you deselect Friday in a custom report calendar, Time in To Do and Time in Progress decrease because fewer working days are counted in each week.

The Created and Time in Status fields (such as Time in To Do and Time in Status) displayed in the report use your desktop operating system's time zone. In contrast, the Created field in the Jira issue view uses your Jira account time zone.

For example, a user creates an issue and later moves it to In Progress while working in Jakarta. At that time, the user's desktop time zone is set to Jakarta. Later, the user returns to Montreal and changes the desktop time zone to Montreal, while keeping the Jira account time zone set to Montreal throughout the trip.

As a result, the Created value shown in the report can differ from the Created value shown in the Jira issue view. Because the Time in Status values are calculated from the report's Created value, they can also differ.