How do you keep Jira projects organized when multiple teams are working together?

Welcome  @Golden Glow Cleaners !

• For managing different teams, I use different boards. Developers are working mostly with Scrum, business teams use Kanban. For complexity, I consult the users that more than 5 statuses in a workflow is already creating a complex workflow. It's about the processes of these teams and how they operate. This is something that I cannot have in control.
• Shared scheme is used if different spaces are focused on getting things done, rather having their workflows different for each work item type. As admins, we should be more than yes men that are agreeing on every request. We should always ask questions.
• I am leaning towards not creating just another custom field. Rather the field that will be used and not just be there, which is also impacting the instance, making it slower.
• It's better to have a new Jira space, rather creating messy workflows. That way, everyone gets everything they want. Using a different scheme also needs to be considered, you don't want to change the default scheme.

Hi @Golden Glow Cleaners 

There isn't a single "best" Jira setup—it really depends on how your teams work. That said, a few practices have consistently worked well for growing organizations:

• Organize projects around ownership rather than departments. If multiple teams work toward the same product or outcome, a shared project often makes reporting and collaboration easier. Separate projects make sense when teams have distinct workflows, permissions, or release cycles.

• Keep custom fields to a minimum. Before creating a new field, ask whether a label, component, issue type, or existing field could achieve the same goal. Too many custom fields make screens harder to use and can impact Jira performance over time.

• Standardize workflows where possible. Most teams don't need completely different workflows. A few well-designed workflows that cover the majority of use cases are usually easier to maintain than dozens of highly customized ones.

• Use automation for repetitive work. Automate issue transitions, notifications, assignments, and routine updates so teams spend less time on administration and more time delivering work.

• Build dashboards for different audiences. Executives typically want high-level progress and risks, while delivery teams need sprint health, blockers, and workload. One dashboard rarely serves everyone.

One mistake I'd avoid is over-customizing Jira too early. Many organizations try to model every business process in Jira from day one, which often results in complex workflows, unnecessary custom fields, and difficult maintenance. It's usually better to start simple and evolve your configuration as real requirements emerge.

For planning across multiple teams, I'd also recommend Planyway for Jira. Jira is excellent for tracking work, but Planyway complements it with visual timelines, cross-project roadmaps, workload management, capacity planning, and dependency tracking. It gives managers a much clearer view of who is working on what, helps balance workloads across teams, and makes it easier to coordinate delivery without adding more complexity to your Jira configuration.

Welcome to the community, @Golden Glow Cleaners.

I'm Marlene from the team behind Quick Filters for Jira Dashboards.

Our app is particularly well suited for building cross-space and cross-project dashboards because it addresses some of the common challenges when combining data from multiple sources.

Some highlights:

• Dynamic filtering across gadgets: You can use a Quick Controller gadget to filter multiple dashboard gadgets at once—for example, by space/ project—making it easy to switch the dashboard context with a single selection.

• Smart field matching: When fields such as Components or Statuses exist in multiple spaces/ projects, our app matches them by name instead of ID. This means that fields with the same name are treated as the same value, rather than as separate ones, resulting in much more meaningful cross-space/ cross-project reporting.

If you're interested, I've also published an article on that topic: https://community.atlassian.com/forums/App-Central-articles/Building-cross-project-Jira-Dashboards-with-Quick-Filters-for/ba-p/2916318

Hi @Golden Glow Cleaners !

Here are a few practices that help keep things organized when multiple teams share one Jira instance.

• Use separate projects per team. This keeps workflows, permissions, and field configurations isolated. Teams can adjust their setup without affecting others. If you need cross-team visibility, shared dashboards and cross-project boards handle that well.
• Keep workflows lean. Start with a few core statuses and only add new ones when there's a clear need. The simpler the workflow, the easier it is for everyone to use it correctly.
• Agree on naming conventions. Consistent naming for projects, labels, and components makes filtering and reporting much easier. This is especially useful for JQL-based dashboards and automation rules.
• Standardize recurring processes. When several teams run similar processes, it helps to document them as reusable templates. Our solution Smart Templates for Jira lets you save a work item structure once and share it across projects. Every team starts from the same baseline, and processes remain consistent..
• Make progress visible at work item level. Status fields alone don't show how close something is to completion. Our solution Smart Checklist for Jira adds detailed checklists to your work items so everyone can see what's done and what's left. It also has a dashboard gadget that shows checklist completion across projects - useful for shared dashboards. You can also create checklist templates and add them to work items automatically based on conditions. This is helpful for planning multi-step tasks and maintaining consistency.

Here's an example of a release readiness checklist built with Smart Checklist:

This type of checklist is especially useful when multiple teams collaborate in the same Jira project / space. In this case, Dev, QA, and product teams can all track their part of the release process in one place. Everyone sees the full picture and knows exactly which steps are done and which are still pending.

Let me know if you have questions!

Hey! 👋

One thing that quietly saves the most pain here: decide the "shared vs per-team" line for each thing separately, not once for the whole setup.

• Workflows and boards — let teams differ. A dev Scrum board and a business Kanban board don't need the same statuses, and forcing one shared workflow is where the mess usually starts.

• Custom fields and schemes — keep these shared and few. This is the opposite call from workflows. Every field a team adds shows up for everyone, so a field that only one team fills turns into noise for the rest. Nikola and Davit already nailed this above — treat every new field as something the whole instance pays for.

• Spaces — separate by how work is delivered, not by org chart. If two teams ship one product together, a shared delivery space with per-team boards beats two disconnected projects you're forever reconciling.

Short version: standardize the plumbing (fields, schemes), let teams own their surface (boards, workflows). Curious what scale you're at — a handful of teams and a dozen teams pull this in pretty different directions.

Great points all around, especially Davit's framing of Demand vs. Supply and the capacity question — that's exactly the right shift.

To add one layer to Point 4: the challenge with dashboards for cross-team visibility isn't just that they're backward-looking, it's that by the time a risk or capacity problem shows up in a report, it's usually already too late to do anything about it without a scramble.

What's worked well for teams we've seen is having a live execution layer on top of Jira — not a dashboard that refreshes periodically, but something that shows you how priorities, capacity, and dependencies interact in real time, so you can catch a collision between two teams' workloads before it hits sprint planning.

the image below shows two teams in two rows so you can track their progress side by side and real-time.

That's the gap we built Everview for. It sits directly on top of Jira — your projects, epics, sprints, and custom fields stay exactly where they are — and gives you a live canvas where cross-team execution is visible at a glance: who's overloaded, what's blocking what, and where the plan is drifting from reality. An AI layer (Ask Ever) watches the same data and flags risks before they land in retro.

If the "we have visibility into what happened but not what's about to go wrong" problem resonates, worth a look: everview.ai

What Jira tells you: what's done. What Everview shows you: what's at risk before it becomes a problem

Hi @Golden Glow Cleaners  ,

Welcome to the community! You've touched on one of the most challenging parts of Jira administration: the "Scaling Wall." Most organizations start with a simple setup, but as soon as you have 3+ teams with different rhythms, Jira can quickly turn into a "custom field jungle" if you're not careful.

In my experience, the secret to keeping things organized isn't in the tools (boards/dashboards), but in how you separate Demand from Supply.

Here are a few strategies that have worked well for me:

1. Project Structure: Functional vs. Delivery
One common mistake is trying to make a single project do everything. I usually recommend a hybrid approach:
Delivery Projects: Focused on what* is being delivered (the "Demand"). These are the projects stakeholders care about.
Team/Functional Spaces: Where the actual work happens (the "Supply").
If you try to cram everything into one shared project, you'll end up with a workflow that is too complex for anyone to follow. If you create too many projects, you lose the big picture. The key is having a clear mapping between "The Project" and "The Team."

2. Fighting the "Custom Field Plague"
@Nikola Perisicis absolutely right about custom fields. They are the #1 killer of Jira performance and user sanity.
My rule of thumb: If you find yourself creating custom fields to track capacity, availability, or cost, stop. Jira is built for issue tracking, not for resource accounting. Trying to force "resource management" into custom fields usually leads to data that no one trusts. Keep your fields lean and use dedicated tools or specific reporting layers for the "heavy lifting" of planning.

3. Workflows: The "80/20" Rule
Don't build a workflow that covers every single edge case. Build a "Standard" workflow that covers 80% of the work, and handle the 20% of exceptions through communication or simple status overrides. If a team insists on a wildly different workflow, it's usually a sign that they belong in their own project/space, not in a shared one.

4. Visibility: From "What is done" to "Can we do it?"
Dashboards are great for seeing what's already happened (velocity, burn-down). But the real gap in most organizations is forward-looking visibility.
Instead of just tracking "In Progress," start asking: "Do we actually have the capacity to take this on next sprint without burning out the team?" Moving the conversation from "Task Status" to "Capacity" is where you truly stop the chaos.

The biggest mistake to avoid?
Saying "Yes" to every request for a new field or a new status. As an admin, your job is to be the "guardian of simplicity." Every new field is a tax on every user in the system.

Hope this helps you set a solid foundation! Looking forward to hearing how your setup evolves.