My R&D team has been working on a major product for over a year and we're using JIRA for issue management.

Now got more minor, distinct products (not related to the previous one), and would like to separate the issues, versions, etc.. related to these products.

We thought of the following options:

  • Different JIRA Projects, one for each product
  • Single JIRA Project for all products + custom attribute (named product)

Which option will be more clear, easier to understand and to manage?

  • I edited your question to remove the best practice request and to be a little more objective in the criteria.
    – user22815
    Commented Dec 3, 2015 at 23:29

3 Answers 3


Jira tends to be project centric, not product centric. So as you have realized, products do not have a very rich model (in Jira). The is a standard field "component" which might express something similar to what you are looking for. The approach of mapping a Jira "project" to each of your product also works, but makes it a bit harder to have a consolidated view of your products.

In the end, it depends a lot on how you work.


I'd personally go this way (we are currently using this in my digital agency):

Have a distinct JIRA project for each project you are managing. This makes it easier to track issues and what's being done on each single worke you are doing.

Then have another JIRA project set up as a Kanban board to track the overall state of the projects.

Ours for example has the following columns:

  • Icebox
  • Estimate
  • Waiting for approval
  • Functional Requirements
  • Accounting
  • Design
  • Development
  • Rejected
  • Release
  • Done

Not necessarily every project goes through every of them in the given order. This allows even people not involved directly on each single project to get a quick picture of what's happening.

You should then have a custom field for projects in the Development column keeping track of the current sprint which is being developed right now.

I don't know if there are some better practises, but I can tell you from my experience that this is working pretty well for us!

  • You illustrate nicely that there is no best practice that fits all businesses. We have some needs in common, some that differ. The kanban board across projects sounds like a nice low cost way to keep enough information to be useful, but not so much as to slow you down. I put sprints in the product version numbers, which fits well in our process. But that's not for everyone.
    – joshp
    Commented Dec 3, 2015 at 23:28

Best practice for me may not be best practice for you, but I can relate my experience, which is that building several commercial products in a single Jira system as separate projects has been really painless for me.

These products are separate and don't all go to all customers but are also quite integrated and related and share dependencies.

Jira's project prefix has become really convenient for writing and reading git commit comments and for quickly finding and filtering issues.

Separating projects makes it simple if release cycles and version numbers differ.

Generally it makes use of Jira's capabilities, in my experience. Yet we can still see issues from all products/sub-products in the dashboard and search results.

For my work it has been a no-brainer, separate projects works and using a custom attribute would be a pain for us.

If I had new sub-products every few weeks, I would consider changing my story, just due to the admin setup and maintenance and wondering whether the proliferation of product-projects will become as confusing as accounting codes, and the UI too cluttered. So if it means quickly going from 1 to 20 projects, I'm going to stop and think it over. 5 or 6, no problem.

If the products / sub-products are always released and versioned together then having them in the same project would not hurt as much, and at some point you really are talking about components or modules. I prefer to do those with tags, because I don't want to pay someone to keep the terms up to date in a formal mutually exclusive component list. Component lists tend to need periodic revamping as teams and products changes. Customers don't pay for that. Git commits are more definitive anyway after a change is done. Before it's done what's important to me is which person is it assigned to.

Disclaimer: I really am not interested in fancy metrics, in aggregate graphs across products/sub-products and I don't need to track or bill time. So I never looked to see how those things are affected.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.