nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Is there a way to move issues to a diff team's board in JIRA after the issue is resolved in sprint?

Emily Parks

Is there a way to move issues to a different team's board in JIRA after the issue is resolved in my team's sprint? I would like to move issues to a different team's board in JIRA after my team closes them in order for the issues to undergo the UAT process, which will be led by a different team and different workflow. I would like to avoid adding sub-tasks to my team's sprints as the UAT process will undergo different worklow steps and under a different cycle time.

Also, I do not want to lose the data that tells us when the ticket was complete within the development sprint.

Any ideas?

Accepted answers

Todd Winton

Emily,

In our development workflow, the last step for the developer is resolved. The next step is for UAT. if UAT passes, then to deployment and closed. We are recording UAT date time with UAT notes, deployment date, and closed date.

The UAT board is filtered to only show those issues in UAT.

Another option is that if you have script runner, on resolution as a workflow post function, the issue can be cloned as a differnt issue type

Nic Brough -Adaptavist-

>move issues to a different board

No, because that's an incorrect assumption about how it works. Boards do not contain issues. Projects contain issues.

Boards show you a view of a set of issues.

What you want to do is set up the boards so that when an issue reaches a point in its lifecycle, one board stops selecting it and another one starts to.

There are a couple of really easy ways to do this. Imagine a workflow is generally:

New -> in dev -> ready for test -> in test -> done

Option 1:
Board 1 for devs has columns for New, in dev and ready for test.
Board 2 for testers has columns ready for test, in test and done.

Option 2:
Board 1 filter: project = abc and status in (new, in dev, ready for test)
Board 2 filter: project = abc and status in (ready for test, in test, done)

All comments

Todd Winton

Emily,

The UAT board is filtered to only show those issues in UAT.

Another option is that if you have script runner, on resolution as a workflow post function, the issue can be cloned as a differnt issue type

Nic Brough -Adaptavist-

>move issues to a different board

No, because that's an incorrect assumption about how it works. Boards do not contain issues. Projects contain issues.

Boards show you a view of a set of issues.

What you want to do is set up the boards so that when an issue reaches a point in its lifecycle, one board stops selecting it and another one starts to.

There are a couple of really easy ways to do this. Imagine a workflow is generally:

New -> in dev -> ready for test -> in test -> done

Emily Parks

Makes perfect sense. Thank you to both of you for your replies. Appreciate it!

Emily Parks

Thank you!

Emily Parks

Makes sense. Can you help add sprint & board type to your example? Say Board 1 is a scrum board that uses a 2 week sprint and Board 2 is a kanban board. How do I understand that the team for Board 1 met sprint goals? Is the sprint for Board 1 closed in the same way as before?

Nic Brough -Adaptavist-

The board types don't matter here. Board 1 selects a load of issues and allows the users to work with them in either Scrum or Kanban ways, depending on the board type, and board 2 does the same independently. They both act on the selection they make from the underlying list of isssues, so changes in one affects what the other sees, but they don't really interact directly.