Skip to main content

Capacity Planning in Jira: How to Plan Against Real Availability, Not the 40-Hour Myth

Most capacity plans fail for the same quiet reason: they assume every person is available 40 hours a week, every week. They aren't. People are part-time, on holiday, in different time zones, split across three projects, or already booked. The moment your plan ignores that, it stops being a forecast and becomes a wish — and Jira, on its own, can't tell you the difference.

This guide explains what capacity planning actually requires, why native Jira can't do it, and how to plan against the real availability of your teams so you see an overload coming before it costs you a deadline.

What capacity planning actually requires​

Real capacity planning is a comparison between two things over time:

  • Supply — how much working time your people actually have, accounting for schedules, holidays, and time off.
  • Demand — how much work projects are asking those people to do.

To do that honestly you need three capabilities: a true model of availability, a way to capture demand as a structured number, and a view that puts supply, demand, and reality on one timeline.

Why native Jira can't do capacity planning​

Jira is excellent at tracking work — issues, status, worklogs. But it has no concept of capacity:

  • A Jira assignment is binary. It says a person is on an issue, not how much of their week that claims, or for which dates.
  • Jira assumes uniform availability. It has no native model for part-time schedules, holidays, time zones, or approved time off.
  • Even Jira Premium Plans reason about team capacity after the fact, not as an up-front negotiation between demand and supply.

So "are we overloaded?" becomes a gut-feel question. You need a layer that models real availability and compares it to demand.

How to do capacity planning over Jira​

Here's the practical workflow, using Resource Management for Jira — a Forge-native app that adds true capacity modelling and analytics directly inside Jira.

1. Model true capacity with real calendars​

Capacity starts with working time, not a flat assumption. The app uses a multi-calendar engine: each calendar defines regular working hours (which weekdays, which time slots — split shifts included) plus exception days (holidays, or special working days like a Saturday with custom hours). Calendars are assigned to resources with effective periods, so the effective calendar for a given date is what drives available capacity.

Because you can define an unlimited number of calendars, you can run one per location — different time zones, local holidays — and assign the right one to each person or period.

tip

Get the calendars right first. Every capacity number, overload warning, and timesheet baseline downstream is only as accurate as the working-time model underneath it.

2. Keep availability current with time off​

A calendar is the baseline; reality shifts. Through availability self-service, people request time off (unavailable) or working time on a non-working day (available exception), and managers approve it. Only approved periods affect capacity — so an approved holiday automatically reduces that person's available time in the plan instead of silently breaking it.

3. Capture demand as resource requests​

Demand has to be a number, not a Slack message. Projects raise resource requests — a role, an amount of time, over a date range — which the app turns into a structured demand signal. Requested and allocated hours are calculated from the same calendar rules, so demand and supply are measured in the same units.

4. Compare supply, demand, and reality on one timeline​

This is where capacity planning becomes real. The Analytics view puts four series on the same timeline:

  • Capacity — available working time from effective calendars and approved availability (the supply side).
  • Requested allocation — demand raised by projects through resource requests.
  • Filled allocation — the demand that's already been assigned to specific people.
  • Actuals — hours actually logged in Jira worklogs.

Switch between Team mode (can my teams absorb incoming demand?) and Project mode (is this project getting the capacity it asked for?), filter by project, team, member, or role, and move the timeline across day, week, month, or quarter for both retrospective and forward-looking analysis.

5. Catch overloads before they become slipped dates​

With those series side by side, the dangerous patterns become visible early:

  • sustained demand running above available capacity (a coming overload);
  • assignments lagging behind requested demand (a fulfillment gap);
  • actuals diverging from allocations (a plan drifting from reality).

The Results by series breakdown then takes you from an executive-level signal down to the exact people, roles, and requests behind it — so you can rebalance assignments or re-prioritize before the gap turns into a missed deadline.

A note on where your data lives​

Capacity planning means feeding your people, calendars, assignments, and worklogs into the tool — exactly the data a security review scrutinizes. Many resource tools pull all of that onto the vendor's own servers.

Resource Management for Jira runs on Atlassian Forge, so it operates inside Atlassian's infrastructure — your capacity and planning data stays within the Atlassian environment and isn't copied to an external server. For orgs with data-residency or vendor-risk requirements, "runs on Atlassian" turns a procurement objection into a non-issue.

FAQ​

Can Jira do capacity planning on its own? Not really. Jira tracks work and worklogs but has no model of availability — no part-time schedules, holidays, or time off, and no structured demand signal. An app like Resource Management for Jira adds the capacity layer on top of your existing Jira data.

How is "true capacity" calculated? From effective calendars (regular working hours plus exception days) and approved availability. That means part-time patterns, holidays, time zones, and approved time off are all reflected in real available time, instead of a flat 40-hour assumption.

What's the difference between capacity, allocation, and actuals? Capacity is the working time available; requested/filled allocation is the demand asked for and the part of it staffed; actuals are the hours actually logged in Jira worklogs. Comparing all of them on one timeline is what makes the plan honest.

Can I plan capacity across multiple teams and projects at once? Yes. Analytics lets you filter by projects, teams, members, and roles, and switch between Team and Project modes, so you can analyze a single project across teams or one team across many projects.

Do I need Jira Premium for this? No. The capacity model and analytics are added by the app and don't depend on Jira's Premium Plans feature.

Next step​

If you currently can't answer "is this team about to be overloaded?", the fastest fix is to model one team's real calendars, capture a few real requests, and watch the capacity-vs-demand lines on one timeline.

See how it works on the Resource Management for Jira product page, read the advanced analytics documentation, or book a walkthrough.