Calculating parent story points only for specific sub-tasks

[Derek Knudsen]

In our process we use sub-task points to capture dev effort and parent points to capture QA effort.  We capture front-end and back-end sub-tasks, with front-end and back-end designated through a label.  We want to summarize sub-task story points for each task type on the parent.  I have created "Backend Story Points" and "Frontend Story Points" fields on the parent and now am trying to populate those via automation but am stuck trying to figure out how to get the automation to evaluate the label when doing the summarization.  Using story point changes on a sub-task as an example:

IF "Story Points" changes on a sub task THEN for Parent re-summarize "Frontend Story Points" by summarizing "Story Points" on sub-tasks only for sub-tasks with a label of "Front End" AND re-summarize "Backend Story Points" by summarizing "Story Points" on sub-tasks only for sub-tasks with a label of "Back End"

Any suggestions?  Thanks in advance.

[Bill Sheboy]

Hi @Derek Knudsen 

Ignoring for a moment the idea of using story points on subtasks (which others may comment upon...) you can do this in several ways:

• use Lookup Issues with JQL to find the issues meeting the criteria, and then sum
• use Lookup Issues on all of the issues, and use smart value, list filtering, and a math expression to sum them
• use the subtasks attribute to access the issues, iterate over them, and use smart value, list filtering with a math expression to sum them

You may want at least 6 rules for the different cases, triggered on: change to story points (manual hacking check), change to the custom fields, change to parent, change to labels, issue created, and issue deleted.

Kind regards,
Bill

[Derek Knudsen]

Thanks @Bill Sheboy

I understand the process but not the specifics.  Hoping to get some guidance on the right automation language/configuration to put in place. I definitely would need to account for a variety of change types.

[Bill Sheboy]

There are many examples in the community and as a template for projects.  I would start with the second one and update the rule, as needed.

If you want to build this yourself...

For the first approach, please try to write JQL (for an example story) to gather the subtasks you want. (e.g., BE)  Then use that with the Lookup Issue action and the list function sum to get the result.  Here are some references to help with that approach:

• https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Lookup-issues
• https://support.atlassian.com/cloud-automation/docs/jira-smart-values-lists/#list.sum

The last approach is perhaps more efficient, as the subtasks attribute is already available.  The idea is to iterate over the subtasks, filtering on labels for a particular type, and summing the story points using a math expression.

{{#=}}0{{#issue.subtasks}}{{#if(equals(labels,"Front-End"))}}+{{Story points|0}}{{/}}{{/}}{{/}}

Here are some references to help with that approach:

• https://support.atlassian.com/cloud-automation/docs/jira-smart-values-math-expressions/
• https://support.atlassian.com/cloud-automation/docs/jira-smart-values-lists/#Combined-function-examples
• https://community.atlassian.com/t5/Automation-articles/Filtering-smart-value-lists/ba-p/1827588
• https://support.atlassian.com/cloud-automation/docs/jira-smart-values-lists/#list.sum

The middle approach was a hybrid of these earlier two.  And, the approach you use may be based on whatever else the rule is doing.