It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Best Practices: Strategies for Defining your JIRA Projects


@Tom_Synnott- sounds like a custom field to me.

@Matthew Wong I am using the nex-gen projects which are great. How would I set it up on these?

@Tom_Synnott , as @Nic_Brough__Adaptavist_ you would need custom fields at project level for this, a marketplace App is required for this. You can check out Profields, which was created precisely for this type of need.

For full disclosure, I work for DEISER, the manufacturer of Profields. But I only recommended when there's a good fit ;)

Matthew Wong Atlassian Team Mar 18, 2019

Hi @Tom_Synnott ,

Agreed with Nic Brough.

If you have projects that are all dedicated to a single customer, my suggestion would be to come up with a good naming conventions with your projects that include a customer name. For instance, if your customer is Acme and you have a web app and a mobile app project for them, create an Acme Web App (ACWA) and Acme Moble App (ACMA) project.

If there are simply handfuls of issues in any given project dedicated to particular customers and you'd like to track who that issue belongs to, I recommend a custom field with a dropdown that lists all of your clients. This is possible both in next-gen and standard projects.

you use "category" for that and group projects within each category

Hi Team,

I need your suggestion to setup the JIRA projects for our program. We have the following scenario

- Multiple products (belonging to different BUs), but a common platform that supports these products and their features

- Multiple teams - Backend, web app, mobile app, firmware, etc

- Common features with span across the products e.g. notifications, schedulers, etc

- Product specific features and release timelines

- user stories that would require work to be done by multiple teams e.g. device notifications

Also what is the right agile methodology recommended - Scrum or Kanban


Any help in this regard is much appreciated.

Matthew Wong Atlassian Team May 06, 2019

Hi Mukesh,

In your case, it really depends on the size of your teams and products. Do you anticipate significant ticket volume for all of them that might require unique fields, workflows, component systems, etc.? If so, then break up your work.

If you don't think that the workstreams will be that heavy, then I'd suggest a single project with a custom field designating what stream of work an issue might fall into.

Finally, with regard to scrum or kanban, that's up to you and your team. I'd do some research on the differences and make the call yourself, since the short description that you've provided above isn't sufficient context to make a call. 

Hi Matthew,

Thanks for the quick response. 

Yes the team size is big (3 developers) and volume is going to be heavy.

Need suggestion on how to manage the user stories when they span across multiple teams e.g. firmware, backend, web, mobile. 

Hello! We've got a new game we're working on and we'd like to simultaneously track bugs/bug fixing and task management/game development. There's so much in JIRA I'm not exactly sure where to start.

I am thinking of having (within the same Project):

  • different boards for bugs vs tasks, 
  • screens for different issue types (e.g. bug, task, request, sub-task, etc)
  • Workflows for bug vs task
  • Some form of a dashboard depending on the user (e.g. a programmer sees programmer tasks only but can go to the backlog, or only sees tasks assigned to them)

Would you recommend a general set up for this? Anything else I should consider now ahead of time?

Matthew Wong Atlassian Team May 15, 2019

Hi @Sorcha_Millican-Nagle

This sounds like a solid plan and feasible within Jira largely out of the box. I'm reluctant to make a hard and fast recommendation regarding how you organize without knowing a lot more detail about your organization and instance. A couple of considerations.

Bugs, stories, and tasks are all distinct issue types that can have their own workflows and screens. That said, if you're just getting started in Jira, I'd recommend against getting to trigger happy with customizations of workflows, fields, or screens. A lot of this specificity should come as a natural progression of mandatory requirements. In other words, if your team can get away with sharing workflows, screens, etc. do that. As you scale and as your team matures in product, you'll grow to intuit exactly what customizations were necessary and what was just nice to have; unraveling a project or instance with a plethora of custom fields after the fact is a pain and the upfront complexity of a poorly instituted screen is a debt that will slow down adoption.

Whether you create two boards for bugs and the rest of your issues is largely up to you. Again, name of the game is to not complicate your work. Multiple boards means your users will need to navigate to two separate places to get a visual of progress. Do you really have that many issues to justify breaking boards apart? Are you a dogmatic scrum adherent who only wants to visualize stories on a board? These are decisions that you'll make on your own, but always consider simplicity v. complexity/customization.

Dashboarding is where I'd say you don't have to worry much about complexity v. simplicity. You can certainly create multiple shared dashboards, one for programmers, one for other kind of team members, and arrange them according to your primary organizing factor, whether that is issue types, distinct projects, etc.

Hope this helps.

Thanks, Matthew that's very helpful! 

We're a team of about 5-15, scaling as the project grows. We were originally going to have a separate task manager vs bug tracker so I think some separate boards might be warranted. Some of the people using task management will be swapping to bug fixing depending on the phase of the project.

Thanks for helping me consider the ideas. I'm going to keep experimenting!

Has any one used Jira projects in correspondence with defined systems of development? 

We have two key development teams, and about 10 key systems we do development in and also support.  Currently, we have Jira projects aligned to the business units (3) that used those 10 systems. 

We're exploring the trade-off of becoming more granular with our projects and having a primary project for each system.  We then could leverage the customization of unique issue types, workflows, screens, and roles for those systems. 

It certainly seem like it would enable standardization, but at the cost of additional management and support.  

I'm interested in getting feedback from anyone who has thought of this or something similar and may have clear pros and cons.  Thanks!

Matthew Wong Atlassian Team May 31, 2019

Hi @Jira Admin , 

Sorry for the late response. That makes sense to me. The trade off is always adoption and administrative overhead.

The more projects you have, the less likely your team is to adopt the processes. That said, if the desire for independent customizations is occurring organically, then perhaps it's not a bad idea.

It'd also depend on whether team members spend across all projects. In that case, I could easily see navigating from project to project being a pain and a hurdle to adoption. That said, if the need and desire for custom objects is coming from your users themselves, then this should outweigh the heaviness concerns.

Thanks for all the input. We are transitioning from Waterfall to Agile with two government projects. We would like to manage the projects and workflows in a similar manner. We think workflows should be determined by the issue type and different stati (plural of status) could all fit in the same column in the board (for example, coding, peer review, and testing could be "In Progress"). Do you have a good reason why all issues should travel through all the same stati?

@patsrick1943 - I'm not sure I understand the nature of your question in full.

That said, you are correct issue types will dictate your workflow and statuses (and vice versa, depending on how you look at it). Placing all statuses in a single column of In Progress would depend on your preference. I'd suggest your board shouldn't ever exceed more than 5-6 columns and each column should be absolutely necessary as vocalized by your team's preference and request. Having more columns than In Progress can be very helpful - just don't get too granular with it, as this can stunt adoption of your boards.

With regard to why all issues should travel through the same statuses, that's not entirely necessary. Board columns can map to multiple statuses across multiple workflows (this is obviously administratively a little heavier, but possible). That said, having fewer and broader statuses is preferable to having statuses that might only apply to a single team or project. So your intuition would be correct if you are thinking that across your two projects there should be more shared statuses than not; the administrative overhead of having a plethora of one-off statuses can get significant and unwieldy over time.

This is good info.  From the various responses on this thread, it's obvious there's a spectrum of possibilities for how to optimize and leverage project capabilities in Jira.  

In light of that, what would constitute the key criteria for creating new projects?  It seems at a high-level, it would be the need for:

  • Unique workflow for the same issue types
    • E.g. Bug on one project is handled differently that bug on another project
  • Unique permissions for same issue types
  • Unique issue types
  • Unique role functions
  • Unique required fields
  • Unique users/teams

I'm sure I'm missing something here, but is it accurate to say that if at least one of these conditions doesn't exist, then there's likely no need, at least from a capability standpoint, for a new distinct project?



Thanks for this overview!

This is new for us, we need to keep experimenting. Thanks for helping me consider the ideas

Thanks for the article Matthew!

Good day fellows.


Greenhorn to JIRA here, so if the question is stupid... 

Without the intention to advertise, just to explain better, i am coming from another team/project management software and there we had specific labels, under those labels i was able to group the team members, also under those labels i was able to create specific roles : like admin, developer, tester, audit, etc. Next step was, they were to create tasks, to organize, add new members, etc, but they saw ONLY the tasks with that label on it, from the group/label they were part of. Me as super-admin, i could supervise all the tasks in a single board and could track and realize what`s happening on project level.

The problem is, the new company is using JIRA so...

Would you please explain to me if it is possible to achieve this with JIRA and point me to a skeleton/key words to be able to search for more information on the subject?


Thank you in advance and great day ahead!

Matthew Wong Atlassian Team Sep 03, 2019

@Drako Dagato - First, get familiar with permissioning in Jira. It's a pain, but it'll get you what you need. Focus on both instance-level groups and project-level roles. That's foundational.

There are a few ways to approach this. If you don't want team members seeing other folks' stories at all, you can use issue level permissions by individual or group. This is a bit of a pain, however.

Alternatively, if all you care about is convenience in viewing relevant issues rather than privacy, Jira projects can have multiple boards and boards can be configured to show particular issues by using the board filter criteria. So you could use the components system, issue types, labels, etc. and have a board that just shows one particular kind of work. This would allow you to bypass the weight of user groups/roles, even though you should still get familiar with those, by giving each discreet group it's own unique board. You can also have a masterboard that allows for view of all the work. Check out the board settings documentation for more on this.

Thanks Matthew for your fast response,


I will focus on pointed topics and i already got some colleagues, willing to join a test project where i will try to approach the problem in the way you proposed.





Dear Matthew,

The organisation you mention 

3. Business Unit Closely related to organizing around teams, you might consider....

Is exactly what we need to do as we use Jira for every Department of the company so we have some admin non ending projets and engineerings one.

Besides that's the way we have organized our Drive.

In your post you do not explain how to do it, we have looked to do it alone but cannot find any satisfacdtory way (all options are equivalent to #tags which is not practical for many reasons)

Any hints ?


Log in or Sign up to comment

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you