A new project is approved, and the deadline is ambitious. The scope is clear enough to begin planning, and the first question that comes up is simple. Who’s available for it?. That's why we’ll help you solve that situation by following this blog post. See how Jira capacity planning has evolved with the Jira Summer 2026 releases and how it compares to Capacity for Jira in real project scenarios.
In Jira, you may already know what needs to be done. You can see the backlog, epics, the tasks, and the people involved in current initiatives. However, Jira didn't have a unified view of people's occupation. The data previously mentioned also doesn’t informs if Laura has 40% availability to take new projects. On the other hand, there are cases, like Daniel's, who's already working on three different projects, given his specific set of skills required for those projects. And of course, he’s overworked... How to tackle these types of situations?
This is when the real pain of capacity planning comes to life: How to properly manage team capacity in Jira?
The Atlassian Jira Summer Release 2026 took an important step toward trying to solve this pain by introducing native individual capacity planning, which means teams now allocate people to high-level work, check if someone is overcommitted, and manage capacity without relying entirely on external spreadsheets. The functionality is available only for Jira Premium and Enterprise customers.
However, planning individual capacity and answering who’s actually the right available person for this project are not always the same problem. Here's precisely where Capacity for Jira takes a different approach.
Capacity planning is the process of understanding how much work people can realistically take on during a specific period of time, and based on that information, allowing the planner to decide where work should go.
In practice, that means connecting several pieces of information that are often separated:
When any piece of those questions/answers is missing, project planning starts to become guesswork.
For example, a project manager knows that six developers belong to a team, but that doesn’t mean they are available for a next project, as three of them might be committed somewhere else within the company, two might be almost 100% of their work allocation, and the one remaining lacks the required skill specialization for this new project…
Here, we can see the difference between having people and having the right available capacity at a glance for your team concerning new projects.
Atlassian’s new individual capacity planning functionality is an improvement for teams that previously maintained allocations in spreadsheets. It’s definitely an upgrade.
Jira now provides a capacity view with two main perspectives. The people’s view allows managers to look at individual allocations and remaining capacity, while the Work view starts from high-level work and shows how people have been allocated to it.
Contributions can be planned in percentages, hours, or days. Jira can also include non-project activities such as leave, training, and operational work when calculating availability.
Although some of the feedback provided during the Early Access Program (EAP) announcement available in the Atlassian Community Forum questioned whether the capacity should be restricted to individual Jira Spaces (or projects), the general available functionality spans the Jira site. Allocations can therefore be across spaces, helping teams identify conflicting commitments.
In short, this Jira native functionality helps answer this question for less complex organizations:
Nevertheless, other organizations need to solve more specific questions such as:
This is basically a resource planning question, not just an allocation question. Let’s see how to solve that:
The weekly view makes it possible to see who has room for more work, allowing planners, from the same view, to assign new work or inspect existing allocations.
This makes the difference for the PMO within the planning workflow. Instead of:
The workflow with Capacity for Jira becomes:
Atlassian describes its native capacity functionality as a way to plan against major work streams. Jira work items added to a native capacity plan currently need to be at the epic level or above, although Atlassian Projects and manually entered activities such as training or leave can also be included.
However, real project staffing often begins one level differently. For example, a manager needs to ask how much of someone’s capacity belongs to Project A vs Project B, inspect what’s consuming that time, and then plan specific Jira work accordingly.
Capacity for Jira, instead, lets planners work with a Jira work item or a space. This also allows for specifically filtering capacity by project, person, and skills,m giving the PMOs a resource-oriented view of work across Jira rather than requiring every staffing decision to begin with.
This is particularly useful for more complex organizations focused on managing big amount of projects, with very specific needs. Your capacity needs model can follow the project and the people doing the work, instead of forcing the project to follow the capacity model.
Availability alone doesn’t make somebody the right person to be allocated for a project; skills are quite relevant, especially if you need to allocate people with specific certifications for specific projects.
Imagine two consultants are both at 60% available for next month. One specializes in ITSM with advanced Jira Service Management experience, and the other focuses more on software delivery.
From a capacity perspective, both look identical, but from a staffing perspective they aren't.
This is why Capacity for Jira includes the possibility to plan work based on Skills. Teams can define relevant competencies, associate them with people, and use those skills as a filter when searching for capacity allocation. These skills can also include proficiency levels, helping planners to differentiate between simply having capability and having the level required by a particular project.
On the other hand, the new native Jira capacity planning feature provides people and work perspectives but not further. Making clear one of the clearest differences between these two approaches.
It’s important to define both of these concepts. Occupation tells how much of somebody’s capacity is already being consumed. Availability tells how much is left, and Capacity for Jira provides both in the same view. For a team, in a calendar view. Or individually, linked to the relevant tasks of interest.
The Planned view shows allocation percentages week by week, with visual indicators that make under-allocation, balanced workloads, and over-allocation easier to identify.
Capacity for Jira also compares the planned allocation with logged work, helping to connect the capacity plan with what’s actually happening once execution begins. This connection matters because this planning is only useful when it can be shown it works.
Looking at one person at a time can reveal an overload, but doing it across the group can reveal a trend and why it’s happening.
Perhaps one senior engineer is at 120% while the other three people have significant availability. Perhaps the problem cannot be solved simply by moving work because those three people don’t have the required skills, or perhaps an entire project is consuming more of the team’s capacity than originally expected.
Capacity for Jira is positioned around both individual and group availability, allowing work planners to inspect workloads across teams or a wider organization while using people, projects, and skills as resource planning dimensions, moving the conversation away from overloading and landing it on how to make it more fair and distributed for everyone.
Both solutions are designed to make capacity more visible inside Jira, with some overlap between them; nevertheless, the choice should come after the need that is necessary to cover.
Both solutions are designed to make capacity more visible inside Jira, with some overlap between them; nevertheless, the choice should come after the need that is necessary to cover.
Download this comparison table between these two >>
Jira’s native capacity planning covers the essentials for high-level, site-wide planning, including individual capacity, project filtering, and team visibility.
On the other hand, Capacity for Jira goes further for teams that need more operational detail, adding support for work below the epic level, skills-based resource search with proficiency levels, planned vs. logged work, and capacity based on Jira-configured working days.
In short, Jira’s native features are a strong starting point for strategic planning, while Capacity for Jira is better suited for downloadable, practical guidance focused on detailed resource management.
The arrival of individual capacity planning with the Jira Summer Releases 2026 confirms something many Jira users have known for years: understanding work is not enough. Teams also need to understand the people and capacity available to deliver.
Atlassian’s native capacity view is an important addition, almost exclusively for very high-level work allocation across major work streams, not available for a more specific view of work planning.
On the other hand, Capacity for Jira, available in the Atlassian Marketplace, addresses the next layer of the problem: finding available people, understanding current occupation, filtering people by project and skills, planning at the individual or team level, connection planned capacity more closely with the work happening in Jira.
Because the most useful capacity plan is not the one that simply shows everyone at 100%, but it’s the one that helps you decide who should work on what, when, and why, and ultimately, depends on the organization's needs.