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.
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:
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.
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).
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.
Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs