Automation rule for issue *removal* from active sprint

[Alex Ball]

Which automation rules should be used to trigger an action when an issue is *removed* from an active sprint?

This is easy for *addition* to an active sprint:

• When: Value changes for `Sprint`
• If: Issue matches JQL `Sprint in openSprints()`

I've tried several variations for the sprint-removal case, like:

• When: Value changes for `Sprint`
• If: Issue matches JQL `(Sprint is EMPTY OR Sprint not in openSprints()) AND {{fieldChange.from}} in openSprints()`

But I haven't found a way for Automation to play nicely with previous values of a multi-value field. `fieldChange.fromString`, `changelog.sprint.from`, etc... no dice.

Is this possible?

Thanks!

[Bill Sheboy · Accepted solution]

Hi @Alex Ball 

There are suggestions in the Code Barrel backlog to detect sprint scope changes as a trigger, and Jira backlog to do so with JQL: 

• https://codebarrel.atlassian.net/browse/AUT-703
• https://jira.atlassian.com/browse/JRACLOUD-75868

I believe there is a ScriptRunner function to detect scope changes, if you have that add-on: removedAfterSprintStart.

Without those things...

Have you tried to shorten your JQL condition?  This worked for me:

• Trigger: value changes for Sprint
• Condition If issue matches JQL: 

key = {{issue.key}} AND Sprint IS EMPTY OR Sprint NOT IN openSprints()

• Action: log the issue was removed from the sprint

Best regards,

Bill

[Alex Ball]

Thanks, Bill! I'll keep tabs on those backlog issues.

Unfortunately, `Sprint is EMPTY OR Sprint not in openSprints()` doesn't quite do it, since we put "top of backlog" issues in four future sprints, each representing a different category (infrastructure, sales requests, bugs, etc.) for better visibility into sprint budgeting. Thus, that rule would trigger when moving an issue from one future sprint to another, which we don't want. AFAIK this means that we need access to the previous sprint value, to ensure that the issue was removed from the *active* sprint.

Bit of a niche case, I know. I'll give ScriptRunner a spin shortly.

[Bill Sheboy]

Hmmm... I tried moving from the active sprint to both the backlog and future sprints, which worked for me.  The problem edge case is when you have parallel, active sprints.

One work-around for the future-to-future scenario: when a sprint starts, mark all issues that were in scope at that time (comment, custom field, etc.) using a different rule.  Then in your removal-detect rule, add a condition to look for that that marking so you wouldn't continue for the move of future sprint A to future sprint B.  (This technique also helps with reporting scope changes over time.)

__Bill

[Johnny Mon]

Hi @Alex Ball ,

I recently came up with a solution using A4J Data Center version 9.0.3 (on-prem) that covers the difficult 'removal' or 'changed' scenario.  Please check out my Github respository: a4j-notification-add-remove-issue-sprint 

for the exported rule and details on the implementation.

[Alex Ball]

Thanks! We're using Cloud. For what it's worth, we're currently using a version of Bill Sheboy's revised suggestion, with an automation rule to copy the sprint value to an "Original Sprint" custom field, and checking against that when an issue's sprint value changes.