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; } } }

Time remaining not correctly calculating

Gary Lazaro

Hi there,

I've read a lot of posts but cannot see a clearly defined solution for this issue where the time remaining on a Jira project isn't calculating correctly.

Example shown below.

The order of the columns are: Time Spent, Original Estimate, Remaining Estimate.

The graph on the right hand side represents the overall time tracking.

The amounts shown as logged, is correct. However, the time remaining is not correct because you can see in the second row 23.75h have been spent of the original 10h. The delta of 13.75h is represented correctly in the graph.

So, if you do the math the total Original Estimate = 123h minus Time spent 85.83h should equal 37.17h.

JIRA calc.png

Any help would be greatly appreciated.

Thanks,

Gary

Accepted answers

Wojciech Miecznikowski_re4b8y

Hello Gary,

The original estimate is not represented in this graph. The simplest explanation is:

At the beginning, when you enter a value in Original Estimate, it is copied to Time Remaining — and that's correct.
From that moment on, these two fields become separate. This means you can adjust Time Remaining at any time (for example, during time logging).
The only place where you can see you're off track with time is the orange field. It shows the difference when Time Logged + Time Remaining is greater than the Original Estimate. I assume that this orange field is exactly 13,75 (50,92-37,17)

I hope this helps! It’s not really intuitive, I agree.
Cheers!

All comments

Wojciech Miecznikowski_re4b8y

Hello Gary,

The original estimate is not represented in this graph. The simplest explanation is:

At the beginning, when you enter a value in Original Estimate, it is copied to Time Remaining — and that's correct.
From that moment on, these two fields become separate. This means you can adjust Time Remaining at any time (for example, during time logging).
The only place where you can see you're off track with time is the orange field. It shows the difference when Time Logged + Time Remaining is greater than the Original Estimate. I assume that this orange field is exactly 13,75 (50,92-37,17)

I hope this helps! It’s not really intuitive, I agree.
Cheers!

Gary Lazaro

Hi Wojciech,

Thanks for that.

Yes, you're right the orange represents 13.75h over original estimate. However, what I was hoping for was the Remaining Estimate column to go into negative by 13.75h.

Which would then mean that the graph should display 37.17h, which takes into account the total time spent across all tasks, including those that have gone into the negative to give the overall time remaining for the project.

Thanks,

Gary

Wojciech Miecznikowski_re4b8y

Hello Gary,

A negative value of 13.75 in Time remaining, both in practice and by definition, would mean that someone has to return to you the 13.75 you spent on the task. Such a situation doesn’t exist in the real world.

Remember that Time remaining refers to the current remaining time and is not connected to the Original estimate.

The Original estimate refers only to the initial estimation and is not really related to the current remaining time.

That’s how it works from the business side. What you're looking for is more like a field showing the relationship between the initial estimate and the remaining time — but such a field doesn’t exist. It’s only represented visually as a color on the progress bar.

However, if you’d like to implement something like that, you could try using Automation Rules or, for example, Scripted Fields (a part of ScriptRunner).

Gary Lazaro

Hi Wojciech,

Thanks again for the detailed explanation. That makes sense and I understand why a negative value in “Time Remaining” isn’t realistic in Jira’s current model.

However, in real terms, when we’re working to a fixed consulting budget, say 40 hours across a project, and a particular task (eg. consulting) is estimated at 10 hours but ends up taking 15, that overrun eats into the overall project allocation. It would be really valuable to reflect this at an aggregate level, so we can see where we’re trending over budget in specific areas.

Are there any examples you could point me to for how others have implemented something similar, perhaps using Automation Rules or Scripted Fields to surface this relationship between actual effort and initial estimate more clearly? I’d love to explore a way to represent this more transparently, even if it’s via a calculated field or a report view.

Appreciate your help so far.

Best regards,
Gary

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

time-remaining