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; } } }

Apply new workflow without affecting other JIRA boards

Justine Daway

So there's an existing project that associated with a JIRA Board (Board 1). What I want to do is to mirror the issues from the "Accepted/Done" column of Board 1 onto the "To do" column of Board 2.

I've managed to replicate the issues onto Board 2 by creating a filter. What I want now is to apply a workflow on Board 2 without affecting the status of issues in Board 1. Is is possible for 2 JIRA Boards to have different workflows without affecting each other?

Take note that both Board 1 and 2 are pointing to the same project. And I'm using Kanban for Board 2.

Thank you!!

Accepted answers

Jack Brickey

Justine,

Just to be technically clear, boards don't have workflows. Rather issue types have workflows. I'm going to provide some input here but to provide the best answer I would need more info on your use case.

Method 1: Split a single workflow across two boards.

In the past I had a '2-board' system where board 1 belonged to PLM and board 2 to DEV. PLM would move requests from idea (far left column) thru requirements and then to a ready for development status (just left of far right column) of their PLM Kanban board. PLM and DEV would meet weekly to review the issues that were ready for development and if agreed move them to a DEV Backlog status (far right column) As you can probably guess we had one large workflow where the front half had statuses for PLM and the back half had statuses for DEV with one overlapping status/column. Something like this:

PLM: NEW --> In Progress --> Req Complete --> RDY4DEV --> DEV Backlog
DEV: DEV Backlog --> Under DEV --> Done

So PLM's board had DEV Backlog on far right (PLM's done) and DEV's board had DEV Backlog on far left (development's to do).

Method 2: Leverage two workflows

If you really want two workflows I would use two different issue types each having a different workflow then having the two boards report on the associated issue type. For example:

Issue Type = Feature Request allows PLM to make decisions, work requirements, and mark as ready for development (done).

Issue Type = Apprved Feature allows DEV to develop the feature and eventually move to Done/Closed

In this scenario you can change the issue type either manually or automatically. If you want to retain the issue in the right column then your filter needs to include the issue type for board 2 but only map the Approved Feature status into the right column. Or you may want to have it disappear all together or you may want a column call Dev backlog on the PLM board. Lots of options here.

I hope this helps and all of the details did not simply confuse you. Let me know if I'm on target or I missed.

cheers,

All comments

Jack Brickey

Justine,

Method 1: Split a single workflow across two boards.

PLM: NEW --> In Progress --> Req Complete --> RDY4DEV --> DEV Backlog
DEV: DEV Backlog --> Under DEV --> Done

So PLM's board had DEV Backlog on far right (PLM's done) and DEV's board had DEV Backlog on far left (development's to do).

Method 2: Leverage two workflows

If you really want two workflows I would use two different issue types each having a different workflow then having the two boards report on the associated issue type. For example:

Issue Type = Feature Request allows PLM to make decisions, work requirements, and mark as ready for development (done).

Issue Type = Apprved Feature allows DEV to develop the feature and eventually move to Done/Closed

I hope this helps and all of the details did not simply confuse you. Let me know if I'm on target or I missed.

cheers,

Justine Daway

Thanks for your inputs, Jack!

The reason for having 2 Boards is so I can track ticket movement during the development phase and production deployment.

Development would be for the Development Team and if the Product Owner's approval of the ticket. Business Review would be for the tickets (from Development) that need to be reviewed by customers and if accepted by, deploy them to Production.

Simply put, the Development Board would have this flow:
To Do --> In Progress --> In QA --> Accepted

Then for the Business Review Board:
Accepted (from Development) --> Under Review --> Waiting for Deployment to Production --> Deployed to Production

Based on your suggestion, looks like I can use Method 1.

Another question that pops up with Method 1 is -- will I still see the ticket under "Accepted" in the Development Board as I move it across the Business Review Board? I would think not because moving it means changing the ticket status (and ticket status is associated with a column).

Jack Brickey

Yes method one is exactly what I did for your case and you will not see the issue under Accepted in the Dev board UNLESS you add all of the Production status into that column of the Dev board. In other words you control what shows on what board and in what column. If you want it shown map the status to the column. If you do not want a status shown on a board leave the status unmapped.

Please be sure to accept the answer here if it address your question as this helps future searchers.

cheers,

Justine Daway

Great! Thanks for answering all my questions Jack!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-software