JIRA Project Data Storage Architecture Question

My department is being reconfigured and as such we are looking to make changes to the way we have JIRA configured so that it works better for the teams using Agile Scrum methodologies. Unfortunately, given our size there is still some work that must cross teams to be completed.

We are trying to determine if it makes more sense to have One single shared project or one matching setup for each team. The ONE project option would require that all the teams would work out of their own backlogs which are defined with filters according to custom fields. I'm
My concern is that the growing number of tickets and need to have complex queries to set up all of the backlogs will cause lag in performance over time.

So, my main question is: In the JIRA database, are the Projects for a given instance on one shared table or does each have its own table?

Additionally, I'm not sure how much of an advantage we'd get for managing work that is split across multiple teams by having a single project if we're separating the tickets into different backlogs. So, any other 'best practices' info you could provide or point me to for guiding the team would be appreciated.

1 answer

1 accepted

0 votes
Accepted answer

If you have a lot of data, splitting things into projects makes a lot more sense in the long run. The decision to make is usually whether you map projects on to "products / purposes" or "teams", or both. It's usually product / purpose, especially if you have the Agile plugin (because Teams then use cross-project boards quite easily), but it can make sense to do it by team. When I say "products / purposes", an example might be one of my clients who use 1 project per web-site they build and maintain, and then have a project for internal support, another for infrastructure, another for operations incidents, another for problem management etc...

As for the internals, projects are not separated. Jiraissues holds the core of every issue in one table.

Thanks for the info Nic. We are moving from having teams by role to having Product groups. Unfortunately, with our current numbers of SME's we cannot set up out Product teams to be completely cross functional and self-contained. There will be dependencies between the teams.

After some more discussions, it seems like the main issue that we're trying to fix is the visibilty of where the work is with cross functional teams which I think perhaps the answer is more in getting on a common sprint cycle and better standardization with our release naming so that all users don't have to guess on the timing of these attributes when looking at the tickets related to a given activity. Having one shared 'Version' list to help keep the Product Owners/Scrum Masters in line with each other so far seems to be the best possible argument for keeping them together in one Master project and splitting the work into the backlogs using fields.

A lot of people have the same problem, but with Agile, there's another approach - multiple projects and boards for the teams. Might work for you.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Jan 29, 2019 in Jira Software

Transforming Jira Software projects for general project management purposes

...It's true that there are projects in Jira; but they are merely a way to cut off issues, to tell them apart from other sections of work and to apply rules that are specific to that team (the schemes)....

183 views 0 6
Read article

Atlassian User Groups

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!

Find my local user group

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

Groups near you