JIRA Automation: Sprint Dates Copied to Start Date & Due Date

Question

Hi All -

I have a variation of the fairly common question of using automation to copy sprint start/end dates to "Start Date and "Due Date".

My issue is not with the copy itself. That works fine. What I am running into is if an issue spills over to an additional sprint, the automation runs, and it copies the dates (again) from the Original Sprint.

Has anyone worked out a solution for this?

Mario Rusch · Answer

Hey ho, maybe this helps.

How to update a story's target start and end dates based on the sprint dates using Jira Automation | Jira | Atlassian Documentation

They explain why the added "last" to the smartvalue. Basically they want to have the sprint dates of the latest sprint in the issue. This won´t work with parallel sprints, as they stated in the documentation.

Greetings Mario

James Czerlonka_bhuumi · Answer

> What I am running into is if an issue spills over to an additional sprint, the automation runs, and it copies the dates (again) from the Original Sprint.

I just spent a good while trying to figure this out. I would try appending ".max" to the "startdate" and "enddate" part of your smart value. Seems to have worked for me though I'm still testing it out.

Bill Sheboy · Answer

As a suggestion, when responding please try to stay with the same thread.  That will help others in the future know if there are multiple solution approaches for a question.

For the image you show, I notice your rule is triggered on a change to the sprint field.  This will happen any time the value changes.  My question is, "when do you consider the value accurate, to support your use of planning?"

It may be better to trigger on Sprint Started, as that is when the issues are planned for a specific sprint.  Your rule could then have logic to handle what you want to do when there are existing values in the Start Date and Due Date: replace them, leave them as-is, or a variation of that.  (For example, only change the Due Date as the story has carried over in time.)

An exception might be if work is added after the sprint has started.  That could be detected with a different rule: sprint value changes, and the updated sprint is active.