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.
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.
This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.Read more
Can a new-to-agile team survive and thrive in a non-agile culture? If so, what advice would you give to those trying to be agile in a non-agile culture? What's the key(s) to success? Share your thoug...
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