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.

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.