Automation Issue - Populate target start with sprint start date

Ashley Stephens_510zhb

We are trying to create a global automation for all the projects in our Plan to populate the "target start" field with the start date of the sprint the ticket is in. 

We created the global automation, but instead of populating the start of the sprint, it would populate today's date instead of the start date of the sprint. 

--

This is secondary to my main question above, but I'm thinking about the whole concept of populating date fields and I'm curious of other people's thoughts. In a hardware and software development company, what is the optimal way to plan work and obtain dates while remaining agile? We need to do things like my question above and have dates and plan ahead, but how do we date our initiatives without turning too waterfall? 

Trudy P Claspill

Hello @Ashley Stephens 

This is a more complex scenario than it may appear at first glance.

In your automation rule are you executing a JQL statement in your trigger? If so, what is that statement?

To ensure that your getting the value you expect to set your field I recommend that you add Log actions to your rule to print the values to the rule execution audit log.

https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Log-action

I recommend that you print the following values:

Sprints associated with the issue: {{issue.sprint}}

Sprint start dates: {{issue.sprint.startDate}}

Sprint start date formatted: {{issue.sprint.startDate.format("yyyy-MM-dd")

Also you don't need to use format("yyyy-MM-dd") You could use simply jiraDate to format the date field value correctly for insertion into another Date Picker field.

 

Note that the Sprint field for an issue can have more than one value, as it will retain the value of sprints that the issue was previously assigned to and in which the issue was neither completed nor removed from the sprint before that sprint ended.

And the sprints will not be in any particular order in that field. If the field does have multiple sprints recorded in it, the date selected will be from the first one that is listed as you see them in the Log actions above.  Here is the example output from my run of a manual rule against an issue that had historic sprints listed:

The actual date that was inserted into the field was Feb. 2, 2023, from Sprint 50, which is actually a closed sprint.

 

Might your issues end up having more than one sprint value associated to them over their lifecycles?

Trying to parse through the values and find the sprint that is currently active or planned for the future would add complexity to your rule.