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 :-)

Has anyone tried the new Jira interface yet?.. I think its only available to some cloud users.  I wasn't too worried prior about using multiple projects within a board since the main menu has a "boards" pull down to help decouple boards and projects. The new interface however.. couples the two more. Now.. to get to a board, you need to goto it's project first and then select the board.  I'm afraid it will make it less intuitive to use a single board to track & manage multiple projects.

Link to information about new interface

Matthew Wong Atlassian Team Dec 01, 2017

Hey Adam,

That's correct - a board will need to be housed in a project. This doesn't limit the board from consuming issues outside of the project it's housed in.

If you need to delete a board to avoid clutter and confusion, you can still do that by navigating to - /secure/ManageRapidViews.jspa. This will prevent multiple boards accounting for the same collection of issues.

OK - Just getting my head around JIRA - so it seems pretty clear that a 'project' comes with a bunch of settings which all issues within the project will share  - and Boards are independent (filtered) views of issues from across projects. That seems clear so far and makes for a very straightforward flexible system. 

But then when in project view - it says "boards in this project".  that's not immediately making sense to me - can you explain how a board relates to a project so that it's 'housed in it'. I don't get this relationship, or it's purpose, and would be grateful if you can help me understand it better. 

We have teams that deal with multiple projects, and projects that cut across multiple teams, we also have BAU work that needs to be organised within each team. How do you suggest we set this up in JIRA?

If we have common 'component names' between projects can I filter all issues tagged with 'component x' from across projects into one board ?

The "boards in project" is a recent thing.  Previously, boards were completely separate from projects, but there was a clear problem in that a lot of people who did not understand the basic relationship, and believed that they did.

So Atlassian changed the UI to make it easier to find the boards that might be related. 

I think they've made a mistake in the wording, as boards still do not belong to projects, I'd have preferred wording that suggests the relationship, rather than suggesting that boards belong to projects.  I don't really know how to shorten "board may be showing issues from this project"

So, when I say "basic relationship", I mean

  • Boards still do not belong to projects
  • A board can include issues from projects, so that's when a board should be shown as having a relationship

Thanks Nic - that helps to clarify.

We' plan to set up one 'JIRA project' per team allowing each team to set their 'components' and team managers to set workflows. We'll use boards to represent our 'projects' which cross cut the teams.

Based on what I know, this makes sense, but please shout if you see any pitfalls in this plan.

Once again, many thanks for the help.

Matthew Wong Atlassian Team Dec 13, 2017

Hey Damian,

Based off of your description, I don't see any reason why your proposed setup should not work. Your projects will organize issues by team and then your boards will be predicated upon components and will cut across projects. No problem there.

The only thing that I'd caution is that agile metrics, whether it is velocity, burndown, et al., have a direct 1:1 relationship with particular boards and not projects. Burndown, for instance, is calculated based on how quickly issues are being resolved on your board.

In short, in your scenario, your agile metrics will be predicated on your cross-functional boards and not on your actual "team," i.e. the framework that you've chosen to organize your Jira projects around. Just something to consider, especially if you're going to be leveraging the out-of-box reports.

Pitfalls - totally the opposite, it's what I would do with your setup! 

Matthew -

I'm assuming that we can have one board per cross-cutting project as you described and also another board for the team leads to use to output velocity/burn down for their team only (which will include their BAU component tasks) 

- Good to know the velocity and burndown are based on boards - I hadn't picked that up before.
-  this way means that most of the issues will appear on 2 boards.  One for team management, and one for project management.  - Let me know if I've stopped making sense.

// -  I'm thinking of a 'board' as being similar to a music 'play list' -  issues are the music tracks - projects are 'albums' -  so an issue can appear on any number of boards, but originates from one project. //

Thanks Matthew and Nic - This is all good thinking, and the assumptions I'm making need to be challenged.  We've also looked v briefly at Portfolio for Jira  - in the hope that we'll be able to integrate this for our Change and PPM team. and capture some critical high level MI reports.

I'm at the very beginning of a long (and probably very bumpy) journey, so setting up the best foundation is going to be key. -

  - am really appreciating this Jira forum positive attitude. - Thank you.

Matthew Wong Atlassian Team Dec 14, 2017

Hey Damian,

Your analogy is on point! Your proposed workaround works, as well. I'd just make sure to be consistent with which board you do your sprint planning and execution.


Log in or Join to comment
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

2,770 views 11 18
Join discussion

Atlassian User Groups

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!

Find my local user group

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

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot