Moving done issues to next sprint automatically

[Sarah Fajerberg]

Now, I don't want any agilists to come after me. I'm just curious about the technical feature part of Jira.

When you finish a sprint and ask Jira to move unfinished issues to the next sprint, is there a way for issues that ARE done to move into the next sprint? Like an automation or rule. Especially if you have multiple different "done" status types. 

[Walter Buggenhout · Accepted solution]

Hi @Sarah Fajerberg and welcome to the Community!

Even though I am very much interested in agile ways of working, I'll stick to the technical part 😅

An issue is considered completed when it moves to the rightmost column of your scrum board. The only way you can make these issues appear in the next sprint, would be by adding your new sprint to the Sprint field on those issues. I have never tried this before (and am not really tempted to try even in a test instance), but theoretically it should be possible to do this with automation like this:

Still, can't help to ask Why? You can always put a list of resolved issues by sprint on a dashboard instead 😉

Hope this helps!

[Callum Carlile _Automation Consultants_]

Hi @Sarah Fajerberg 

As @Walter Buggenhout said - "An issue is considered completed when it moves to the rightmost column of your scrum board"

So if your column for your 'Done' issues wasn't the column on the far right of the board, the issues in this column wouldn't be seen by Jira as 'Done' and therefore would move into the next sprint (such as the below).

The main issue with this setup is that the number of issues in your sprint would accumulate as nothing would ever be 'Done' in the eyes of Jira, but that's how technically you could configure it

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

You could do it with an automation (sprint closed is a trigger, and you could add the new sprint to the issues).

But I would question why?  "Done" means done - it should need no more attention from the team, so there's no point putting it into another one of their sprints.

I can see a use for this when you've got a process where one team's done is another team's to-do, but that's going to get complicated because you'll be putting stuff into a sprint from a different board/team, not the current one.