Jira’s only native capacity feature — Plans, formerly Advanced Roadmaps, and it’s Premium-and-up — is scoped to one team and one board. An Atlassian team member confirmed on the Community forum that “each team’s capacity can be measured against only a single board,” and Atlassian’s own documentation describes that capacity as a number you set once per team, never per person. A separate request for a per-developer version has sat open since August 2025 with the same answer: “not available natively within Jira itself.” So “capacity planning across projects” and “capacity planning by individual” aren’t two different searches with two different answers — they’re the same gap. Native Jira gives you neither a cross-project view nor a per-person one; it gives you one team’s number, tied to one board.
What Jira’s capacity feature actually is
Plans (the current name for what most people still call Advanced Roadmaps) is where any native “capacity” concept lives in Jira at all, and it’s part of the Premium and Enterprise tiers, not Standard — per Atlassian’s own plan comparison. Inside a plan, you create a team, assign it an issue source (a board), and set an iteration length and a capacity — either a weekly time budget or a story-point target per sprint, according to Atlassian’s documentation on teams in Advanced Roadmaps. That capacity number describes the team as a whole for that sprint. It was never built to answer “how much is Sarah personally carrying,” and it doesn’t.
The single-board ceiling
The part that actually blocks “across projects” is structural, not a missing checkbox. Atlassian’s own page on capacity and velocity in Advanced Roadmaps states it plainly: “To manage a team’s capacity from your timeline, you must use a board with sprints or iterations as the issue source for your plan.” One board, one issue source, one capacity reading.
Someone ran into this directly and asked the Community forum whether a team’s capacity could be measured against several projects inside a single Premium plan — their org runs multiple Scrum projects with the same people spread across them. An Atlassian team member’s answer closed the door: “Each team’s capacity can be measured against only a single board as its ‘issue source’ for sprint-based (Scrum) teams” (Atlassian Community). If your team’s tickets live on three project boards, that’s three separate capacity numbers Jira will compute for you — never a combined one.
The other half: capacity is per-team, not per-person
Even inside one board, Jira’s capacity was never built to be read at the individual level. A separate thread, titled plainly “Capacity Planning - by Individual,” asked for exactly the metric a manager actually wants: how many points is each developer committing to, and completing, per sprint. The accepted answer is unambiguous: “this is not available natively within Jira itself.” The asker went further and noticed the direction of travel — Atlassian’s own tooling has “a switch from individual capacity to team capacity for reporting,” meaning the gap isn’t an oversight waiting on a roadmap item, it’s the opposite of where the product is headed.
That thread has pulled roughly 3,500 views since August 2025 without a native answer landing — a proxy for how many people hit this exact wall and went looking.
Why “capacity,” “workload,” and “tickets across projects” get conflated
Three different pages, three different jobs, and it’s worth being precise about which one you actually need:
- Your own tickets across projects — solved natively today. The Your Work page and a saved
assignee = currentUser()JQL filter already roll up everything assigned to you across every project. We cover that ground, including the one wall that doesn’t move (a second Atlassian site), in all my Jira tickets across projects. - A team dashboard — status, sprint burndown, velocity — partly solved. Filter-based gadgets aggregate counts across projects fine; sprint-shaped gadgets (Burndown, Health) stay locked to one board unless you’re on Jira’s Enterprise-only Atlassian Analytics tier. Full breakdown in a Jira dashboard across multiple projects.
- A team’s per-person load, across every project they’re in — this page. Not “my tickets,” not “the team’s sprint status” — the question is how much is each person carrying, everywhere, at once. That’s the one Jira’s own Plans feature explicitly can’t reach past one board for, and can’t break down by person even when it does.
Getting these three confused is why search results for “Jira capacity across projects” feel contradictory — some answers are correct about tickets, some about dashboards, and none of them are actually answering the capacity-by-person question.
What people build instead
Two routes show up consistently across these threads, neither of them a Jira setting:
- A cross-project JQL filter feeding a dashboard gadget or Quick Filter, summing story points grouped by assignee. Free, native, and it works — but it’s a filter you build and rebuild as projects and people change, and it produces a table, not a rollup with a capacity comparison behind it.
- A Marketplace app. Respondents in the by-individual thread named several purpose-built for exactly this: Capacity Planner (resource allocation across projects), Multi-team Metrics & Retrospective (custom JQL-driven metrics), and Time in Status (workload breakdowns by assignee). Each is a separate purchase, separate setup, and — like the JQL route — scoped to whatever you configure it to read.
| What you want | Native Jira | Real option |
|---|---|---|
| Team capacity on one board | Plans (Premium+) | Built in |
| Team capacity across several boards/projects | No — one board per team, confirmed by Atlassian | JQL rollup you build, or a Marketplace app |
| Capacity broken down per individual | No — capacity is a team-level number | Marketplace app, or a filter summing points by assignee |
| Your own tickets across projects | Yes | Built in — see all my Jira tickets across projects |
What OneView does instead
OneView signs in with your real Atlassian account and reads every connected Jira project — and every connected site — at once, no per-project filter to rebuild. Group the grid by Assignee (a live control on real data, not a demo toggle) and each person’s row totals their actual Jira fields — Story Points and original time estimate — summed across every project and every issue underneath it, the same estimate math Plans uses for a single board’s capacity, just not stopped at one board.
To be precise about where the honesty line sits: OneView doesn’t invent a person’s true capacity any more than Jira does — nothing in Jira or Microsoft Planner stores what someone’s actual weekly capacity is, so that has to come from you, not from a connector. What OneView removes is the piece none of the workarounds above solve in one place: the per-person, cross-project load — every open story point and estimated hour a person is carrying, rolled into one row, across as many projects and sites as their work actually spans. Start a free trial and group your own team by assignee to see it.
The same job, on the other tracker
If the team in question runs Microsoft Planner instead of Jira — or a mix of both — the identical gap, with Planner’s own ceiling, is covered in Microsoft Planner capacity and resource view: Planner has no native capacity view at all below a Premium People view that, like Jira’s Plans, stops at a single plan. Same shape, different tracker, same fix.