nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Accepted answers

Bill Sheboy

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

All comments

Bill Sheboy

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud