Best practices for choosing single or multiple projects

Shaikh Quader

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.

Jeremy Gaudet

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.