Auto Time Log Tied to Issue Status

[Christian]

I am looking to make an automation that will atomatically log time on an issue if it is in the workflow stats 'In Progress'. Is this at all possible? I picture an automation that runs at midnight every day and looks at all in progress issues and updates the time spent on issue as from the point the issue was put into progress until now, but I am open to better suggestions.

Is this at all possible?  

[Trudy Claspill]

Hello @Christian 

Before we talk about how that might be accomplished, let us talk about why you want to do it.

What problem are you trying to solve by automatically logging time on an issue?

Logged time is intended to record the actually time spent by a person actually working on the issue.

Your proposed automation doesn't seem to align with that.

What value do you get out of logging time against an issue for all the hours of all the days that it is in the In Progress status?

[Christian]

With my company's setup, whenever an item is "In Progress" the assignee should be working on it with their 100% focus. Linking logged time to the In Progress status ensure that we always know how long a task took. If this is better served in a different field I don't really care, but I think the logged time field makes the most sense. 

[Trudy Claspill]

So let us back up to define the problem you are trying to solve.

You want to know "how long a task took". Why? What are you going to do with that information? What decisions will you be trying to make based on that information?

Do you need to generate some sort of report for that? If so, how does the data need to be aggregated - per Assignee, per Project, per Issue Type?

The best solution depends on understanding the problem to be solved.

Things to consider:

Would you intend to log all time from the moment it changes to In Progress - i.e. 24 hours a day? Or do your team members work only 8 hours a day? What if they work a partial day? What about weekends?

Can you have more than one Assignee on an issue over the course of its life cycle?

What if the issue changes to another status and then back to In Progress? Do you want to aggregate all the time it spend in In Progress, or reset the "clock"?

An alternative to logging time is to keep track of how many days the issue spent in the In Progress status.

[Christian]

We are trying to create a comprehensive production schedule, and as part of that we want to know how long a task (in business days) is worked on until it is complete. Number of assignee's is irrelevant.  We want to see after a project is finished how long each task took and then adjust them in a schedule for the next project to more accurately predict working time. If the field moves to a waiting status 

Maybe I'm off looking at the time logging field to track this.  I just want to a way to concisely show this for company managers. Do you know the best way to do this? 

[Trudy Claspill]

Thank you for describing the problem you are trying to solve. That is very helpful.

There are a variety of ways to address the need. 

You could indeed use work logging, and then look at the "Time Spent" on the issue. When logging work, the work has to be attributed to a User. If there is any reporting being done concerning work logged by users, you would need to consider the impact to that reporting by this solution.

You could alternately have a custom field that records how many business days an issue stayed in the In Progress status. That would be a simple number field, not a duration field like Time Spent. This solution would not be explicitly linking the "time" to any particular user.

When looking at using Automation Rules for this requirement you need to consider the limits imposed on automation rule executions per month. With a Premium subscription the execution limit is 1,000 multiplied by the number of licensed users.

An alternative implementation to using Automation would be to acquire a "time in status" third party app.

https://marketplace.atlassian.com/search?hosting=cloud&product=jira&query=time%20in%20status

The trick with Automation will be figuring out how to trigger it to get the desired affect.

For logging time you might use a Scheduled Trigger to run once a day, towards the end of the day, and find all the issues that had a status of "In Progress" at some point on that day.

status was "In Progress" after startOfDay()

Using this JQL would ensure that if an issue moved to "In Progress" some time during the day and then to another status, it would still get work logged for that day.

Then log 1d of work to each of those issues.