Automation for all Sprint Items (Active or Future Sprints) To take Start and End Date

[kunal.matharu]

Hi, I'm looking for an automation that takes the sprint start and end date for both active and future sprints reflects this to all the items within its respective sprint. Also an additional automation for when the sprint is closed and items that have not been completed spill into the next sprint and automatically reflect the new end date of the sprint.

[Bill Sheboy]

Hi @kunal.matharu 

Would you please explain the problem you are trying to solve?  That is, why do this?  Knowing that may help the community to offer better suggestions to solve that problem.  Thanks!

Until we know that...

I suggest only updating the issues in the current sprint, updating them based on the Sprint Started trigger for the rule.  That will improve the accuracy of the change, and eliminate any churn in values from repeatedly updating the dates before the sprint starts (due to issues moving between future sprints).

Kind regards,
Bill

[kunal.matharu]

Hi Bill, we are trying to use advance road maps and we do not want it to be a manual add a start and end date to each issue. This way we can plan our Releases and scope based on the teams velocity and visually view the outliers right away. 

[Bill Sheboy]

Thanks for that information.  Please note using this approach reduces autonomy of agile teams as it may set expectations for people outside of the team that the forecasted dates are commitments, set long before sprint planning has occurred.  Regardless of that concern...

Challenges with automating these dates are: issue carry-over when not completed in a sprint and determining which sprint to use for source dates.  You could try a multi-step approach:

• Initially, use JQL to find issues and bulk-update to set the dates.  That will establish a baseline point.
• Create an automation rule, suggested earlier, when a sprint starts, set / reset the dates
• Create another rule, triggered on a change to the sprint field for an issue, which tries to set the dates for issues in future sprints.  I note "tries" because there are problems with the changelog and the sprint field in automation rules.  It may not be easily possible to accurately determine the dates when there are multiple values in the sprint field for an issue.  And the max / min functions cannot be relied upon with the sprint date fields as you may replan issues for different timeframes (earlier or later in the future).
• Finally, consider creating one final rule, trigged on sprint completed, and decide what should happen if issues are not completed during the sprint, carrying over to future ones: no change to dates, clear the dates, etc.

[kunal.matharu]

Thank you @Bill Sheboy  for the Inputs, I will try following steps mentioned above and creating an automation around this.