Add up multiple estimates of same story till closed

[Thomas Hartmann]

Yes, we face the fact that stories often outlast over multiple sprints. The reason may vary, sometimes the story is not finished, code review or testing is not done yet. Altough it might not be best practice by theory, we move the same story to the next sprint and set remaining estimate with the value of the amount we think its needed to finish.

We do not bother developers by logging their work on story level, but as a project manager I want to know how much effort it took till the story is closed. Even the estimate is not the correct value, it's a good average I can use for my reports.

Now, if a story runs over multiple sprints I need the sum of all estimates. For example:

Sprint 1: Orig. Estimate = 3d

Sprint 2: Remaining = 1d

Total: 4d

Is there any (simple) approach, script or automation which I can use to calculate those values and save them best in the story itself (custom field) so I can export those values out of Jira?

[Trudy Claspill]

Hello @Thomas Hartmann 

Yes, you can accomplish this through Automation, with caveats.

The built in time tracking fields automatically convert values to display in terms of weeks, days, hours, etc. taking into consideration the configuration that has been set for your instance for working days and working hours per day.

There is no comparable custom field type. So, you would need to create a custom Number field, get the Original Estimate and Remaining Estimate values in seconds, add that to your number field. You might want a better display of the value in terms of hours, or days, and if so you would need to add steps to your rule for that conversion.

I would recommend creating a rule that would initialize your custom field to the value of Original Estimate when that field is first set. However, what would you expect to happen if the Original Estimate was later changed?

You could have another rule that takes any change to the Time Tracking field and adds the Remaining Estimate time to your custom field.  For that a rule like this would work, assuming that the custom field has been initialized to some number; either 0 or the Original Estimate. If the custom field has not been initialized to some number this rule, as it is, would fail to update the custom field. You would need to add and If/Else block to evaluate if the field was empty or already set to a number, and then edit the field to either add the remaining estimate (as shown) or set the field to the remaining estimate value.

The value in the custom field ends up being the total seconds of the Remaining Estimate as it changes values. If the remaining estimate was 1h and you changed it to 2h, then the total in the custom field would be 10800 (60 seconds * 60 minutes * 3 hours). 

And if you added steps to convert the seconds to hours or days or whatever, then you would need to consider that when trying to update the value and either convert it back to seconds or convert the Seconds value of Remaining Estimate to match.

[Thomas Hartmann]

Thx for answering and the pitfall with initializing the custom value with a number. I am not interested at all in better formatting, as I would do this after exporting the custom field by my own in Excel. But I understand the problem with multiple change of the original estimate or even multiple changes of the remaining estimate, but only one change was really "the right one". This would sum up the custom field to a complete wrong value.

I am asking me, if it's possible to run an automation only if a sprint starts? If so, I could sum up the custom field with the remaining, only once per sprint start. As remaining is the same as original the first time, it should also cover all others problems.

What do you think?

[Trudy Claspill]

Yes, there is a trigger for executing a rule when a sprint starts.

https://support.atlassian.com/cloud-automation/docs/jira-automation-triggers/#Sprint-created--started--or-completed

You could use that trigger along with a branch for Related Issues / JQL to find all the issues in the sprint, and then execute your steps to sum up the current values of the fields.