Problem with tracking time / remaining time calculation

[Pedro Alves]

Hi! We've been using JIRA for a while and didn't have problems with it till recently. Sometimes we notice that JIRA has been miscalculating the remaining time estimate. It should decrease the time based on the time a member of the team has logged, but it has been subtracting wrong values. Sometimes JIRA does it and then the remaining time estimate becomes orange even when there's still time left based on the original estimate. We have two screenshots of the history tab that's attached here. Pay attention to the logged time and the time that was actually subtracted.

I'm not sure whether we're using JIRA wrongly or that's a bug. Has anyone ever had a problem like that?

Note: We use the new issue interface.

Thank you!

[George Bou-Rizk]

Hi,

I have a similar issue except I know exactly what causes mine to happen.

Basically if you set the original estimate, it will set the remaining estimate to that value. If you then start logging time, it deducts from the remaining estimate as expected.

The issue happens once you log time beyond the original estimate. If I then edit the worklog entry and bring it back under, the remaining estimate calculation is wrong.

For example:

I have a task with without any logged time and an original estimate of 40h

next  I log 20h and the remaining estimate is calculated fine.

Next I log a time of 30h and as expected, remaining goes to 0 as it does not support negative time.

Then if I edit the last log from say 30h to 10h, You would expect the remaining time to go to 10 hours as I would have logged a total of 30h. However, the remaining estimate goes to 20 hours.

It seems that what it is doing is adding time to the remaining budget based on how much time was removed. i.e. it was 30h and I changed it to 10h, which is a difference of 20h, so it thinks there are 20h remaining.

Instead of doing a calculation based on Original estimate - Logged time, which would give the correct value of 10h.

Note that I am using tempo for logging time. I originally raised it with them but they suggested they simply grab the data from Jira and aren't doing their own calculation.

This really is a problem because it's a typical scenario for me that people will log too much time and we will have to move or deduct time, if this messes with the remaining estimate it's an issue.

Additional note:

The issue will also happen if you modify the original estimate after you have logged time. it will not properly calculate the remaining time.

[WernerS]

Is there any update for this issue?

[George Bou-Rizk]

Atlassian seemed to just ignore me on this one.

Note I found a sort of work around by creating an automation in Jira which I can run that automatically does a calculation of Original - Logged time and overwrites the remaining estimate.

This works best when you have the rule trigger every time someone logs time. However automations are limited, if you have premium you get quite a lot but they can still run out. there is a lot of logging happening in my company so it could get used up quite quickly and then the automation stops running.

I might look into a way of doing this on demand or once a day where I can click run automation and it runs the estimation calculation overwrite on all tasks, I just haven't had the time.

It's pretty poor from Atlassian. All they need to do is change the remaining estimate field to be one that is calculated based on Original time - Logged time as I am doing using automation. Rather then this weird formula they have now which seems to be remaining estimate = remaining estimate +/- Logged time which is just straight wrong.

This is a simple bug with a simple fix.

[Raman Shahdadpuri]

https://jira.atlassian.com/browse/JRACLOUD-42743