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.
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.
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.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
As part of the Bitbucket product team I'm always interested in better understanding what kind of impact the use of our tools have on the way you work. In a recent study we conducted of software devel...
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!
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