How to automate Total Story Points (Custom Field) for Release Task using JIRA Automation

[Paras Dua]

Hi,

I am trying to automate the Total Story Point sum / calculation using automation in Company Managed project on JIRA Cloud.

I have already set this up to work fine for Rolling up Story Points from Sub-Tasks to Story.

However, I am not able to get the total from the Blocking Stories to a Custom Work Item type (Release) that we have created in the company type project which works for our specific setup and team structure.

Structure is :

Release Work Type to group all Stories and Tasks to be taken for the Release through different environments.

Here is what I have tried so far.

Step 1: Trigger Automation Rule on change on Sub-Task Story Point Field -- Works.

Step 2: Identify the Related Issues and point to the Release Type Cusom Work Item. -- Works.

Step 3: (This is what is not working) Sum of Story Points from Related Work Items using {{lookupIssues.Story Points.sum}}.

Please help.

Thanks,

[Trudy Claspill]

Hello @Paras Dua 

Welcome to the Atlassian community.

Given that you have indicated your plan type is Standard, I surmise that you have not modified the Issue Type (Work Item) hierarchy to enable you to have Story issues be children of Release issues.

How are you creating the relationship between Stories and Release  issues? Are you using generic issue linking?

Please show us the entire automation rule you currently have, the output in the Audit Log for when the rule runs and doesn't provide the expected results, and details about what results you expected vs. what results you got.

[Paras Dua]

Dear Trudy,

Thank you for a swift help here.

I have not edited anything specific in the work Hierarchy and the scheme is as below:

Epic : 1

All others like Task, Story, Release, Improvement, Bug : 0

Dev Sub Task and QA Sub Task : -1

I am linking (blocks) with the Release (this is also a task type with a specific workflow for release management) as below

Here

IFB-184 is the release. This release (IFB-184) has IFB-97 and IFB-22 as the stories. IFB-188 is the Dev-Sub-Task in the IFB-22 Story.

The Ask: We update story point in the dev-sub-task (IFB-188)

1. It should update the story point in the Story (IFB-22)

2. Story Point are getting rolled up/ updated in the Story (IFB-22) has been updated by another automation which is working fine.

3. The rollup is not happening for the Release (IFB-184) with the total for issues marked as blocked on it under linked items (IFB-97 and IFB-22).

Here is the screenshot of the Automation which is not working.

Here is the Screenshot for Audit Log:

In case it helps solve faster:

Custom Field ID for the Total Story Points: is customfield_12139.

Once again appreciate your help in advance.

Thanks,

[Trudy Claspill]

Thank you for that additional information.

First, I would recommend having two separate rules; one that rolls up points from subtasks to their parent issue, and on for rolling up points from Stories to their linked Release (issue type). It sounds like maybe you have that already, but I was not sure because I can see you have added Sub-tasks to the condition of your Trigger.

@Bill Sheboy 's points are also things you need to consider.

For the very simple case where the points on a Story has changed and you want to update the total points on any linked Release issue type:

Use the Field Value Changed trigger to detect a change in the field. Add a condition to it to confirm the change was in an issue type of interest (Story).

Add a branch to change the focus of the rule to any issues linked to the trigger issue, where the trigger issue "blocks" the linked issue.

The actions nested under the branch will be applied to each issue found by the branch.

Add a condition to check that the linked issue found is of the issue type that you want to update (Release) [I'm using Task in my example]

Add a Lookup Issues action to lookup all the Stories that are linked to the Release issue that is currently in focus in the branch.

The JQL I used for this is looking for all the Story type issues where Story Points is not empty and the Story is linked to the Release with the "is blocked by" link.

issue in linkedIssues({{issue.key}}, "is blocked by") and type=Story and "Story Points" is not empty

Then use an Edit action to set the value of the field in the Release issue as the sum of the Story Points fields in the issues (Stories) found by the Lookup. In my example I am putting the sum into the Story Points field in the linked Task.

In addition, because the Story itself may be updated by another rule (the rule that sums Subtask points up to the parent Story) you will need to check this box on the Rule Details page:

There are several reasons why your rule did not update the Story, looking at the Audit Log you provided.

The rule was triggered by a change to issue IF-188, which you said that IF-188 is the subtask issue.

You are then doing a Lookup of issue linked to the trigger issue. I'm not sure why you're doing a Lookup at this point, but since the trigger issue was the subtask, this lookup will not find any linked issues.

Next you are using a branch to change the focus to issues that are linked to the trigger issue by "blocks". Since there are no issues linked to the trigger issue (subtask) by "blocks", this branch finds no issues and does nothing.

You said you have a rule that successfully updates a Story based on changes to the Subtask. Am I correct that is a different rule than the one you have shown?

If so, then the rule you showed would at least need the checkbox checked as I mentioned above, so that the rule to update the linked Releases could be triggered by the rule that updated the Story.

Keep in mind Bill's points. For instance, if a new issue is linked to the Release, that by itself would not trigger an update of the story points in the Release. Likewise, if an issue link was removed from the Release, the story points in the Release would not be updated.

Let me know if you have additional questions.

[Bill Sheboy]

Hi @Paras Dua -- Welcome to the Atlassian Community!

I understand why a single delivery team might do this for their work items within the scope of a single project.  Other scopes may not provide the expected results.  Regardless of that challenge...

I notice you are trying to make updates when the Story Points field changes for specific work item types.  Have you considered there are multiple other cases to handle, depending upon when you need the sums and how accurately you want them recorded?

Some cases include, and are not limited to...

• when the "story points" change for a work item with a parent, update the parent's field (This is your described case.)
• when a work item is created with parent, update the parent
• when a work item is removed from a parent, update the previous parent
• when a work item is deleted, update the previous parent
• when a work item is moved to a new parent, update the new and previous parents
• when a work item changes type, decide which, if any, parents need to be updated
• when someone manual changes the "story points" in the middle of a chain of work item types, decide what to do: re-calculate all relevant values, do nothing, etc.
• when there is an Atlassian outage preventing rule executions, my understanding is some of them never run to "catch up"; in such cases, consider adding a scheduled trigger rule to do so...and even this may not work due to the service limits (i.e., count, load, looping)
• different project types use different fields for "story points": company-managed use "Story points" and team-managed use "Story point estimate"; and so multiple project scope scenarios may need to account for this
• etc.

Thus, there is no single rule which could solve all possible scenarios.  Please consider which ones you want to handle as you create your rules.  Thanks!

Kind regards,
Bill

[Paras Dua]

Dear @Bill Sheboy and @Trudy Claspill ,

Thank you for giving time to this issue.

Please see that I have created a Manual Trigger for now to calculate the sum of Story Points Blocked on the Release to ease the complexity.

Here is the screenshot:

I will also try setting up the Automation as per details provided by @Trudy Claspill and share results.

Appreciate the support and details provided so far.

Will add progress details. :-)

Thanks Team,

[Bill Sheboy]

@Paras Dua please review the suggestions from @Trudy Claspill ...

The Lookup Work Items action you show uses JQL which is too broad: it will attempt to find all items with a link type of "Blocks" rather than ones linked to the trigger issue.