Best Practices: Strategies for Defining your JIRA Projects Edited

One of the most common questions I get speaking with new JIRA users (and even some experienced ones) is how to best organize their JIRA projects. While there's no one way to organize JIRA projects, there are some parameters to consider. In this article I'll do three things:

  1. Define what JIRA projects are
  2. Detail some common ways of organizing projects in JIRA
  3. Provide some factors to consider as you plan your projects

The goal is that by article's end, you'll be making more informed decisions on plotting out your instance!

What is a JIRA project?

At a base level, a JIRA project is a grouping of work items or, in JIRA terms, "issues" that are held in common. If JIRA issues are a variety of different colored, shaped, and purposed LEGO pieces, projects is a box that hold them. Each issue contained within it will share a common key. So, for project "Lego Castle," issues will be itemized as, LC-1, LC-2, LC-3, and so on. 


Simple enough, right? Beyond that, JIRA projects will stand alone in a few ways.

  1. JIRA project issues will share common potential configurations. Whether they are workflows, fields, screens, etc., available configurations will be defined on a project-by-project basis based off of issue type.
  2. Projects will have their own permissions system, i.e. which groups of users can access the project, which issues they can see, etc.
  3. Projects will have their own versioning or release index, i.e. LEGO Castle v. 1, v. 2, etc., as well as components.

One last thing to note, projects in JIRA aren't by nature terminal. By default, you should consider projects as ongoing efforts. To take our LEGO analogy further, you aren't just building a stock, prepackaged castle; you're adding additional drawbridges, turrets, etc. as you go along in an ever-evolving endeavor.


That said, you can certainly close out and archive projects pertaining to ad-hoc efforts.

So, how do other JIRA users organize their projects?

There are a few common strategies that are commonly taken with respect to organizing projects. Again, there's no right or wrong way - it's simply a matter of appropriate fit.

  1. Releasable product - If you're a software development team looking to make heavy use of the JIRA release and versioning system, you'll want to give strong consideration to organizing your projects by releasable product or groups of work that share a common release cycle.
  2. Team - Team based projects are another common organizational model. This allows your work to mirror your social organization and is convenient in less cross-functional setups, as it allows for more straight forward project permission management.
  3. Business Unit - Closely related to organizing around teams, you might consider also organizing around larger business units - marketing, product, IX, IT, and so on. Types of work will likely fall into similar patterns, making setting up workflows and issue types particularly more convenient.

Within these categories, you can get as granular or as broad as you want or you can even mix and match - just try to mirror your organizational habits and proclivities in your project setup.

A note of caution on Team and Business Unit setups: If your business is prone to consistent reorganization, this could create quite a bit of headache for you as a JIRA administrator. Merging projects and project settings can be cumbersome, so consider your organization's stability before proceeding.

Other Considerations

So what else might you want to factor into your decision making?

  1. Components - Be aware that you can still sub-categorize issues within a given project using components. Perhaps you have a small mobile team that does a lot of work both on iOS and Android. Rather than split them up into unique projects, think about using components, or even a custom field, to further parse out your work.
  2. Independence - Let's go back to the mobile team. While in some cases iOS and Android developers might want to work out of the same project due to high correspondence in release cycles, proposed feature, etc., if the two efforts are entirely forked, the work could be disparate enough to justify separate projects. Requirements over time could develop to be entirely independent and justify separate projects rather than a shared one.
  3. Boards - A lot of users assume that boards need to correspond to projects 1:1. This isn't the case! Since boards are filter-based, they can map to multiple projects. Don't let a boards restrict how you schematize your projects.

So there you have it! While this isn't a comprehensive rundown of what considerations you might make in terms of project organization, it should help you get started and stir up some ideas.

If you've organized projects in alternative ways, feel free to comment below!

Footnote: This article is a bit of a starters guide to JIRA projects and how to get going quickly. If you're interested in diving further into the nitty-gritty of JIRA Software, nothing beats a deep read of our "Configuring Projects" documentation.


Nice overview of how to work with projects in Jira, thanks!

Another way to organize projects is to match to "business projects". For example you have a project with a specific customer: several teams will work together, maybe several applications impacted (so you could need to have projects organized for releasable products in parallel and linked issues between "bussines projects" and "releasable projects"),...

A common concern is also about the size of the project versus the number of projects. Is it better to have one big project (maybe with components to organize it) or several small projects?

I guess here it really depends from one individual to another.  But some stuffs one could consider to contextualize as much as possible the day-to-day work: do you need many different issue types between business projects? Are there many differencies in the screens/fields/workflows steps you need from one "business project" to another?

I tend to think that small projects are more manageable, above all if they can share most of their configuration. Given cross-project reporting is possible it does not represent a barrier.

I keep explaining the same thing to my users.

It's also possible to organize projects by the type of work that need to be done. If everyone is managing some issue type the same way, you could have a project just for these types of task.


If your business is prone to restructures try using something stable like Value Chains or Industry Service Models. These should only change if there is a fundamental change to the business, instead of when managers just try to carve out bigger teams ... 

Hi Leroy,

So you would make one Jira project for one activity of your value chain?


Denis, your method sounds interesting, do you have an example?

Hi Nic
We have "BAU" ones at Value Chain level, so one for Marketing, Sales, Operations, Customer Service, etc and a few for supporting Functions like IT, HR, Finance, Risk and then we have a JIRA Project per Business Project. But they are all using the same Schemes which we have kept simple (only 2 workflows). We then use JIRA Portfolio Shared Teams (vs another Custom Field) to identify Accountable Teams.   

But do agree with Denis, in an ideal world your whole Enterprise could you use one project! We should be guiding business to a simple solution not acceding to trying to replicate every teams complicated, highly managed business process. 

Yes sure keeping the things simple and avoiding to replicate is key.

On the other hand, one generally like to have a synthteic view of projects so all business project under one Jira project doesn't necessarily answer to the needs in the best way. Even if the workflows, issues, ... are the same and even if you propose lots of filters.

Finally it's all about finding the right balance, a tough but rewarding excersise :-)


Log in or Register to comment