The Time in Status column allows you to calculate how much time issues spend in a particular status. It can also track multiple statuses, so you can see how much time issues spend in a particular part of the overall workflow.
Each Time in Status column (you can include as many as you need in a structure) can be customized to display precisely the data you need to see.
...
To add a new Time in Status column, open the Add Column menu and search for Time in Status...
Once you've added the column to your structure, you can customize it to fit your specific needs.
...
To customize a Time in Status column, open the column configuration panel and adjust any necessary settings:
Name - we recommend giving the column a distinct name that alludes to the status(es) it's tracking, particularly if you have more than one Time in Status column in a structure.
Type - this is the column type, and should remain unchanged, unless you wish to change an existing column to something else.
Statuses - select which statuses and/or status categories to include when calculating time spent.
Use current status - this option allows you to track how long each issue has been in its current status.
Returns only - select this option to only track time when an issue returns to the selected statuses - see Returns Only for full details.
Transition filter - this option allows you to limit the results to only include time in a status when it directly preceded a move to a specific target status. For example, you could track just how long issues spend In Progress immediately before moving to Testing – if the issue moved from In Progress to any other status (back to Open, straight to Done, etc), that time would not be included.
Sum over sub-items - select this option to get an aggregate total (all sub-issue values are summed up to their parent issue).
Work time - when checked, the value is interpreted according to the Jira settings for work hours (work hours/day, work days/week).
Calendar - choose a work calendar that should be used to calculate the time in status:
Standard calendar 24/7 will consider all hours of every day.
Standard work calendar 8/5 only considers time during a standard work week. For example, if a task has been in Open status for 6 days, using the 24/7 calendar it's time in status would be 6 days, with the 8/5 calendar this would be 1 week.
If you have Structure.Gantt installed, you can create custom calendars which can be selected here. For example, you could specify holidays and vacations, which would then be excluded from the time in status calculation.
...
...
| Anchor | ||||
|---|---|---|---|---|
|
...
In the following workflow, you may want to see how much work has had to be re-done because issues are being passed along to testing too soon. To do so, under Statuses, you would select In Progress, and under Options check the Returns only box.
...
In this configuration, Structure would ignore the first time the issue was in the In Progress status, and only track time if it returned to the In Progress status after moving to Testing, Done, or back to To Do.
...
To do this, you could add both In Progress and Testing to your selected Statuses, and continue to select the Returns only box.
...
Now In Progress and Testing are considered a group to Structure - so moving from In Progress to Testing and then back to In Progress won't be considered a return (since the issue never left the group of selected statuses). But if the issue is moved to Done and then returns to either In Progress or Testing, that will be considered a return and Structure will track how much time is spent in those statuses after that point.
...
Many of us have multiple statuses for work in progress or testing. In this case, you can group all of those together (or just the relevant ones). In the example below, we've added In Progress, Testing, and Testing: Performance to our Statuses list.
...
In this example, let's look at how Structure will calculate time if Returns only is checked:
Issue moves from To Do → In Progress → Testing → Testing: Performance → Done - In this case, no time will be reported, because the issue never returned to a selected status.
Issue moves from To Do → In Progress → Testing → In Progress → Testing: Performance → Done - Again, no time will be tracked. Even though the issue went back to In Progress a second time, it was continuously in one of the selected statuses, so this is not considered a return.
Issue moves from To Do → In Progress → Testing → Testing: Performance → Done → Testing: Performance → Done - This time Structure will report the time spent the second time in Testing: Performance.
Issue moves from To Do → In Progress → Testing → Done → Testing: Performance → Done - Structure will report the time spent in Testing: Performance. Even though the issue only reached this status once, it did so after leaving the selected statuses the first time; therefore, it is considered a return.