How do I move stories from one board to another, or one project to another automatically?

[Craig Krohn]

I currently have a team based project.

I want to split the project from software development, into an additional board/project for QA. That is, once development tickets are completed, and move to testing, I want those test tickets to appear in the QA board. How do I do that?

We are doing one week sprints, with an off sprint release cycle for QA. How do I make that magic happen?

[Trudy Claspill]

Hello @Craig Krohn 

Welcome to the Atlassian community.

Could you clarify - are the QA's working in sprints also?

What problem are you trying to solve by tracking Development work completion separately from QA work completion for the same item? Is the item considered "done" after the development work is complete, or must the QA work also be completed in order for the item to be truly "done" and releasable?

Moving work items from one project to another will mess up the Sprint reporting for the first project. I advise you not to move the issues between projects because of this.

Having an item stay within the project but be "complete" for Development in one scrum board with status A, and then transitioning the same item into a new status that makes it "incomplete" in a new QA board (for the same project) can also mess up your sprint reports.

If you want to track Development work in sprints and track QA work in separately (in sprints or kanban), and keep your Development sprint reports accurate, I recommend that you use entirely separate issues for Development and QA work.

[Craig Krohn]

So our team is 16 devs, 4 QA. And we just transitioned to Scrum. We are doing one week sprints for a few months until the team is used to estimating work for the week before moving to 2 week sprints. 

I wanted to split the team in 2 teams, but I don't think that's the right move just yet. But down the road that should happen.

Team codes one week. On off sprint, QA tests, and we deploy. Rinse repeat.

The Jira board however is huge as a result. And I wanted to eliminate some of the noise of testing when working with the development effort and vice versa. Suggestions are welcome.

[Trudy Claspill]

Thank you for that additional information.

I still need some clarity on the separation of Dev and QA work. I'm not sure if I'm asking the question clearly.

Does the work item remain "incomplete" at the end of the Dev sprint (Sprint Burndown does not burn down the work items as Dev work is finished) and move into the next sprint for QA work? 

Or at the end of the Dev sprint do you expect the sprint burndown for that sprint to show the work items as "completed" if the Dev work is done?

Is the project type Team Managed or Company Managed? You can get that information from the Type column on the View All Projects page under the Projects menu?

I'll need the above information to make a meaningful recommendation.

[Craig Krohn]

We are team managed currently. I was wondering if one of the solutions was to switch to company managed, and just 2 boards for one project.

The stories move to "Test" and stay there until deployed. Problem is, the sprint ends, and these stories are not deployed yet. So the metrics and burn down isn't pretty. The following week we do a deploy, and then those stories are closed out. But all of the current dev stories will then go to test, and sit there until after the sprint is over. Also if there is any carry over work, then the sprint gets very heavy. Especially with so many on the team. 

What I'd like is to have a system where once dev is done, it's done. And then those stories get kicked to QA. Maybe that's a new board, new project, or maybe that's solved with a better workflow within the same project. I'm not sure! 

[Trudy Claspill]

So, the work item moves to "Test" when dev is done, and doesn't move to "done" until it is deployed? And you can't tell if testing is actually completed or in progress or not started?

What I'd like is to have a system where once dev is done, it's done. 

I would ask you to consider carefully what the root problem is that you are trying to solve by considering the work to be "done" when only the development work is complete. There are other options for reducing the "noise" on the board. And while you may think the burndown metrics are ugly and the sprints heavy, is the work really done if it isn't tested and deployed?

Do you use the Release functionality? If so, perhaps when testing is complete you can set the issues to Done, and set the Fix Version for each work item, and then track if the deployment is complete using the status of the Release instead of the status of the work item?

You could also use Custom Filters on the board to reduce the display of work items in the sprint to those of interest. For example you could have a custom filter that is:

status not in (Testing,Done)

...to reduce the display to only the issue Dev cares about. Using Custom Filters on the board is one way to hide the "noise".

If you really want and need

1. the Dev team to get burndown credit in a sprint when they complete their part of the work, and
2. the QA team to get burndown credit in a sprint when they complete their work without affecting Dev's burndown, and
3. the wait until deployment to not affect either of those

Then at a minimum you will need separate work items; one for each of those phases of the work. Whether those work items are in separate projects also is not necessarily required, but may be needed depending on your workflows and board configurations.

Moving one work item through different boards/sprints segregated by "phase" (Dev work phase, QA work phase, deployment work phase) is going to mess up the sprint reporting for each phase.

In my opinion, it would give you cleaner reporting to have a separate work item for each phase for each thing you are developing, QAing, and deploying.

That is, however, not quite aligned with the basic scrum methodology, which is the work item is not complete (and burned down) until all the work is complete and the "definition of done" is met entirely. Generally the "definition of done" means the item is ready to release or has been released, which means the testing is also complete. I don't want to digress into a debate on how scrum should or should not be used. People have strong opinions on that topic. My goal here is to try to help you meet your requirements by telling you pros and cons of solutions.

If you feel you must be able to show burndown in the Dev phase and the QA phase and the Deploy phase separately, and opt for the three-items approach, that could make it more challenging to determine the state of the "thing" being developed, You would have to look at three separate work items to determine the status of the "thing". You could make those three items children of an Epic that represents the "thing". Epics are normally used to track the status on a larger scope thing, though, and you may already be using Epics for exactly that.

I see you have the Premium subscription, so you could theoretically use Epics and the three-child-items as I suggested, and create another work item level above Epics for the larger scoped item that encompasses Epics. However, the issue hierarchy is a global definition, and changing it might not be an option in your environment.

If you choose to opt for the three-item approach, you do not necessarily have to stop using your Team Managed project. You would have to add new Work Item types to it, and you may need to make workflows specific to those work item types.

Team Managed projects don't support multiple native agile boards, and creating separate boards based on saved filters results in boards that don't behave quite the same way as the native board. So you might have to adjust the mapping of Work Item Statuses to columns in the board and modify the column names.

You could use the Type filter within the board to display the work item types relevant to the team (Dev, QA, Deploy) with whom you are viewing the board currently to reduce the "noise" on the board.

Or you could consider using separate but parallel sprints; one for Dev, one for QA, and one for Deploy, and use the Sprint filter to show what is relevant to the team currently viewing the board.

The pro for conversion to a Company Managed project would be that you might consider if you could use sprints just for Dev and kanban for QA and Deploy. In that scenario you could keep the "thing" as one work item. You could map all the statuses relevant to the QA and Deploy work to the last column on the Dev Scrum board. From the Dev Scrum point of view, the work items would be considered complete, and not disappear from the sprint history if moved to other statuses that are relevant only to QA and Deploy. You could then set up Kanban boards for QA and/or Deploy with the statuses relevant to those phases of the work.

The con with this is that your QA and deployment efforts are not tracked in sprints.

Also, "converting" between TM and CM project types is not simple and can result in loss of data. You may be better off starting fresh in a CM project going forward with issues that are only in the backlog of the TM project, and finishing out in progress work in the TM project.

I hope I've given you information that can help you figure out the right path for your team.

If you have more questions, don't hesitate to ask.

[Craig Krohn]

Thank you this is awesome information I needed. You've given me a lot to think about. :)