I need to switch a task automatically from one sprint to another depending on the last edit date. I'm new to jira and I'm not sure how to automate this process.
ex.: I need task 1 to move from A to B within X time, but when in B it can go to C in Y time.
A, B and C are sprints and X and Y different time periods to consider in automating the change.
Hello @Juliana Fernandes Martins
Welcome to the Atlassian community!
Are these all active sprints running in parallel?
Typically an issue is assigned to a sprint when the commitment is made to complete the work of that issue within that sprint. It remains in the sprint until the sprint ends. If the work is not completed, then the issue is either moved to another sprint or moved to the backlog.
Can you provide more information about your scenario? What problem are you trying to solve by moving issues from one sprint to another based on when the issue was edited?
Thank you for replying!
They are not sprints running in parallel.
The idea of having this change is to organize the period before a sprint, which is currently not happening in an organized or periodic way. In general, the sprint that is taking place will not suffer from such an alteration, since it follows the logic of one.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I think I am still not really grasping your use case. Are you trying to automate sprint planning?
Can you provide a detailed example with fake issue IDs and sprint names, and Last Updated dates to walk us through how you would expect this to work?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Of course, I can detail better. I apologize for not being clear earlier.
You are correct in understanding to organize sprint planning, but it is also to remove old and de-prioritized items.
Currently the area that will take care of organizing the jira is under construction, therefore, the current period of the company has a planning organization and jira backlog somewhat messy and dirty with items that should no longer be developed for various reasons.
The idea is to be able to move items from one sprint (which is not and will not be active) to another to be able to organize the sprint planning according to some criteria.
An example would be moving from sprint ID 10 title '10 - design' to sprint ID 13 title '13 - dev' if 30 days pass after the last task update. (names, id and time all fictitious)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Are the sprints you are moving the issues from and to going to be static? Will it always be from sprint ID 10 to sprint ID 13, or are you going to be creating new sprints such that the issues might be moved from a sprint with a different ID to another sprint with a different ID?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I would recommend that you use a Scheduled Trigger for your automation rule.
- Set the Rule to run daily.
- Include in the trigger a JQL to select issues; i.e.
updated < -30d and sprint not in openSprints() and statusCategory != Done and project=<yourProject> and type = standardIssueTypes()
(If you have additional criteria constraining the issues in the board, like checking for issues with specified Component values, add those criteria to the JQL.)
- uncheck the box that says "only include issues that have changed.
The next step would be an Edit Issue action.
- This action lets you select fields from a list and specify the value to put in the field. However, for the Sprint field it will not let you specify a specific future sprint by name or ID. So you have to use the More Options option, and set the field through JSON, thus:
- Where I put 47 you would put the ID for the sprint.
And that's it; just a trigger and a single action.
You would need one rule for each date range/sprint pairing, using appropriate JQL for each trigger; i.e.
Issues not updated for more than 10 days, but not more than 30 days
updated < -10d and updated > -30d
Issues not updated for more than 30 days
updated < -30d
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.