Moving task between boards

[Akakiy Zilbirshtein]

Hi, community!

I have a rather complex development process, and if it were placed on one board, it would have more than 15 columns (statuses). Hence, I want to split this process into 2 or 3 separate boards (e.g., analysis, dev, qa) within one project, so tasks should be automatically moved between these boards. Is it possible to implement?

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

Boards are not issue containers, they are a view of a set of issues.  You don't "move issues between boards" as they are not containers.

You should set up your board filters so that they select the issues you want to see on each board.

[Akakiy Zilbirshtein]

I can't get the idea...

I have the following flow: I receive a business request, create a Jira task, and it goes through the next steps: business analysis -> BRD review - system analysis - FSD review - estimation - approval/prioritization - development - code review - stage deployment - testing - production deployment. In this flow, some steps (statuses) are missing.

On each step, the task is processed by a different user or team. I have no idea what kind of filters should I implement to fit the entire process into 6-8 statuses.

[Nic Brough -Adaptavist-]

In Jira, think of a board as being a team - the people using the board are the team tasked with doing the things on it.

Set up your boards so that they select the things that the team needs to be working with (but include all "after our team" status in the last column of everyone's board, if you want to report on burn-down/up or scrum like stats)

[Akakiy Zilbirshtein]

Got you!

Because of it I want to create separate boards for each team.

[Dan Tombs]

Hi @Akakiy Zilbirshtein

Short answer is yes. You would set up the boards to run on a similar filter and then only set up the columns you want with the final column on board one overlapping with board two so an issue is always visible.

The long answer is your workflow sounds far too long and NEEDS to be addressed. 15 statuses is one hell of a hefty flow. The happy path guideline states we should be aiming for a flow of around 8 statuses max. A large workflow like this wont create a great user experience and could cause developers to get annoyed very quickly. This may be more of a process change then a technical change.

[Akakiy Zilbirshtein]

I know that 15 statuses can be a nightmare! That's why I want to split the entire process into smaller ones. I plan to split the process by teams: Analytics, Dev, Test - in this case, each board will consist of 6-8 statuses, which will be much more convenient.

But task should 'jump' between them.