Best practices for choosing single or multiple projects

I earlier asked a question on this topic, but I would like to extend my question.

My department has 6 Agile teams with nearly 100 users working on different projects. There are 6 scrum masters, each per team. We have a requirement that the VP should be able to view all teams' activities from a single report. In this case, will this be better to keep all teams under one JIRA project and then create separate scrumboard for each team within the same project? or will it be better to create separate projects, one for each team?

Please advise and provide reasoning behind your advice as I will need to convince my department why we're picking one option over the other. Thanks in advance.

2 answers

1 accepted

4 votes
Accepted answer

My experience has been that each project should represent a releasable product that is independently versioned.  So if all 6 teams use the same versions, and the products will be released as a bundle, one project is fine.  If all 6 teams use different versions, or release at different times, then you want multiple projects.

Part of the rationale there is that putting them together in one project, but independently versioned, means you have to disambiguate your versions by prefixing them with the product.  Say:



etc.  That makes it so you can't search for just "1.2", for the case where there may be a relevant intersection, and just generally confuses things.  As in, if you have:




If you want to find everything being released in "1.2", you can't search for:

projects in (PRODX, PRODY, PRODZ) and fixVersion="1.2"

You'd have to use:

project = ONEPROJECT and fixVersion in ("PRODX 1.2", "PRODY 1.2", "PRODZ 1.2")

(or something similar).

Putting them together also effectively forces you to embed metadata in the version, which can also impact other initiatives; for example, I wrote a 'sort' script for versions, and it has to break out the prefix and sort on that first, then the actual value (I have a support project that supports all products, so it has no choice except to cover all versions).

You definitely don't want to put them together, independently versioned and released, and not disambiguated.  Someone will make a mistake and forget to include a metadata-based disambiguator, like component, and possibly bulk update something not due for a release.  On the same note, since component is global to the project, that's another reason to separate them; if each product/team has multiple components, lumping them all together just becomes a mess.  The same goes for any custom fields that may be desirable to have product specific lists.

Thank you Jeremy for your answer!

0 votes
Joseph Pitt Community Champion Apr 21, 2016

If the teams will be working independently and you think you may want to restrict which issues people can see I'd go with different projects. You can create a report showing all the work so that isn't an issue.  Also, I've seldom seen multiple teams do things exactly the same and having different projects will allow some flexibility if it is needed.

Thank you Joe for answering my question!

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Nov 29, 2018 in Jira

How to set up an incident workflow from the VP of Engineering at Sentry

Hey Atlassian community, I help lead engineering at Sentry, an open-source error-tracking and monitoring tool that integrates with Jira. We started using Jira Software Cloud internally last year, a...

1,096 views 0 8
Read article

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