Can we lock a story's Original Estimate, so new subtasks only impact the Remaining work?

[Max Cascone]

I've seen a lot of similar questions, but not exactly this scenario.

We believe we're following the right guidelines by only estimating time in a Story's sub-tasks, and using the built-in rollup functionality to show all the work remaining for a Story.

However, once we set a Story in motion, it's possible that more subtasks could be discovered, and we'll add them to the story.

The issue is that adding these subtasks, with their time estimates, increases the original estimate roll-up of the parent story. So we aren't shown intuitively that the parent's estimate increased from its original value. Presumably it will show as a bump in that sprint's burndown, but not when looking at the story card itself. It looks like the estimate was always at that higher number. 

This is a bit different than having your Original estimate for an item, logging work to it, and also saying that now I think there's more work left than originally estimated. That will show nicely in the Time Tracking bars for the individual item; the Remaining will creep out past the Original.

What I'm asking is, is there a way to "lock" the Original Estimate of a parent story, so that when a new sub-task is added to that story, its estimates only impact the Remaining values of the parent story. The Original Estimate should stay the same, so that it's clear that more work was discovered than originally estimated,

[Anton Chemlev - Toolstrek -]

Do you have ScriptRunner? If yes, you can create custom field and fill it on some transition or event.

[Max Cascone]

If I'm understanding you correctly, you're suggesting to create a new field that the Original Estimate can be copied to in the event that something changes it?

[Anton Chemlev - Toolstrek -]

Yes, you are right. You will be able to capture initial Original estimate.

For example, you have Estimation step in your workflow. Make post-function on transition from this step, which will copy Original estimate to custom field. See ScriptRunner docs for additional info.

[Max Cascone]

We seem to have stumbled on a workaround, that was defined some time ago by another team in our company but we're not sure if they were using it effectively. Anyway, they created a new custom field just called "Estimated Days" that lives at the story level. It can be used for estimating the Story's effort in days. It's not connected to anything programatically, so we can still add estimates and logged work to our subtasks, which roll up to the Story (when the box is checked). 

So we plan to use this field as the rough estimate, for "look-ahead" roadmap planning and prioritization purposes. Later, when Dev actually pulls it into their backlog, they'll use the Time Tracking fields at the Sub-task level to estimate and log their time. We still have the issue of the Story's Original Estimate being inflated when new subtasks are added to a story in motion - the subject of this thread - but we'll always have the static field that will stay at its original value.

We have documented that new subtasks created after a story is in motion should set their Original Estimates to 0, so they don't inflate the Story's OE. But now with this additional field, that's probably not necessary anymore.

It's not perfect - I wish the Original Estimate could just be set and locked at the Story level, and unimpacted by subtasks' estimates, while still burning down the Remaining estimate. It appears that Jira expects you to use one or the other item to track time, but not both. While it doesn't seem like such a conceptual leap to allow locking the fields, I'm sure Atlassian has their reasons for not supporting it.

[Pankaj Sharma]

@Max Cascone  do you have any groovy script using which you are capturing Original Estimate value in a custom field 'Estimated days' ?