Jira does have capacity planning built in now: on Premium and Enterprise, the Capacity view does individual capacity planning, one row per person against epics, while Plans still plans capacity per team. Atlassian announced it for every Premium and Enterprise site on 27 July 2026. Before that came an early-access run from December and a gradual rollout through July.
Wurm Peter asked the question I'd ask first, on 15 July, under Atlassian's announcement in the Community: "So the capacity tab is assuming that everyone works the same hours/week? Nobody is allowed to work part-time? Or am I missing something?" That post has 25,149 views and 74 comments as I write this, and he wasn't missing anything. On our test site a person who works 20 hours a week shows up as 50%, and there's no box anywhere to tell Jira she works part-time.
So this guide does two jobs. It walks you through setting up a capacity plan, step by step. We did it on our own Jira Premium site on 28 October 2026, with four people, three epics, a story, a Leave row and a CSV import. And it tells you up front who it's good for, and who still needs Plans or a resource-planning app. A lot of you are reading this with a renewal or a Premium upgrade on the table.
[!NOTE]
Prerequisites: Jira Cloud on the Premium or Enterprise plan ("This feature is available on Premium and Enterprise plans", from Atlassian's support doc). You need permission to change the space's navigation to add the tab, and some epics (or higher) with an Original estimate if you want a Resourcing percentage. Atlassian's FAQ lists team-managed, company-managed and business spaces. The CSV import uses Rovo and is marked BETA. We tested as a site admin in a company-managed space, with the dark theme, so that's what the screenshots show. We didn't test what a non-admin sees.
The short answer, if you're deciding about an app: the Capacity view covers week-by-week booking of full-time people against epics, inside Premium. Keep your app if you need part-time or custom hours per person, or story-level planning. The same goes for planned against logged time, holidays from a calendar, or hiding colleagues' percentages (we couldn't test that last one). The details, and the cost, are further down.
Does Jira have capacity planning? Capacity view vs Plans team capacity
Yes, two kinds, and they answer different questions. In the Capacity view you ask "how much of each person's week is spoken for, and by which big pieces of work?" Plans (Atlassian's advanced planning, the old Advanced Roadmaps) asks "how much can this team finish per sprint or per week, and does the scheduled work fit?"
Here's how they compared when we put the same four people in both:
| Capacity view | Plans team capacity | |
|---|---|---|
| Unit | One person, against a fixed 40-hour week | One team, a number you type per iteration |
| What you plan against | Epics or higher, Atlassian projects, and free-text rows like Leave | Estimated work items from the plan's boards, projects or filters |
| Estimates | Optional. Original estimate only feeds the Resourcing column | Required: story points or time estimates, and boards as sources for capacity |
| Part-timers | Can't be set. 20 hours shows as 50% | You can type any team total (we typed 140 for 40 + 40 + 20 + 40) |
| Velocity, actuals | None | Velocity from past sprints |
| Scope | Site-wide: Add work searches every space, and allocations aren't tied to one space in the API | The issue sources you add |
| Plans and Capacity sharing data | No. Atlassian: "Capacity data in plans : This is under consideration" (29 July) |
One thing we didn't check is whether every space's Capacity tab shows the same plan. We saw no plan picker and no way to create a second plan, and Atlassian's announcement says "The plan spans site level, so allocations are visible across spaces."
If you manage people across several projects and your question is "who's double-booked in November?", the Capacity view is the one. If you run a team on sprints and your question is "will this release fit?", Plans still does that and the Capacity view doesn't try to. Atlassian's product manager put it plainly in the Community thread in March. The MVP helps "plan individual capacity against big rocks of work over a quarter or more directly in Jira" and "does not aim to solve strategic or detailed workload scenarios today."
One naming trap if you're searching: the old Data Center page "Using the capacity view" belongs to Advanced Roadmaps on Data Center. It's a different feature from the Cloud Capacity view in this guide.
How to set up the Jira Capacity view (Premium and Enterprise)
On our site a brand-new company-managed space (we called it ZZCAP) had the Capacity tab already, right after Calendar. An existing space didn't, and it took the + at the end of the tabs to find it. Atlassian's admin note says it's "accessible to anyone with the appropriate space permissions", with no configuration required.
[[steps]]
- Open your space and look for the Capacity tab: it sits in the horizontal tabs, near Backlog and Calendar. If it's there, skip to step 3.
- Add the tab if it's missing: click the + at the end of the tabs. Under Views you should see Capacity, with the line "Plan contributions and track team capacity in your project." Click Add to navigation, and the tab appears.
- Open Capacity: the empty plan says "Balance individual capacity to keep work moving" and offers two buttons, Add people and Upload CSV. The URL ends in /capacity/people, so you're on the People view.
- Click Add people and pick your team: the field reads "Search people and teams". Tick each person and click Confirm. Each person becomes a row with an Add work line under it.
- Add work under each person: click Add work. Its search box says "Search epic and larger work types". It searches the whole site, so you'll see epics from other spaces too. Tick the epics and click Confirm.
- Add time off as its own row: type Leave (or Staff training, or anything else) in the same Add work box and pick "Create: Leave (non-project work, paid time off)". It's created straight away, no Confirm.
- Type the allocations into the weekly cells: click a cell, type a number, press Enter. Switch the unit menu (it starts on Percentage) to Hours or Days if you prefer. Each input's label tells you how much is left, for example "Enter allocation for Mihai Perdum to ZZCAP Mobile checkout redesign, 100 remaining".
- Check the person totals: switch back to Percentage. Each person's top row sums their week, and anything over 100% turns red.
You don't have to type cell by cell, by the way. Open the legend (the i button). It lists the keyboard shortcuts, and also "Drag blue dot to fill cells" for filling a row across weeks (we typed ours cell by cell).
The two Mihai Perdum rows are two different accounts on our test site, by the way. That second account carries the Leave week. A 40-hour Leave week shows as 100%, so it reads as fully booked.
Besides Weekly, the timescale menu offered Biweekly and Monthly on our site, even though Atlassian's roadmap comment from 28 September still lists "Monthly & Fortnightly Views [COMING SOON]".
Capacity by team member: people, epics and the fixed 40-hour week
Before you put real people into it, here are the limits we hit, one at a time.
Every person is a 40-hour FTE, and you can't change it
Atlassian's doc says it straight: "Capacity plans currently use a fixed 40-hour work week. Custom time-tracking or working-day settings are not yet reflected in these plans." The legend in the product opens with "FTE = 40h per week". And the Resourcing tooltip in the Work view goes a bit further. It says changes to Jira's time tracking settings "will not reflect in the capacity view which is fixed at 8 hours per day, 5 days per week."
We looked for a way around it. A person's More actions menu has exactly one item, Remove person. There's no working hours field in View settings, in the legend or in the header menus either. So we gave Gabriela (me, in the test) 20 hours a week on one epic, and the grid shows 50%. A full-timer with half a week free would show the same. If your team has part-timers, four-day weeks or people split with another department, the percentages are off for them and you'll need to keep that in your head.
It's on Atlassian's list, sort of. Their own RFC from November 2025 planned allocations "anchored to each individual's configurable overall capacity (default 40 hours/week, editable)", under "Later". In July the product manager wrote: "We're considering flexibility here for the future though I'm not able to share a timeline just yet." As of 28 October it hasn't shipped.
Epics or higher, says the doc (a story got in anyway)
The doc says you can add work items "as long as they are epic-level or higher in your work type hierarchy". In the product the Add work box agrees. Searching our story's summary, "checkout button", returned "No results found".
Then we typed the story's key, ZZCAP-4, and it came up with a checkbox. We added it and gave it 4 hours, and the Capacity API returned that 4-hour allocation afterwards. So on our site the search enforced the rule, and an exact key got past it. I'd treat this as something we saw once, on 28 October, that Atlassian may close. Their roadmap comment lists "Level 0 work items: Expanding capacity planning beyond Epics down to standard story or task level work items" as what they're working on now, so maybe it's the start of that.
Over 100% is a warning, never a block
Atlassian's FAQ: "The capacity bar turns red to flag the overallocation, but there's no hard cap." We pushed one person to 54 hours in the week of 26 October and the cell said 135% in red. Jira accepted it without a dialog. Hovering the red bar didn't show any extra detail for us.
The Work view starts empty
Next to People there's a Work toggle. It switches to a view with one row per epic and the people under it. You'd expect it to fill itself from what's in the People view. It didn't: it said "Start adding work" until we added the epics there too, and then their existing allocations appeared. Atlassian's roadmap has "Cross-View Auto-Population [COMING SOON]", so this one is known.
The Work view also has a Resourcing column, fed by the Original estimate. We set a 200-hour estimate on one epic and allocated 4 weeks of 50 hours to it, and Resourcing showed 100%. An epic with no estimate showed 4 with a person icon instead of a percentage. Only one full-timer was on it, for four weeks, so it looks like FTE-weeks (we didn't confirm the unit). We saw no field change on the work items themselves, so the allocations don't seem to write anything back to Jira fields.
No actuals, and no velocity
Nothing in the view reads logged work. Sascha Weber asked for exactly that in the Community thread ("where did he spend his Time already, that's currently an impossible view without marketplace apps"), and as of our test there's still no time-spent column. So what you get is a plan of intent. If you need planned against actual per person, that's still a report you build elsewhere.
Import a capacity plan from CSV with Rovo
If you already keep this in a spreadsheet, the Upload CSV button (with the Rovo icon) is the fast way in. On an empty plan it's on the start screen, otherwise it's under More actions. The doc says to stay on the People view, and that "Rovo will analyze the data and present suggestions. You can accept or dismiss each suggestion individually, or select Accept all".
Our first file failed. It had a row for every person in every week, with the header "Person,Work,Week starting,Allocation %", and the only answer was a toast saying "We couldn't complete your request".
The second file worked. It had one row per person and work item and one column per week:
Name,Work item,Week of 23 Nov 2026,Week of 30 Nov 2026
Gabriela Perdum,ZZCAP-2,25%,25%
LeanZero SRL,ZZCAP-2,50%,50%
Gabriela Perdum,Staff training,25%,25%
Within about 10 seconds the grid previewed the suggestions and the toast said "Suggestions added. Some items missing." Error details had one line:
So the CSV can't create non-project rows like Staff training, and the error says the work must belong to "this space", while the Add work box searches the whole site. We clicked Accept all and the two good rows appeared in the weeks of 23 and 30 November (you can see them as the 25% and 50% cells in the grid above). Keep CSV rows to epics, and add Leave or training rows by hand. We didn't test whether the CSV matches a row that already exists.
Rovo ran three times in our test. We saw no credit counter in the product and didn't pull the usage export, so we don't know what the imports cost. If you're watching Rovo credits, our Think Deeper credits test shows how much the bill can swing by feature, and it's worth checking your own usage page after a big import.
There's also a Rovo skill: open Rovo Chat, type /manage-capacity-plan, and ask in plain words ("Add me to this plan and assign me to Marketing Project for 100% over July" is Atlassian's example). We didn't run it.
Read your capacity plan through the REST API
Atlassian has shipped a public Capacity Planning REST API (its roadmap comment of 28 September marks it "[SHIPPED]"). It's handy for checking what's stored, and it's how we found the cleanup trap below. It worked with basic auth (your email and an API token) on our site. First get your cloud ID:
curl -s https://wolfaenpak.atlassian.net/_edge/tenant_info
{"cloudId":"049de078-bffa-42d1-bbfb-ad8db9860adb"}
Then list the non-project rows, like Leave. Swap in your own site and credentials:
CLOUD=049de078-bffa-42d1-bbfb-ad8db9860adb
curl -s -u "$JIRA_ADMIN_EMAIL:$JIRA_API_TOKEN" -H 'Accept: application/json' \
"https://api.atlassian.com/ex/capacity-planning/$CLOUD/v1/non-project-work-items"
{"nonProjectWorkItems":[{"id":"055ae1fa-bf87-4e8b-9223-35fa5797ad8a","ari":"ari:cloud:capacity-planning::custom-contribution-target/activation/d0cd8ee8-0829-4199-930e-a54b6fedf70e/055ae1fa-bf87-4e8b-9223-35fa5797ad8a","name":"Leave"}],"pageInfo":{"hasNextPage":false,"hasPreviousPage":false,"startCursor":"TGVhdmUAMDU1YWUxZmEtYmY4Ny00ZThiLTkyMjMtMzVmYTU3OTdhZDhh","endCursor":"TGVhdmUAMDU1YWUxZmEtYmY4Ny00ZThiLTkyMjMtMzVmYTU3OTdhZDhh"}}
That Leave row is the one from our test, still there after we cleaned up. The API has no DELETE for these rows. The API's authorization page says it "enforces the same permission checks as the Capacity Planning UI", so a user can't read through it what they couldn't see in the product.
It also has endpoints for the person-to-work links (contributor-work associations) and the weekly numbers (contributions). We used them to confirm the 4-hour story allocation, and to clean up.
Remove person hides the row, and the hours stay
This one caught us. When we finished, we removed all four people with More actions > Remove person. There's no confirmation, and the plan went back to its empty screen. But the API still returned their links to work and their weekly hours, for example 30 hours a week for one person on the checkout epic. Remove person hides the row. The allocation data stays.
We cleared it with the API (POST to contributions:clear for the 8 person and work pairs, then contributor-work-associations:delete), and re-reading gave 0 links and 0.0 hours. If you're cleaning up a test plan, or someone leaves and you don't want their old allocations lingering, keep this in mind.
Who can see whose allocation: no setting we could find, and untested
Atlassian's line is that the tab is "accessible to anyone with the appropriate space permissions". We didn't find a capacity-specific permission or a "who can see this" setting anywhere in the view. Wurm Peter raised the same worry in the thread. "In most companies, team members aren't allowed to know whether colleagues are assigned 80%, 100%, or 110%." We couldn't test it from a non-admin's seat, because our only non-admin test account has no Jira access and giving it a seat costs a Premium licence. So check it on your own site, with a regular user, before you put real names and percentages in.
Jira team capacity planning in Plans: what the Capacity view does not replace
Plans measures a team, per iteration. From Atlassian's capacity and velocity doc: "Capacity in your plan refers to the number of story points or hours your team can complete in one iteration." For Kanban teams it's hours per week, and capacity information only shows when the plan's work comes from boards.
We built a plan on the same board and added a plan-only Kanban team with the same four people. Then we set its capacity to 140 weekly hours (40 + 40 + 20 + 40). Plans took the number. Its REST record has one capacity field and a list of members, with nothing per member.
So the funny situation today is that Plans lets you type a part-timer's hours into the team total and the Capacity view doesn't let you type them for the person. And they don't talk to each other. If you use both, you keep two sets of numbers.
Does the Capacity view replace a Jira resource planning plugin?
For some teams, yes. If you were paying for an app mainly to see who's booked on which initiative, week by week, and your people all work full weeks, the Capacity view covers that inside Premium. Atlassian even calls it "big rocks" planning.
It doesn't replace one yet if you need any of these. Part-time or custom working hours per person, planning at story or task level (officially), planned against logged time, holidays from a calendar instead of typed Leave rows, or a permission that hides colleagues' percentages. The Community thread keeps asking for them, and two old tracker tickets are still open: JRACLOUD-90363 (capacity per team member, 227 votes, 119 watchers, Gathering Interest) and JRACLOUD-88144 (scheduling plans on user capacity, 188 votes). Neither was closed by the launch. You also don't get dependencies or a critical path in the Capacity view. That's Plans' timeline, or an app (our own LeanZero Management Gantt tutorial is one example of where that lives).
And the cost. Atlassian's pricing page lists Premium at $15.56 and Standard at $8.48 per user per month, at its 300-user reference price. That's $7.08 more per user, about $2,124 a month for 300 people. I wouldn't pay $7.08 a user for the Capacity view alone. If you'd use Plans too, the sum looks different, and our usage-based pricing budget for 50 to 500 seats has the full numbers by seat band. If you're already on Premium, it's included. Try it for a week before you renew an app.
If it didn't work
There's no Capacity tab. Check the + at the end of the space's tabs, under Views. If Capacity isn't listed there, check your plan: it's Premium and Enterprise only. In the summer release thread, an Atlassian PM told a user who couldn't see it that "a space admin will need to add it from the ‘ +' in your top navigation."
Add people says "No results found" for someone. On our site an active user wasn't offered. We think (unverified) it's because he has no Jira product access. Check the person's Jira access first.
Add work can't find your story or task. That's the epic-or-higher rule. Use the epic. (An exact key got a story in for us, but don't build your process on it.)
The CSV says "We couldn't complete your request". Our row-per-week file failed with this. The file that worked differed in more than layout. It had Name and Work item headers and the bare key (ZZCAP-2, without the summary). Its columns were headed "Week of 23 Nov 2026", with a % sign on each value. We changed all of that at once, so copy the example above exactly.
The CSV says "wasn't found. Ensure it is an epic or above work item and belongs to this space." Our case was a non-project row, which you add by hand. The message also says the item must belong to this space.
Removed people still show up in the API. Remove person only hides them. Clear the contributions and associations through the API.
What you have now
[[takeaways]]
- A capacity plan in your space, with people on their epics (plus Leave rows) week by week, and red bars where someone is past 100%.
- The limits that matter before you rely on it: everyone is a 40-hour FTE, epics or higher (officially), no actuals, the Work view filling only from what you add there, and Remove person keeping the hours.
- A CSV format that Rovo imported (one column per week), and the one that failed.
- A clear line between this and Plans: per person against big work here, per team against estimated work there, and no data shared between them today.
Are you using the Capacity view with part-timers, and how are you working around the 40 hours? Or did you try it and go back to your app? Tell me in the comments, or mail gabriela at leanzero.net. I'm collecting the workarounds :)
Originally published on leanzero.net. More Atlassian, Forge and local-AI write-ups at leanzero.net/blog, and if you're planning a migration or a Forge app, that's what we do: leanzero.net/services.
Top comments (0)