nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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?

Accepted answers

Henning Stoll

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

jira time.png

All comments

Henning Stoll

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.

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

Finished result should display it like this

jira time.png

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 timer stop.png

and the field looks like this:
time ain't showing.png

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.

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud