Individual capacity planning in Jira is having a moment. Atlassian’s Early Access thread for the feature filled up fast, the Jira 2026 Summer Release ships a native Capacity view, and LinkedIn’s Agile forums keep circling one question: how do you align sprint planning with your team’s actual capacity and skills when capacity changes every sprint? The short answer: stop planning against a team average and start planning against people.

Why the team average lies

Six names on the roster doesn’t mean six full people. One developer is 50% on another project. One is out Thursday and Friday. Your tech lead loses a day a week to architecture reviews. The intern can take bug tickets but not the payments epic. If you plan the sprint against “our velocity is 40 points,” all of that variance is invisible — until the sprint fails and the retrospective blames “estimation.”

Average-based planning fails precisely when planning matters most: the sprints where availability is unusual. A team at full strength can absorb a sloppy plan. A team at 60% capacity cannot. That’s why individual capacity planning keeps resurfacing in every practitioner discussion — it’s the difference between a commitment and a hope.

What Jira now gives you natively

Credit where due: Atlassian heard this. The Summer Release’s new Capacity view shows how the team’s time is allocated, who is overloaded, and where there’s room, with the backlog alongside so you can rebalance. Individual capacity planning was one of the most-requested features in the Early Access Program, and for a single team on a single board, the native view answers the first-order question: is anyone overbooked this sprint?

If you’re new to capacity-based planning, start with our capacity planning in Jira guide — the concepts below build on it.

Where per-person planning gets hard

The moment your situation is less tidy than one team, one board, full-time people, the questions get harder:

• Split allocation. A person on two projects has two capacities, and both plans need to see the same number — otherwise they’re committed at 130%.
• Stated capacity vs. demonstrated velocity. Hours available and points delivered are different currencies. A plan needs both: capacity to distribute the work, past velocity to sanity-check the total.
• Skills. Forty free hours of backend time doesn’t help a sprint full of frontend work. Capacity has a shape, not just a size.
• Time off and holidays. PTO, public holidays, and recurring ceremonies quietly remove 10–30% of a sprint. Planning that ignores them starts overcommitted.

Running sprint planning on individual capacity

The mechanics are simple to describe and easy to skip. Before the meeting, collect each person’s real availability for the sprint window — days off, split allocations, recurring commitments. Convert to a per-person number in whatever unit you estimate in (if you’re torn on that, see story points vs hours). In the meeting, fill the sprint person by person, not from the top of the backlog down: assignments follow availability and skills, and nobody exceeds their own line. Then compare the total against past velocity — if the plan says 48 and the team has never done more than 38, the plan is wrong, not the history.

This per-person pass is one step in a larger ceremony — our sprint planning guide covers the full sequence from goal to commitment.

When you outgrow the average — and the native view

Divim’s Sprint Planning, Capacity & Resource Planning for Jira was built for exactly the messy cases: per-person capacity with time off, split allocations, and skills, planned against past velocity — on one screen inside the Jira backlog, so planning and rebalancing happen where the work already lives. Teams that refine before they plan pair it with Backlog Refinement, Sprint & Capacity Planning for Jira, which brings story-quality checks and the same capacity awareness into refinement, so the sprint is planned from a backlog that’s actually ready.

Native individual capacity planning in Jira is a real step forward — adopt it. And when your roster includes part-timers, shared specialists, and people split across projects, plan them as people, not averages. That’s the version of sprint planning that survives contact with the calendar.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio