nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Best way to set up & manage a very large number of small projects? Individual JIRA/GH projects or Epics within one project?

Prem Mariappan

Hi,

Just wondering what the best way would be to organize, set up and manage a very large number of small projects in Jira/GH.

We are anticipating to have a large volume of projects, say 1-2 new projects each week. Each project would typically have less than 100 issues. Then after the initial active development (which would last 1-2 weeks) they'd be largely dormant, except for maybe < 5 or so maintenance issues per year. Logically, since each of these projects are for individual clients, they should be separate Jira/GH projects.

However, my concern is how would Jira/GH cope over the years as the number of projects increases? Say over 300+ projects? Can Jira/GH scale to cope with this?

What alternatives are there? Maybe having 1 large Jira/GH project, but Epics for individual client projects? What would be the disadvantages of this approach? Obviously the integration with Confluence which is used to manage requirements specifications etc, would become less effective.

Looking forward to hearing your thoughts.

Prem.

Accepted answers

Chris McFadden

One thing to keep in mind that there does not need to be a 1-1 correlation between a "Project" in JIRA and a "Project" as in Project Management. In JIRA, it is often better to have projects be aligned to products, libraries, or code bases that tend to have long lifecycles. Project Management Projects by definition have a discreet time duration with an end - but that end does not signfy the end of the products lifecycle.

You should pare down the number of Projects in JIRA based on that consideration. Traditional projects may be aligned by the use of Versions (i.e. releases) or possibly Epics or a combination of those and other things like components. You may also use a custom "Project" field to designate as well.

All comments

Renjith Pillai

Probably it won't. It will be a good idea to keep regular backups and JIRA database and delete of the projects. So that in case you need to get some old data, you can always restore the database to another instance and refer the data.

There is a JIRA archiver which is being planned, if interested in evaluating you may contact Roy, refer - https://jira.atlassian.com/browse/JRA-5843

The other alternative is to use a single project as you mentioned and handle teh customer as a component or a custom field drop down. Or even a label as this removes administrative overhead.

Prem Mariappan

Thanks for that info Renjith. What is the reason you think Jira/GH won't necessarily cope? Is it because there is a large overhead with each Jira project?

Renjith Pillai

While I do not have a direct mapping on the number of projects to JIRA performance, in general it affects as the project size increases. Also the amount of references to various schemes stored will start increasing with the number of projects.

Chris McFadden

Prem Mariappan

Thanks Chris. I think Epics might work well for the number of projects that we have. Certainly saves admin time, ie creating projects etc.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud

jira-cloud