You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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?
Hi - and thanks! Long time reader, first time writer :)
Here is a shot of the overall logic:
Not doing anything custom on much of any of this:
Here is the specific:
The Start Date piece is the same, just using Sprint.start. Everything works great, with the exception of that issue. As to how often... it isn't too bad, but it is glaring, and troublesome when you begin to visually display issues in Plans and use Start and Due date to show timelines.
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.
> 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.
Hi @Alex -- Welcome to the Atlassian Community!
For a question like this, please post an image of your complete automation rule, images of any relevant actions / conditions / branches, an image of the audit log details showing the rule execution, and explain what is not working as expected. Those will provide context for the community to offer ideas. Thanks!
Until we see those...
You may be able to add some conditions to your rule to handle that case. How often does this issue carryover happen?