Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Can JIRA Automation check if there are multiple active sprints?


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.

1 answer

1 accepted

1 vote
Answer accepted

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,


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 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 {{}} 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.)


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. 

I made a test rule for this use case, and when editing the fixVersion of the issues in the created sprint, I just entered {{}} 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.


create version with sprint start.png

Like Arthur Bershadskiy likes this

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!

Like Bill Sheboy likes this

Suggest an answer

Log in or Sign up to answer
Site Admin
Community showcase
Published in Marketplace Apps & Integrations

Bitbucket Smart Commits vs. Genius Commits - What's the difference?

If you already heard about Smart Commits in Bitbucket, know that you just stumbled upon something even better (and smarter!): Genius Commits by Better DevOps Automation for Jira Data Center (+ Server...

130 views 0 2
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you