auto-log time when transitioned into in progress, and stop when transitioned away

[Azizbek Umaraliyev]

Hey guys, I have been reading here and online, but I can't seem to find a solution for the problem I have.

The issue is, I am working with a dev team that is lazy to log time, they regularly forget about it and do it post-factum.

so, I was thinkig of creating an automation that starts the timer when the issue gets transitioned into "in progress" and stops when transitioned away.  

To be honest this doens't necessarily have to work this way, but this probably isthe simplest way to automize the time logging. but if you have better suggestions, I'll be glad to hear them too.

So, can someone please point out how I can start the timer automatically when the issue gets transitioned to in progress?

[Henning Stoll · Accepted solution]

Hi @Azizbek Umaraliyev 

you can accomplish this by creating 2 automations and 3 customfields .

The customfield could have the names start time and end time and time worked.

For the first automation the trigger would be transitioning into in progress and then add edit issue as an action where you select the customfield start time and write into it the smart value {{now}}. Then give the automation a name and save it.

Then add the 2nd automation where the trigger transitioning from im progress and you can leave the nd option empty. Then ass action select edit issue again and choose your 2nd customfield end time and write into it {{now}}. Then you write into the field time worked: {{issue.customfield_xxxxx.diff(now).minutes}}. fill in the id of your start time field here you can acces the id by copying the number from the url when you view the customfield in the adminstration and press context and default value. this now should be set up and work.

Remember to add the 3 fields to your screen so theyre vissible and useable for your project.

Finished result should display it like this

[Azizbek Umaraliyev]

@Henning Stoll Thank you for you answer, it is really useful, and I appreciate it.

There is one problem. 

I can't seem to get that timeworked to show up ?

My second automation looks somewhat like this 

and the field looks like this:

Could it be because of the smartvalues ?  because I made sure to wait a few minutes 

[Henning Stoll]

Hello @Azizbek Umaraliyev

what customfieldtype did you use for the field time worked ?

[Henning Stoll]

oh i see you used a dat field for this aswell, i can tell by the pick a date in your automation, this wont work since the date and time field can only hold date and time but we want it to hold a string( the reuslt of our calculation).. So the time worked should be a  text field. Just delete the current one create a new one with the same name and make it a text field and then change the id in the automation and redo the test.

[Azizbek Umaraliyev]

@Henning Stoll Thank you, I wasn't able to get it to work even in a textual form. But that could be perhaps due to screens and field configuations. I was trying to make a fields configuration schema for all the projects, because we have three software projects, one service, but I wanted to make one single template, and I touched so many things, I can't remember which could be the real reason. Because turns out you have to associate fields with screens, screens with field configurations etc. 

But anyways, your suggestion was the closest, thanks.

[Henning Stoll]

Hi @Azizbek Umaraliyev if you want to work further on this iwould be willing to help as you can see on my sandbox it works and dont worry this has nothing to do with screen schemes and such its enough to have them on the screen which they are as i can see from your screenshot. maybe send me an updated screenshot with the text field being filled and the audit log then i can pinpoint you towards a solution.

[Bill Sheboy]

Hi @Azizbek Umaraliyev -- Welcome to the Atlassian Community!

How is your team / company using the log time feature of Jira?  What value does it provide?

I ask this question because if your team is not accurately logging time, and instead you want to automatically record the duration an issue is "in progress" based on issue status, that duration is not the actual working time.  It is the calendar / clock flow time, and will certainly ignore many things: actual work time, task switching, forgetting to transition issues, rework, hidden work, etc.  And so if you are charging clients or measuring the duration of work, automating in this way will not help.

Please review how your team uses logged time, and then discuss with your team how to support that.

Kind regards,
Bill

[Azizbek Umaraliyev]

Hi @Bill Sheboy thank you for raising this point. 

We have internal development team, and we are not charging or paying by the hour, we want to have hours, because moving forward we want to be able to calculate approximate hours we can work in a given iteration, and then take only the amount of work that is estimated to fit in it. but we don't have any clues how many hours we are working as a team,/company. So, it is not going to be a strict measure but one that could give us some idea and trasparency 

[Bill Sheboy]

Thanks for that information.  Given what you describe, you may want to try using the built-in control chart to measure the build cycle time (i.e., from start of work until completion).

https://support.atlassian.com/jira-software-cloud/docs/view-and-understand-the-control-chart/

[Azizbek Umaraliyev]

In my experience, working with teams that are new to agile, should be in the most simplest form. Thus, I don't want to have any measurements of like cyccle time or time to market etc. This confused them even further, for now the first step is to have an idea of hours worked as a team, and take only that much work, then we can step by step improve our agile ways