Automation: Sprint name into fix version field

[Stian Stiansen]

Hey!

I'm trying to make an automation of the release notes in the Jira board and I'm having issues with the automation which picks out the name of the sprint, and adds it to the "Fix" version field. It's basically a set of 3 automatons where:

1. the first one creates a version when the sprint is created,
2. the second one is supposed to add the issue/ticket to the version when it's assigned to the sprint,
3. and the third one will release the version when the sprint is closed.

The challenge with the second one is that it will add the value (smart-value) if the issue has not been in any sprints before, and get's added to one, but if the ticket has been moved from an earlier sprint, then no value is added.

It does work if you decide in the automation to add the "next unreleased version", but then you can't prepare future sprints because you can only have 1 at the time.

Basically what I want is the current sprint to be in the fix version field.

Any takers on how to solve this easily?

[Brian G]

I use this logic here: 

[Alex Degregori]

Hey @Stian Stiansen - curious if you were ever able to get this figured out? I'm looking to get this same automation up and running. 

Also, would you be able to share a screenshot of the setup of your 3 automations? I'm struggling with the smart value setup. 

[Stian Stiansen]

Hi Alex!

Some of our projects are more or less fully automated except for the task handling which is manually, so I was able to create a 7 automation setup which is taking most cases into consideration I think. These projects basically have two columns on the board which is TO DO (the initial state) and DONE (the completed state).

The standard rules are:

1. When the Sprint Starts --> Then create a new version

2. When an issue transitions to TO DO --> Clear the field "Fix Versions"

3. When an issue transitions to DONE --> Then update the "Fix Version" field with the value of the "next unreleased version"

4. When the sprint is completed --> Then release the next unreleased version

Task creations happens between rule 1 and 2, but this is something you can exclude if you would rather create your tasks manually. For these examples where I use this then the tasks creation steps are all automated as well, and it's basically done like this:

Firstly I usually create the epics in one automation rule each, and then based on the epic names, then I have a rule which creates the sub-tasks for the epics. This is therefore very optional depending on your setup.

For those projects which are basically used as monthly checklists, then I've added these as well as they are very predicable.

Optional:

5.  When an Issue transitions to TO DO --> If the connected EPIC has the status DONE, and connected issues has the status TO DO = Then change the status of the epic to TO DO

6. When an Issue transitions DONE --> If the connected EPICs status does not equal the status DONE, and the connected issues has the status DONE = Then change the status of the epic to DONE

7. When Version is released --> If an issue is the type Epic and has the status DONE = Then update the underlying EPIC status to DONE. This hides the epic from the backlog

I hope this is useful for you as well!


Best regards,

- Stian Stiansen

[Alex Degregori]

Hey Stian! 

Thank you so much for the context here. I think your 3rd rule is where our use case changes.

"3. When an issue transitions to DONE --> Then update the "Fix Version" field with the value of the "next unreleased version"

I am looking to have a sync occur between the Fix Version field and the Sprint field no matter the status. I am running into issues around how to represent the name of the Sprint field and have the Fix Version with the same name also get added to the issue. Going to investigate more on my end! 

[Stian Stiansen]

Hi Alex!

I did so in the beginning as well, until I found out that the sprint field contains the values for all the sprints the issue has been through, and not just the latest one. Knowing that, then I tried different solution with extracting the values and then parcing only the lastest or first value etc.

Basically the challenges was that if you have a ticket which has only been to one sprint, then parsing that value will work, but if the issue is moved through multiple sprints, then it becomes harder.

I therefore decided to change my approach to and use the next unreleased version instead, until Jira comes with a way to only fetch the currently active sprint.