How do teams organize Jira work across multiple product and packaging projects?

Question

I’m interested in how teams organize Jira when they manage several types of projects at the same time.

For example, a company such as Silver Edge Packaging may have work across product development, website updates, marketing, design, content, and customer related requests. These activities can involve different teams but still depend on each other.

I’m curious how experienced Jira users handle this kind of structure.

Do you normally:

* Keep each department in a separate Jira project?
* Use components or labels to separate different work types?
* Connect related issues across projects?
* Use epics for larger product or marketing initiatives?
* Create a centralized project for cross-team requests?

I’d especially like to hear how teams avoid duplicated issues while still giving each department enough visibility into the work that affects them.

What Jira structure has worked well for organizations with several teams and different types of ongoing work?

otperpms · Answer

I’d avoid putting every type of work into one large board. Separating the main workstreams usually makes ownership and priorities much easier to see.

For example, product, website, marketing and customer work can have their own boards or views, while keeping a consistent workflow and naming structure across them.

The important part is being able to quickly answer: who owns this, what stage is it in, and what needs attention next?

I’ve seen simpler Kanban tools like Otper take this approach as well, especially for teams that don’t need a very complex setup.

Matthew Sinclair · Answer

To add to Mia:

This is why I subtly said "very very light".

Our new Governance board we built to help clean the mess our org made made a disturbing discovery when I explained how the labeling system works.

The labels you store in the "Global pool" of your Instance cannot be removed by an Administrator - you have to stop using the label for it to be removed all together. (At least for now - Atlassian is always adding new toys these days)

Think of it as a hashtag system - you have to stop using it to get rid of it.

I bring this up because we encounter mispellings - duplicates - etc.

Components are favored as such as space admins are the only ones who can create/maintain/remove. The downside however is Components are limited to the space of which they live in and are not shared.

Custom Fields at least are moderately easier to deal with - but come with their own "baggage."

Whatever you use - do so in caution and with consistent governance/practice.

One more thing - Do not use Team Managed spaces. Avoid them like the plague.

Team Managed spaces are great for tiny teams. But the moment you scale up and have to deal with multiple groups - you will have headaches you can't even begin to imagine as an administrator. They do not get along with each other at all really. Not to mention become quite troublesome for Org Admins when lifting/shifting.

This is why I loathe Jira Product Discovery - great product for users - but horrid for Admins to manage. Company Managed spaces can help enforce some order in the chaos and allow Admins to maintain consistency - which allow for easier collaboration between spaces - such as joint Kanban Boards. Even JSM/CSM can be tied in (observing the obvious workflow challenges of course).

Just my two cents and a quarter. :)

Mia Tamm _Simpleasyty_ · Answer

One rule I'd add: use spaces/projects for ownership, and components/labels for classification.

Once labels start deciding who owns the work, which workflow applies or where people are supposed to look for it, the Jira structure gets difficult to understand very quickly. One work item, one owner — then use links, boards and higher-level initiatives to show the cross-team picture.