What's the best way to moving tickets between boards?

[Jeff Wogan]

Our team has decided that the definition of done is once the developers have completed unit testing.  We want to then move the ticket to the QA Team's board.  The QA Team will be a sprint behind the Dev Team.  So when Dev is working on Sprint 2 tasks, QA is testing task from Dev's Sprint 1.

Here's the problem.  I moved all the DONE tasks from the Dev Board into the QA Board and then closed the Sprint on the Dev Board.......and the tasks were removed from the QA Board.

Can someone helps us configure the board so the behave like our intension?

Thanks

[Scott Theus]

Hi @Jeff Wogan

The boards are just visual representations of the status of the issue(s), so when you close out the Dev board and mark all the issues as DONE the issues are considered completely resolved. Since the status of the issues are DONE there is nothing for the QA board to display. Having separate sprints for QA and Dev can be tricky; in Jira the only way I can think of do that is to have two separate projects; one for Dev and one for QA. 

Here is what I suggest:

• Create a new issue type for QA testing, then create one issue to test all the Dev work from each sprint.
• Sprint 1 starts with just Dev issues. 
• Following with Sprint 2 through Sprint N you include the Dev issues for the sprint, plus the QA issue to test the Dev work from the last sprint.
• Your DoD for your QA test issue is the completed regression testing of Sprints 1 through X-1 (where X is the current sprint)
• The final Sprint N is just for regression testing and bug fixing for the entire release.

Doing it this way will allow your Dev team to have a 2 week sprint, release that code to QA, who then tests the code one sprint behind. 

Of course, this is not really "Scrum" strict "Agile" since the goal of the scrum team is to have a shippable product release at the end of each sprint, but I won't tell anyone if you don't. 

Hope this helps, 

-Scott

[Jeff Wogan]

Thanks Scott.  Yeah well ya gotta work with what cha got.

[josh]

This is a little difficult. The best thing to do would be to write stories that dev and qa can both complete in the same sprint and get them on the same sprint cadence and board.

Using two boards and two sprints will mess with reporting such as burndowns. The issue will appear as incomplete in Dev's board. But if you must;

You'll need to build the workflow in such a way that the rightmost column of the dev board is the backlog of the QA board. for instance

Open->In Progress->Resolved --> Testing --> Closed

Where the Dev board uses only Open --> In Progress --> Resolved

and the QA board only uses Resolved -> Testing -> Closed

Another option is to have the dev board use a kanban board. It would seem that your QA team will always work on the dev completed issues as they flow in, this may help with the reporting.