How to not consider remaining estimate on closed issues in Tempo planner

[Marketa Dvorackova]

Hi,

we have a problem with users' capacity calculation, which goes under zero because of remaining estimate on issues that have already been resolved.

We would like to have an option to choose if to consider or not the remaining estimate on the resolved issues for the users' capacity value. Ideally on team level. Is there such a thing to set up?

Thank you for any ideas.

[Gebsun]

Log Work Utilities add-on allows to clear remaining estimate on issue close/resolve without a need to modify workflow: https://marketplace.atlassian.com/plugins/com.gebsun.plugins.jira.log-work-utilities/server/overview

[Jeremy Gaudet]

I don't know if this helps, but I was asked to modify our workflow such that the "Close" transition sets the remaining estimate to '0'.  That would be per-project, not per-team, but you could check the assignee and zero it out selectively.

[Marketa Dvorackova]

Hi Jeremy, thanks for your response, but I really don't want to lose that data only to achieve some kind of a workaround, you know? I believe it should be only a matter of data visualization not manipulation. Ideally:)

[Albert Hauksson]

Hi Marketa and Jeremy, This would also be the recommended workaround from Tempo. Regards, Albert - Tempo Team

[Marketa Dvorackova]

Hi Albert, I will repeat - you're telling me seriously that for a simple visualization of a piece of data, I have to LOSE data? It doesn't seem to me that difficult to add a flag to the Planner ui "consider/not consider remaining on Closed", but apart from that, seriously. Deleting data, which is always a great loss, on purpose and call it workaround? Impossible.

[Jeremy Gaudet]

Out of curiosity, what does that data represent to you? Say an issue started out with an estimate of 30, and had a remaining estimate of 5 when it was closed; you have no way of knowing if the estimate was off by 5, or if they just forgot to change it. If the former, than the 5 means something, if the latter, the "correct" thing to do is zero it out. That was the basis for the request to set it to 0 on Close, the assumption is that the developer forgot to zero it out. As a more advanced workaround, you could copy the data to a custom field first, then zero it out; that way you don't lose anything, and the custom field would be explicit w.r.t. what the data now represents (remaining estimate on close). Or, to remove the ambiguity, you could force the developer to set the remaining estimate on close as a required field on the "Close" transition, and automatically zero out the remaining estimate such that it no longer impacts the capacity calculation. It's not great, but, at least on some level, "zero" could be considered the only valid value for the field once an issue is completed.

[Marketa Dvorackova]

Jeremy, if there is a remaining estimate on a resolved issue, for me it means that it was definitely not estimated well. There is a precise process which lets the planners change the estimates. After a certain point, it only gets cut down by worklog. But that's it. If you decide today that you will work for 3 hours tomorrow on something, then you start and find out you're out of time, it's not that you can magically change it a add some to the estimate in the middle of process. That being said, there is no "setting to zero". You set it to something and consume. Whatever is left means an incorrect estimate for me. If it's incorrect by a couple of hours, ok. But if it's off by 400 hours, I need to know. And I also need to know in which departments it repeatedly happens, which particular planners, etc. There are many way in which any data can be used, this is just one example. It is a matter of principle, loosing something you have if you don't have to, is not correct. The custom field solution is doable, as a workaround, need to analyze all the impact though.