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 work items created in the previous week: created >= startOfWeek("-1w") AND created < startOfWeek()

Time in Status Group measurement is recommended when a space 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 space contains more than three statuses.

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

You can measure how long work items 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 a work item 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 work item 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 work item is marked as Done.

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

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

For example, a Waiting for Customer status may exist in a space used to track the development of custom features. However, the same status may not exist in an internal space 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 work item has not transitioned to an active status.

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

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

Also, the Work items 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 work items spent a combined total of more than 569 weeks in the In Progress status category. This total includes work items that are currently In Progress, work items that have since been completed, and work items that later returned to the To Do category.

By comparison, Work items 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 work items that are currently in progress (Unresolved). These work items 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, Status Category Changed, 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.