Should each Jira Project have its own work flow?

Simon Chadwick

There are two parts to this questions.

1. Is there any savings in ether compute and/or DB size in having JIRA projects all following the same work flow? We are running JIRA on our own servers and not it the cloud. 
2. Is it good practice to have all projects/scrum teams following the same work flow (we have multiple teams working on different things)? Or should each team/project setup their own workflow depending on how they work?

I know this 2nd question is a bit open but just trying get an initial understanding of how we should proceed with our setup.

Thanks in advance.

Jonas Andersson

I suggest to reuse as much as possible in Jira. If you can limit the amount of used permissions, workflows, screenschemes and so forth, the easier it gets to understand for the end user. What i suggest is to increase the amount of issuestypes, and use the same workflow for these issuestypes across all projects. This makes it easier to create JQL filters that are looking for specific statuses.

A good example might be a procurement process, where individual departments has their own project, which all contain a procurement ticket issues type. A part of this ticket can be price, description, business case. With this setup you can now create JQL filters that allows you to line up all procurements still open, the price of these. By a simple change in what projects you are searching for issues, you can now see the global outstanding procurements, or cherry-pick what all development projects outstanding procurement costs are.

The same could be applied to change management, allowing you to line up upcoming changes, within a department, within a datacenter, within the whole organization.

I base this on 10 years of experience of administering Jira.