Structuring a JIRA project

Question

Warning: Wall of text below.

Internally, there is some discussion as to what a JIRA project is. I am under the belief that a JIRA project will be under an application or product suite. A few others believe it should be group based. So I am asking everyone I can and posting everywhere I can to get feedback and your own personal use.

At our company (Enterprise) we have hundreds of applications. We have dedicated teams that support those applications and we have floating teams that go from app to app. We also have hundreds of development projects a year. Does a group get its own JIRA project with the applications they support as a component, or should they work within the various JIRA application/product suite projects?

Example 1: This product suite is maintained by a single area (group) primarily with some outside help. They want a product suite.

Product Suite A - This is your JIRA project
- Component: App 1
- Component: App 2
- Version: Project 123
- Version: Project 456

The above is fine for this product suite because they perform all of their development and the version Project 123 can span all of their app components. On occasion a general group will have a project and will lead their own efforts to modify an app in the Product Suite A.

Example 2: General group floats between different applications for work. Typically driven by a project...but we will concentrate on how does a group, that doesn't own an app but works in many, maintain work?

General Group 1  - This is your JIRA project 
- Component: App 1 (from Product Suite A)
- Component: App 1 (from Product Suite B)
- Component: App 1 (from Product Suite C)
- Component: App 1 (from Product Suite D)
- Version: Project 123
- Version: Project 456

General Group 2  - This is your JIRA project

- Component: App 1 (from Product Suite A)
- Component: App 1 (from Product Suite B)
- Component: App 1 (from Product Suite C)
- Component: App 1 (from Product Suite D)
- Version: Proj 789
- Version: Proj 456

Wouldn't you want to track work (defects, support, backlog) for Product Suite A in the Product Suite A JIRA project?

Example 3: A single development project spans multiple applications and products. What's the best way to structure? Where do you create the base issue?

Product Suite A
- Component: App 1
- Component: App 2
- Version: Project 123
- Version: Project 456

Product Suite B
- Component: App 1
- Component: App 2
- Version: Project 123
- Version: Project 789

Product Suite C
- Component: App 1
- Component: App 2
- Version: Project 123
- Version: Project 456

Keeping in mind that we will be plugging GIT repositories to this for the code back-end, and using Zephyr for Test management so simplifying the repositories would be great but finding how to setup to support spanning groups and actual projects throws me off.

Am I thinking too much? Or am I trying to make the tool fit every situation? I just want to make sure that it is implemented in a way that we don't have to change down the line and I believe setting up JIRA projects to represent our Product or application fits versus setting it up so that JIRA projects are your actual groups.

MarkW · Answer

Thanks for the response Nica.  That is the problem we face. In our enterprise some groups are structured by that, a group. This group floats around to work on various applications and systems. So in their organizational structure they want to define their workflow, what information they require etc.  Then there are those that work directly against or for an application. In some cases this clash. A development project can have those dedicated to the application working on it as well as the floating group.

I think in the end it should be for the application/product as that allows cleaner integration with other tools and processes such as install approvals being applied to workflows. Also in the end, groups and teams all adhere to the applications release cycle, platform testing requirements, etc., etc.

Nica Huestegge1 · Answer

In both cases (structure by products / structure by teams) you will be able to filter and therefore report the information you need. I personally would always tend to choose the structure by products, mainly because of the versioning options that gives me - but this does depend on your company's structure. How do people communicate, sit together, report their status? If every perspective in your company is streamlined for the team, then structure for the team, by all means...

Norman Abramovitz · Answer

I usually tell people take your head out the weeds and look at the whole garden.   Look at what makes sense for your bosses instead of yourself.  Usually, the answer becomes clearer.

Developers/Testers needs a place to record information and want their tools to integrate cleanly.   An issue covers that.   The rest of the structure is for communication.  How you plan to communicate matters.  If the majority of the communication is by products, then structure by products.   You can still report by groups by setting up the proper groups, components, statuses, etc, etc. across products.