Create rule/automation to Fix versions and Sprints

[Anastasiia Peshekhonova]

I`m trying to create a rule if value changes for Fix versions then issue field Sprint updated to value of fix version. 

So, it should work in such way:

- the task updated to fix version #1, so the Sprint field updated to Sprint #1

[Nic Brough -Adaptavist- · Accepted solution]

I'm afraid the previous answer was written by an AI, which has no idea what it is talking about when it comes to the smart values it mentions in the last line.

There's a whole pile of problems with this idea:

• Fixversion is accessed with {{issue.fixVersions}}
• But that's not a string, it's a version object, so you probably want to use name - {{issue.fixVersions.name}}
• And fix versions can contain many values, so you need to iterate over it, for example 
• (Copy and pasted from the docs, to save you having to read them)

  • This issue is part of the following releases: 
    {{#issue.fixVersions}} 
    * Fix version: {{name}}, released on {{releaseDate}} 
    {{/}} 
    
    // returns This issue is part of the following releases: 
    • Fix version: Version 1.1, released on 2019-08-10T00:00:00.0+0000 
    • Fix version: Version 1.5, released on 2019-08-02T00:00:00.0+0000

• The Sprint field is a different type of field from the version field, and they don't have directly compatible data
• Sprint cannot be directly edited, you can only move issues between the backlog, an active sprint or a future sprint
• And the killer:
• Automation has no "move issue around the backlog", let alone between sprints

May I ask what problem you are trying to solve with this automation? 

Moving issues between sprints is not something you should automate really, sprints are supposed to be planned by the team.

[Anastasiia Peshekhonova]

@Nic Brough -Adaptavist- 
The challenge is planning sprints ahead. It is important that filling was partially automatic. Issues from a particular release were automatically attached to a sprint with the same number. However, this is only partial planning. The rest of the sprint planning is manual. 

Therefore, I wanted to set up a rule, if an issue is assigned a specific release, it is automatically attached to the sprint with the same number. And if the release number inside the task changes, then the task is automatically transferred to another sprint.

As far as I understood from the answer above, this is not possible, because fix versions and sprint are different entities.

Is there any way to have tasks from the backlog automatically attached to the sprint or is there a workaround?

[Nic Brough -Adaptavist-]

The "workaround" is to do sprint planning properly. 

Issues should not be assigned to a release - you can't know if an issue will be done at aa a fixed time, and you certainly can't know which sprint an issue will be selected for.  Imposing that breaks the whole point of being Agile and using sprints.

Two changes you should make to your process:

• The team should work together to work out what things should (ideally) go into each sprint.  Do not try to automate this beyond ranking issues.
• Swap the version/sprint relationship.  The stuff that gets done in a sprint should be bundled up as a version.

[Frederik Vantroys]

Hi @Anastasiia Peshekhonova ,

• Set the trigger condition to be "Issue field value changed" and select the "Fix versions" field.
• Add a condition to check if the new value of the "Fix versions" field is not empty. This ensures that the rule only triggers when a value is added or updated.
• If you don't want this to happen for all issues in Jira, add a condition so it only works with tasks or story, ...
• Add an action to "Edit issue" and select the "Sprint" field.
• In the action configuration, set the value of the "Sprint" field to "{{issue.Fix versions}}". This will dynamically populate the value from the "Fix versions" field into the "Sprint" field.
  Save the rule.

[Anastasiia Peshekhonova]

@Frederik Vantroys  I did, but the rule don`t work( 
Maybe my changes are not correct? 

[Anastasiia Peshekhonova]

On the example of this task, there is an error in the logs - the sprint was not found.

In this case, the name of the sprint is the name of the fix version.