nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Multiple projects, multiple products, shared resources, and multiple boards?

Tatsiana Gomolko

Hi,

We’re trying to figure out the best way to organize planning and visibility across a growing number of products and teams in Jira. (Probably been answered quite a few times, but still.)

Atm, we have around 15ish products managed across different teams. Some products are independent, while others share functionality and have dependencies between them. Understandably, as things scale in our team, it’s getting harder to answer some basic questions, like: What is everyone working on across all products and teams? Or do we have enough capacity to take on new work? Or where are the dependencies? And is there a way to make delivery status updates less manual than they are now? I think you get the gist

Bottom line, we’d like to keep Jira as the source of truth for execution, but somehow make it a more convenient setup for working across projects, managing shared resources, tracking effort, and getting a bigger-picture view of delivery.

What setup would you recommend for a team operating at this scale?

Accepted answers

All comments

Mary from Planyway

Hi Tatsiana,

You can keep Jira as your source of truth and use Planyway to get a cross-project view. With Planyway, you can connect multiple Jira projects, view all work in one place using Timeline, Table, or Calendar views, track dependencies, monitor workload across teams, and get a high-level delivery overview without moving issues out of Jira.

jira dependencies.png

capacity for jira in planyway (6).png
Our Table view is useful when you need a structured, spreadsheet-like overview of work across multiple projects. It allows you to review Jira issues with important details such as status, assignee, dates, estimates, and other fields in a single view. You can quickly scan large amounts of work, filter what matters, and manage portfolio-level planning while keeping all updates synced back to Jira.

table view.png

Hope it helps

Gabriela - LeanZero

Jira's own answer to most of that list is Plans (it was called Advanced Roadmaps). One timeline across many projects, capacity per team, dependency lines between items, and it reads from your existing boards, projects or filters rather than holding a second copy of the data.

The catch is the tier. Plans only opens on Premium or Enterprise, so on Standard you're back to dashboards plus filter-based boards, and that's a much more manual setup than the one you're describing.

Which tier are you on? The answer splits hard there.

Joshua Brock _ Seibert Group_ GmbH

Greetings @Tatsiana Gomolko ...

At ~15 products with real dependencies between some of them, the four questions you listed (what's everyone working on, do we have capacity, where are the dependencies, can status updates be less manual) are really the same underlying problem: nobody has a single connected view across teams, so each question requires manually stitching data together.

Mary's and Gabriela's suggestions above (Planyway, or native Plans/Advanced Roadmaps if you're on Premium or Enterprise) are both reasonable starting points, and keeping Jira as your system of record while adding a planning layer on top, as you described, is the right instinct rather than exporting data elsewhere.

If, alongside "keep Jira as the source of truth," a meaningful number of these products and teams already work toward a shared planning cadence (or you're considering moving in that direction), it's also worth looking at Agile Hive, a SAFe delivery platform built natively in Jira.

It's aimed specifically at the coordination challenges you're describing:

Automated dependency management and visualization across teams, so "where are the dependencies" becomes a live view instead of a recurring meeting question
ART and team reports comparing planned load against available capacity across every team, addressing the capacity question directly
A Program Board gives a single view of what every team is delivering, cutting down the manual status-update work
A WSJF-prioritized backlog with the full SAFe hierarchy (Epics, Capabilities, Features, Enablers), so work across your 15 products shares one prioritization model instead of 15 separate ones

You can find more here at our website: https://agile-hive.com

Worth being upfront about the trade-off: Agile Hive is built around the SAFe/Program Increment model, so it brings some process structure. If your products operate largely independently, that structure may be more than you need. It's worth deciding whether a shared cadence across teams makes sense for you before adding a tool built around one.

If your products operate largely independently, that structure may be more than you need.

As with my response to your other question/posting, a note of disclosure that I work at Seibert Group GmbH, the team behind Agile Hive.

Best of luck, and hope this helps!

Joshua
Content Writer & US Representative
Agile Hive and Aura Apps (products of Seibert Group GmbH)

Tatsiana Gomolko

Hi Mary,

Thank you for the recommendation, seems like a nice fit. Will try it out.

Tatsiana Gomolko

Hi Gabriela,

Thank you for the breakdown. We're on Standard at the moment.

Gabriela - LeanZero

Standard covers three of your four. Worth knowing which one it doesn't.

For what everyone's working on, stop thinking per project and build a board off a saved filter instead: Boards, Create board, Board from an existing Saved Filter, with JQL spanning whatever slice of the 15 you want in one view. The same filter drives dashboard gadgets, so the cross-team read costs you nothing extra.

Dependencies you already have, in a plainer form than you'd like. The blocks and is blocked by link types carry the relationship and JQL can query them, so "everything currently blocked across these products" is a saved filter away. What Standard won't draw is the lines between them.

Status updates being manual is the one automation genuinely fixes. Standard gives you 1,700 rule runs a month, and a scheduled rule that assembles a delivery digest and posts it where people already look will barely dent that.

Capacity is the real gap and I'd rather say so plainly. There's no cross-team capacity view on Standard, no per-team number to plan against, nothing native that answers "can we take this on". That's the piece Plans buys and Plans is Premium. If the other three get you most of the way, start there, then see whether capacity is still the thing hurting in a month.

Melika-Everview

Good question! and the fact that you've framed it as "keep Jira as the source of truth but make the cross-project view convenient" is already the right instinct. At ~15 products the answer is usually a layering problem, not a restructuring one, so I'd start native before adding anything:
- Plans (Advanced Roadmaps), since you're on Enterprise. This is the native answer to "what is everyone working on across products" and "where are the dependencies" — you can pull multiple projects/boards into one plan, see dependencies on a timeline, and get a capacity view per team. For a lot of orgs this covers the planning-time version of your questions.
- Components or a shared team/label taxonomy, applied consistently, so "who's working on what" is filterable across projects rather than reconstructed by hand.
- Saved cross-project filters on shared dashboards for the recurring questions (in-progress by team, blocked work, unassigned capacity), so the status view is a live query instead of a manual roll-up.
Where native tends to strain at your scale is the two things you flagged last: live capacity math (Plans capacity is planning-oriented, less "do we have room right now given what's actually slipping") and making delivery status less manual — the roll-up across 15 products is usually where the manual effort creeps back in.

I'm on the team at Everview, and that strain point is exactly what we built for, so I'll be direct since you asked for setup recommendations. We layer on top of Jira (it stays your source of truth no rip-and-replace) and read your existing issues and links to give one cross-product execution view: what every team is working on, live capacity vs. committed work, dependencies across products, and delivery status that updates from Jira itself instead of manual updates — each with the evidence trail behind it so you can see why a status says what it does.
We're on the Atlassian Marketplace if it's useful to try against your own instance: Everview.Ai

That said I'd genuinely start with Plans first. If it answers the planning-time questions well enough, you may not need a layer on top; the case for one really shows up when the live "do we have capacity and what's slipping right now" view is the recurring pain. Happy to go deeper on either path.

Daria Spizheva_Reliex_

Hi! Great question — this is exactly the scale where a resource-planning layer on top of Jira starts to pay off. Keeping Jira as the source of truth is the right call, and ActivityTimeline works on top of your existing projects/boards without changing them. Here's a setup we'd recommend:

Cross-project visibility — connect all relevant Jira projects and view them on a single planning dashboard. You can filter by project, epic, sprint, or saved Jira filters, so "what is everyone working on across all products" becomes one screen.
Teams & shared resources — build teams in ActivityTimeline (manually, by skill/position, or imported from Jira groups). Since people can belong to multiple teams, shared resources are visible in every context, and you'll spot double-booking immediately.
Capacity planning — workload and availability indicators show each person's/team's load based on estimates and schedules, so you can quickly answer "do we have capacity for new work?" before committing.
Dependencies — enable "Track blocked issues" to have ActivityTimeline track Jira's blocks/blocked-by links and highlight scheduling conflicts between dependent tasks.
Less manual status reporting — built-in reports (Project/Issue Progress, Plan vs Actual, Utilization, Timesheets) can be bookmarked and shared with stakeholders, replacing manual delivery updates.

Team Capacity Chart 2026.png

A good starting point: connect a couple of projects, set up 2–3 teams, and try the Planner + Milestones panel for deadlines and releases.

Happy to help with the setup — feel free to book a demo and we'll walk through your specific structure.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

resource-management

portfolio-for-jira