Jira Automation with Child Issue Story Points assigned and reduced from the parent Issue

[Boll Kristi]

Our team is new to JIRA and are trying to transition from another tool.  We are using a team managed project. Every sprint we have 2 Issues created that are specific to providing support to our business users.  We allocate a X number story points for that unknown activity - kind of like a buffer but work that is tracked and limited.  One is for Critical/High Incidents and the other is for Medium support Incidents.  For example, we may assign 5 story points to one and 10 points to the other.  When a support ticket comes in,  and a team member is free (not working on another issue), we want to create a child issue and assign it a story point based on what is required to assist the person submitting the incident and know how to do this, no problem there.  Our team has come up with a predefined point determination based on past history, so we stay aligned and consistently assign values.

What we'd like to automate is to take the story point value from the child and reduce it from the parent.  This way we can monitor how many support tickets we are able to work along with all the other work we have committed to during that sprint.  (We also include this work as part of our committed work and is used for yesterday's weather when planning for upcoming sprints.   If we reach the limit (ie get to 0) and still have other committed work that is not finished, we work with the PO for priority.  Most often we carry over the medium incident work for another sprint and leave them unassigned.

Is there a way to do this automatically, instead of manually doing it?  We know this is not necessarily the "proper" way to use an Issue  but is what has worked for us and streamlined our support work.  Any assistance/suggestions is greatly appreciated.  Thanks so much!

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

Yes, you could do this, and it's a lot better than what a lot of people try to do (add up sub-task estimates to stories), but it is not Scrum and Jira's Scrum boards are not built to do not-scrum.

The best way to cope with support issues interrupting your development teams is to create a recurring story for "unexpected support" in each sprint - looking at historical reports of this to size it for each sprint, you can then do what you suggest - when a support issue arrives, create it as a sub-task, estimate it, and subtract the estimate from the parent.

Automation can do that for you.

But the main trick here is to make sure you do it in a different field from your sprint estimation statistic - then it won't mess up your statistics.

[Boll Kristi]

Thanks for the quick response Nic! 

So are you suggesting to not make changes to the story point estimate fields on the parent and child issues?  Can you provide a suggestion as to how exactly to set this up?  Everything I've tried doesn't seem to work.  LOL

[Nic Brough -Adaptavist-]

Not quite, but very close.  I need to go back to scrum principles and how Jira has implemented support for it to explain this.

Scrum works off a pile of sprint-able items (stories).  When you go into a sprint, the aim is to complete a set of selected stories that your team committed to delivering at the start of the sprint.  The achievement rate is measured at the end of the sprint, and used to try to work out how much the team can do in the following sprints. 

Sub-tasks are not stories, they are wholly a part of their parent story.  So Jira ignores sprint estimates on them when you're doing Scrum, because the sub-tasks don't matter to the estimates directly.  You're committing to doing a story, and whether you do it or not, a sub-task, as part of it, by definition, must be complete for the story to be complete.

A lot of people (including me) find estimates on sub-tasks useful to help plan and evaluate, but they often fail to understand that this estimate can only be a part of the story, not an estimate in its own right, as far as the sprint is concerned.

So, what we need is a way to allow for sub-tasks with estimates that will be reported correctly by both Scrum and the rest of Jira.  The trick here is to separate Scrum estimates from actual estimates.  To do that, we need two fields, used in three ways.  I'll stick with simple numeric fields for this:

• The Estimate field should exist on stories and sub-tasks and contain the story points only for that issue.
• The Sprint Estimate field should only exist on the Story level issues, the actual sprint-able items, and it should be calculated from the Estimate field on the story and all its sub-tasks (there are a load of different schemes for adding up, subtracting etc)

On your board, you set the Estimate statistic to the second field.

With the second field, you are aiming for a field that only changes content when its scope genuinely changes.

You might need to use a couple of automations to do this properly (I do this with a single scripted listener or even a scripted field on server, but I usually have access to Scriptrunner there.  I am less familiar with Cloud)

The rule you need to implement is "set the Sprint Estimate field to be the sum of the Estimate field on the current issue and all its subtasks"