Time remaining doesn't change

[Camille Coffé]

I have two issues with the "time remaining" field:

1) When I change the "original estimate" on an issue, the "time remaining" doesn't change with it. I would assume that as your estimate changes, the remaining time should also change? 

2) Same goes for the time that was logged onto a ticket BEFORE I filled in the "original estimate" - this logged time is not taken into account when calculating the "time remaining". Only time that is logged AFTER I filled in the "original estimate" is taken into account when calculating the "time remaining".

Is this the purpose? Am I doing something wrong?

Thank you! 

[Trudy Claspill]

Hello @Camille Coffé 

Welcome to the community.

Generally, the Original Estimate is a static value. Once set, it sets the baseline Time Remaining value.

Ideally you should be setting Original Estimate before any time is logged against the issue.

As you log time against an issue you have the option to automatically update the Time Remaining (automatically reducing it by the time logged) or explicitly update the Time Remaining to a specific value.

Generally, you should not be updating the Original Estimate once it has been set and after you have started logging time against the issue. Only actual time logged and Remaining Time should be updated at that point.

The Original Estimate can then be compared to the Actual Time Spent when the work is completed to help you improve your estimating skills. If you are changing the Original Estimate and/or logging time before you have an Original Estimate, then you lose the ability to compare and improve your estimating skills.

[Camille Coffé]

Thank you for your quick reply! If I may be honest, this doesn't sit right with me. It can always happen that the scope is changed along the way (for example - the client approves more working hours, or when you decide to reallocate hours from another ticket). Do you know of another way to approach these kinds of cases? 

[Trudy Claspill]

My question for you is what are you trying to accomplish with your process? Why would you be logging time before estimating the time needed for the task? Why would you want to change the Original Estimate?

What is it that you are really trying to track and why? Maybe the default functionality of these fields is not able to fulfill your needs, and a different solution is needed.

We don't actually do time estimation in my group, so I definitely am not an expert on what "should" be done or all the options for what can be done. I'm sure other community members can provide more expertise on this topic based on their experiences.

[Camille Coffé]

In our company we use this field for the amount of workinghours (=budget) that is approved by the client, because it's then handy to see how much time is remaining from the allowed hours. And as I mentioned above, it happens that a client will allow extra hours when we are already working on a task (when time is already logged). Or sometimes working hours can be reallocated from another ticket where they are no longer needed in their original ticket. 

[Trudy Claspill]

It sounds like you are using the field for a purpose that is not covered by the design for the Time Tracking fields.

Since the Time Remaining field is not changing automatically when you change the Original Estimate, your recourse is to change the Time Remaining value manually or see if you can create an Automation rule that will change it automatically.

[Jack Brickey]

agree. OE should not change OE is the plan. there is value in being able to look back at the OE and compare to the actual in order to improve original estimation. If you want to change the OE then you are free to do so but you should update the remaining time as well since you are 'starting over' with your plan.

[Tom Thompson]

Wow, such a simple concept but Atlassian has basically made the Time Remaining field useless.

If I change the Original Estimate BEFORE any time is logged, common sense says change Time Remaining.

However, in my case, Time Remaining is always zero and useless anyway.  And no good suggestions whatsoever after Googling.

So I created a custom field and did what Atlassian should have.

[Jack Brickey]

Hi @Tom Thompson , you might want to use the in-app feedback link to share your thoughts.

[Tom Thompson]

OK... whatever that means... lol... 

I posted the simplest answer around the problem described in this thread.  It was easier to create a custom field with automation than try to figure out why Time Remaining is always zero no matter what setting is tweaked.  

So spent about 20 minutes researching for an answer.

And then about 5 minutes adding custom field with automation to do what Time Remaining should do.

Done.  

[Jack Brickey]

It was just to suggest reaching out to Atlassian to provide product feedback.

Regarding the custom field idea keep in mind that the system field has underlying capabilities that the custom field will not. Specifically in sprints where time estimation is used as well as how time logging is done. with that said if the custom field meets your needs then that is great.