Moving Issues from One Project/Workflow Scheme to Another

Question

Hi community,

Need suggestions!

We have two projects: One project is strictly used for the purpose of prioritizing features and selecting which features we want our engineering team to work on - let's call it "Feature Priorities." The other is used for the development/deployment process which only our engineers and product team uses -"Development Process."

Once an issue has moved to the final status "Selected for Dev" in our Feature Priorities project, it means that the issue is now ready for our Development Process.

Currently, I've set up an advanced filter to show these issues in the Development Process's project's backlog. However, because the issues live in the Feature Priorities project... I do not see the statuses that are associated with the Development Process's workflow scheme.

Not sure what to do.

1. Do I move the issues directly to the Development Process? And if so, I see there are ways to bulk edit/move issues but is there a way to automate this? Perhaps with the Jira Misc Workflows Extension?

2. Do I simply find a way to change the workflow scheme? Is that possible?

I'd like to keep these projects separate so as not to overwhelm our engineering team with thousands of backlog issues that have yet to be prioritized.

Appreciate any insights. Thanks!

Marlene Kegel - codefortynine · Answer

Hi @Tori Cook,

You mentioned that you're thinking about creating "a new issue in Dev Project that is linked back to the Feature Priority issue".

If you plan to do this on a regular basis, you could save a lot of time with our cloud app Deep Clone for Jira.

* Clones can be moved to other projects or issue types while cloning
* It's possible to create clones automatically on transition with a Deep Clone post-function
* You can create presets for recurring cloning actions
* You can bulk clone several issue at once
* A link between the original and the cloned issue can be created
* And much more that might help to save your time ...

If you have questions or feedback about Deep Clone for Jira, don't hestiate to contact our support.

Tori Cook · Answer

Thanks for your suggestions!

I need to think on this a little. One of the challenges is that we have an integration with our CRM so feature prioritization JIRA issues are linked back to service tickets in our CRM. We want these to always stay in sync and we'll want to know when these featured are pushed live in our prod environment so we can let our contacts know a feature has been released! I suppose I could create a new issue in Dev Project that is linked back to the Feature Priority issue... when it's closed in Dev and released to prod, then automatically update the Feature Priority issue's status to closed... I wonder if it is possible to trigger a status changed of a linked issue...

I will also consider the single project idea. I had initially considered one project with multiple boards, but because we are integrated with our CRM, when we create JIRA issues from our CRM we can only choose what project to associate it to... not boards.

Brant Schroeder · Answer

@Tori Cook

This is an excellent question and there are several different ways you can go about it.  For me I really like to keep things simple so I will provide some additional solutions to consider.

Recommended Solution for Current Project Configuration

Retain two projects and keep them entirely separate so you can have incites from both.  I would recommend that you close out the issue in your features project and as part of the workflow you trigger the creation of a new issue/issues in the development project using JSU or ScriptRunner and link them to the closed issue in the features project.    This will allow you to report on issues in the features project still (How many features approved in a given month, year, etc)  It will also make for a seamless process to get the issue created in the development project at the proper time.

Additional Option

You could update your workflow and work out of a single project.  You can hide issue from the developers until they have been approved using issue security.  When the issue reaches a certain point in the workflow the issue security changes and the developers can see the issue.  This would take a little work up front to create / adjust the workflow and implement issue security but would not require any apps and would allow for the same reporting to take place based on status.