What is Jira capacity planning?

Jira capacity planning compares the work committed to a sprint or project (demand) against the capacity the team actually has for that period - each person's available time, minus leave and holidays, adjusted for how much of what they plan they historically deliver. A plan is realistic when demand fits that real capacity, for the team and for each person.

Why isn't comparing points to average velocity enough?

Average velocity assumes everyone is present and averages the whole team into one number. It hides leave, holidays, part-allocation, and individual overload, and it ignores that a half-finished sprint only has half its capacity left. Real capacity planning checks remaining demand against remaining capacity, per person and per week.

Capacity planning

Jira Capacity Planning

See whether your Jira plan is realistically deliverable — demand against real capacity, per person and per sprint.

From the team behind Project Commander — the Jira app that tests whether a plan will actually deliver before you commit to the date.

Most teams "check capacity" by adding up a sprint's story points and comparing the total to their average velocity. If it's under, they ship the plan. That feels like capacity planning, but it isn't: average velocity is the wrong limit, and one team-level number hides the two things that actually sink sprints — individual overload and the days you've already spent. Real Jira capacity planning compares demand to the capacity a team genuinely has, for each person and each week, with time off and holidays already subtracted.

What Jira capacity planning actually means

Capacity planning answers one question: does the work you've committed fit the time the team really has? To answer it honestly you need three things the story-points-vs-velocity check skips:

Real capacity, not average speed. Start from each person's available time this sprint — minus leave, minus company holidays, adjusted for how much of their week is genuinely free. A practical refinement is effective capacity: raw capacity multiplied by how much of what the team plans it historically delivers (a standard 80% is a safer assumption than 100% until you have that history).
Per-person load, not a team total. A sprint can sit comfortably under the team's velocity while one engineer is loaded to 150% and another is at 40%. The total looks fine; the plan is not.
Remaining work against remaining capacity. Halfway through a sprint, its full capacity no longer applies — you've already spent the elapsed days. A 36-point sprint at its midpoint has roughly 18 points of capacity left, so 20 points of open work is overcommitted even though it looks "under" the full number.

Sprint capacity planning in Jira, done right

Sprint capacity planning in Jira is where the difference shows up first. For each sprint, compare its demand to its real capacity and give it a plain verdict: capacity comfortably above demand is deliverable; capacity that only just covers demand (say within 90–100%) is tight; capacity below demand is overcommitted. For an active sprint, judge remaining demand against remaining capacity — the days still ahead — so a stuffed sprint can't look deliverable just because the calendar hasn't run out yet.

Estimates can be in story points, hours, or days — the comparison works the same way in each, because it always reduces to "does the work that's left fit the capacity that's left."

Capacity planning per person — where sprints really break

Roll the same demand-versus-capacity check down to each individual. Useful bands: over ~115% of their capacity is overloaded, 90–115% is optimal, 60–90% is available, and under 60% is underloaded. This is where the hidden failures live — the sprint that's green overall but has one person who cannot possibly finish their share. Rebalancing that load, or moving work off the overloaded person, is often the entire fix.

Look week by week, not just per sprint

Overload rarely spreads evenly. A sprint can net out fine while one week inside it is badly over capacity because three deadlines and a holiday collide. Bucketing demand and capacity by week surfaces exactly which weeks break, so you can move work off the pinch point instead of discovering it when the work is due.

How Project Commander does Jira capacity planning

Project Commander runs exactly this check on your live Jira project — no spreadsheets, no manual roll-ups:

Every sprint carries a Deliverable / Tight / Overcommitted badge from a direct demand-versus-capacity comparison; active sprints are judged on remaining work against remaining capacity.
Team & Capacity shows each person's demand against their real capacity, with an Overloaded flag where it's exceeded — leave and holidays already subtracted.
When a sprint is overcommitted, Auto-Level rebalances the work across sprints in one click, so you can see a plan that actually fits.
The same capacity picture drives a delivery forecast — a projected finish date with the odds of hitting your target — so capacity problems show up as a date, not just a red bar.

Capacity planning across a whole program

Capacity planning in Jira isn't only a single-sprint problem. When several projects share the same people, the Projects portfolio rolls each project's capacity and demand into a program view, so you can see where the same team is committed twice over — the overload that no single board reveals.

The honest test of a plan is simple: the work that's left fits the capacity that's actually left — for the team and for each person, this week and next, with time off and holidays already subtracted. Check it that way and you stop shipping plans that were overcommitted from day one.

See the whole picture

Capacity planning is one part of it. On the main site you'll find everything Project Commander does — the delivery forecast, threatened dependencies, and every project's health in one place — along with the interactive demo and the free install.

Explore Project Commander → See all features →