JIRA Project Data Storage Architecture Question

Ashley Jean July 30, 2014

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
Answer accepted
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 30, 2014

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.

Ashley Jean July 31, 2014

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.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 31, 2014

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