Can JIRA Automation check if there are multiple active sprints?

[Arthur Bershadskiy]

Hello,

I'm trying to set up JIRA to automatically assign fix versions to issues that are in an active sprint. My team has overlaps in our sprint cycles where the next sprint will start before the previous sprint has closed. 

I've set up rules to create new fix versions and assign them to issues when a sprint is started but I'm not sure how to handle the above scenario. I don't want to hard-code the fix version values in the Automation rule for obvious reasons but the only automatic options are either "last released version" or "next unreleased version" (this is what I'm currently using to create/assign versions to the active sprint). 

The issue with my setup is that when a second sprint is started, the issues in that sprint get the fix version of the sprint prior since that sprint has not been closed yet. 

Appreciate any thoughts you guys might have.

[Bill Sheboy · Accepted solution]

Hi @Arthur Bershadskiy  -- Welcome to the Atlassian Community!

Would you please share your naming convention for your versions and sprints?  Those may provide ideas for the community to give suggestions.  Thanks!

Also, have you considered waiting for a sprint to start to create the new version?  That could ensure a pairing of the two.  (This would not handle scope changes to the sprint, and thus version.)

Best regards,

Bill

[Arthur Bershadskiy]

Hi Bill,

My sprints are named [A-Z]21 and I set it up to use the same naming convention for versions. 

The method you described it how I have it set up now:

1) When sprint created, create a matching version #

2) When an issue is added to active sprint, update with the latest unreleased version (created in the step above)

3) When a sprint is moved out of an active sprint, remove the fix version

The problem is that if I start sprint A21 and it creates version A21, then 2 weeks later I start sprint B21 it will populate those issues with fix version A21 since that one hasn't been released yet.

The easiest option I can think of is to not start the second sprint until I release A21 and set the start date retroactively. This is good enough but I was wondering if there's a way to handle this automatically.

Thanks,

Arthur

[Bill Sheboy]

Thanks for that information, Arthur.

I was suggesting to wait until the sprint starts to create the version, rather than doing so when the sprint is created. 

That prevents version errors (sprint created and then deleted without starting), and ensures the issues are assigned to the version for their respective sprint.  Even with parallel sprints, there is no confusion in the rule because you use {{sprint.name}} to create the version.  This will work even when there is carry-over issues from one sprint to another. 

Although, you probably want another rule which clears fixVersion when Sprint Completes and there are remaining incomplete issues.  (Branch and JQL for that one.)

__Bill

[Arthur Bershadskiy]

Sorry about that but I mis-typed up there. I do have it set the way you described so the version is created when the sprint actually starts. 

It does avoid the errors you mentioned but I run into another error:

Sprint 1 starts -> Fix Version 1 is created and assigned to tickets

Sprint 2 starts -> Fix version 2 is created but it assigns the latest unreleased version (Fix Version 1) 

The other rule about clearing the fix version is a good idea and is something I was planning on adding. 

[Bill Sheboy]

I made a test rule for this use case, and when editing the fixVersion of the issues in the created sprint, I just entered {{sprint.name}} because my version names exactly matched the sprint names.  That worked as I did not assign them to the latest unreleased version, avoiding the confusion you note for parallel sprints.

If you needed to build a version name different from the exact sprint name you may instead store it with a Create Variable and then use that smart value in the fixVersion edit.

[Arthur Bershadskiy]

Oh that's perfect! I did not realize I could use the smart values in that field. Thanks for your help, this is exactly what I was looking for!

[Bill Sheboy]

I am glad that helped!  Automation documentation has some info gaps, and so it can help to experiment and see what is possible.  And, watch these posts for ideas and updates:

• https://community.atlassian.com/t5/Automation-articles/Jira-Automation-all-the-resources-you-need-in-one-page/ba-p/1388465
• https://community.atlassian.com/t5/Automation-articles/79-Questions-and-Answers-about-Jira-Automation/ba-p/1363930
• https://community.atlassian.com/t5/Automation-articles/Announcing-the-Jira-automation-template-library/ba-p/1537227