Best practices for choosing single or multiple projects

Shaikh Quader April 21, 2016

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

5 votes
Answer accepted
Jeremy Gaudet
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 21, 2016

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:

PRODX 1.2

PRODY 4.3

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:

PROXX 1.2

PRODY 4.3

PRODZ 1.2

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.

Shaikh Quader April 21, 2016

Thank you Jeremy for your answer!

0 votes
Joe Pitt
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 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.

Shaikh Quader April 21, 2016

Thank you Joe for answering my question!

Suggest an answer

Log in or Sign up to answer