I work for a company with a Single web portal with multiple "modules" within portal.
Currently, I am trying to keep everything in a single JIRA project, and using "components" as the modules.
We can use the same workflow / statuses / etc for all issues, so I figured it made sense to use one project for everything.
However, the backlog for this single project is getting pretty big and unwieldy.
I was looking for advice on when to break a project out to multiple projects. Is it when workflows deviate, permissions, etc.?
Backlogs are managed with multiple quick filters.
Is it when workflows deviate, permissions, etc.?
Projects should deviate when issues created do not match the project context. For example, you don't create a leave application in a software development project. Remember that schemes (and such) can be used for multiple project.
Your situation certainly sounds like a good candidate for multiple projects. Timothy Chin mentioned that workflows, permissions, etc. are packaged in schemes that can be applied across multiple projects. You can certainly break your modules out to different projects and just reuse the same workflow scheme, permission scheme, notification scheme, etc for all of the projects without creating much additional work. If you find that workflows, permissions etc do begin to deviate, you can always copy the base schemes and customize them accordingly, too.
Another thing to consider is how you will be searching JIRA for these issues. Do you need to set up gadgets or filters that show issues across multiple modules? If so, then your queries may have to include project in () instead of component in (). Not a whole lot different either way, but maybe .
One other thought: how many levels of organization do you want? Would the components field be useful when dealing with a single module? If so, separate projects might be better. If not, then splitting them into separate projects might be a little bit of unnecessary overhead - unless reducing the backlog size is worth it. It wouldn't be much additional overhead, though, as noted earlier.
Additionally, breaking out to separate projects means a difference in the issue keys, which might make finding items in a specific module easier. Again, not a big difference, but some.
e.g. Quick Search for My Open XYZ (returns all open issues assigned to the current user in project XYZ) is a little easier than My Open ABC c:XYZ (returns all open issues assigned to the current user in project ABC that have component XYZ).
I agree with what @Randall and @Timothy mentioned above; allow me to eloaborate on what I'm planning to come up with for our current JIRA instance.
That's the above setup that I come up with for my current company's JIRA. The way it is done above is quite generic which allows feasibility and easier management for future enhancements. Plus, the changes you made for a category's scheme would be shared across all the project under that category.
Of course, you can make schemes which are specific to a project's name; but remember the performance overhead and the management of the projects would be a tad tedious.
Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...
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
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot