Blog · 6 October 2026

Jira capacity planning: how much the team can take on

Capacity planning in Jira means answering one question before each sprint or month: how much work can this team actually finish? Jira gives you three places to answer it. The Velocity chart shows what the team completed in past sprints, the sprint container in the backlog adds up the estimates you drag into it, and plans (the advanced planning feature) let you set capacity per team and compare it with the work scheduled. Whichever you use, the number is only as good as the list of work it is compared against. The usual hole in that list is routine work that returns on a rhythm and has no ticket until someone remembers it. This guide walks the three tools, then fixes that hole.

A note on words. Jira Cloud has been renaming things: projects are now spaces and issues are now work items in much of the interface. This article uses both, since most teams still say "issue".

What "capacity" means in Jira #

Jira has no single capacity field. Capacity is a comparison between two numbers you maintain yourself:

• Supply: how much effort the team has in the period, after holidays, leave and meetings.
• Demand: the estimated effort of the work items you intend to do.

Planning goes wrong when either number is guessed. Supply is guessed when nobody subtracts the days people are away. Demand is guessed when work is missing from the backlog, which is the part Jira cannot help with on its own.

As of October 2026, Atlassian's pricing page lists Advanced planning (Plans) and a Capacity management row in its plan comparison, and describes the Premium plan as the one for aligning multiple teams with cross-team planning and dependency management. Check the comparison table for your own plan before you build a process on it.

Step 1: find the supply #

Start from what the team has finished, not what it hoped to finish.

1. Open the board, then Reports, then Velocity chart.
2. Read the completed bars for the last three to five sprints and take a typical figure.
3. Adjust for the coming sprint: fewer people, a public holiday, a release week.

The committed bars show ambition and the completed bars show capacity. Planning to the committed number is the most common mistake, and a sprint that is repeatedly overfilled teaches the team to ignore its own plan.

For a monthly or quarterly view, do the same arithmetic in days: working days in the period, times people, minus leave, minus the fixed overhead of meetings. If your team has no estimates at all, days is the honest unit.

Step 2: measure the demand #

Demand is the estimate of everything planned for the period.

1. Make sure every backlog item you might pull has an estimate, in story points or time.
2. Drag items into the sprint from the top of the backlog.
3. Watch the running total in the sprint header against the supply from step 1.
4. Stop when the total reaches the supply, and leave a small buffer for the unplanned.

If you run Kanban, there is no sprint container. Use a work in progress limit on each column instead, and treat the limit as the capacity: the column is flagged when the team takes on more than it said it could hold.

Step 3: find the work that is not in the demand #

Here is the part that makes capacity numbers lie. Every team has routine work that returns on a rhythm:

• the dependency update every two weeks,
• the monthly access review,
• the release checklist,
• the on-call handover,
• the report that goes to the same people each Friday.

It takes real hours. It is rarely in the backlog when planning happens, because nobody creates a ticket for something that has not happened yet. So two things follow. If someone remembers mid-sprint and adds it, the sprint grows after it started and the burndown bends. If nobody remembers, the work is done without a ticket, and the velocity chart under-reports what the team does while the team feels permanently behind.

Either way, the supply you computed in step 1 was too generous, because part of it was already spoken for. The fix is to make the routine work visible as tickets, with estimates, before the planning meeting.

Three ways to get routine work into the plan #

By hand is fine for two or three recurring jobs and a scrum master who never takes leave. Put "create this sprint's recurring tickets" on the planning agenda.

Jira Automation can do it with a Scheduled trigger and a Create work item action. The details, including what each run counts against, are in Jira Automation pricing and Jira Cloud automation limits. Saying "every second Monday" in a scheduled rule means a cron expression, which has its own traps.

A scheduling app keeps the schedule and the ticket template together, per space. Recurring Work Items for Jira is built for this job. A project admin writes the rule once, and the work item appears in that space's backlog on the day it is due, with its description, assignee, labels, due date and subtasks filled in. Custom fields can be set in the template too, so an estimate field arrives already filled. Titles and dates can carry tokens, so the ticket reads "Dependency update, sprint of 5 Oct" instead of repeating last time's summary.

Step 4: make the routine load measurable #

Once the tickets exist, you can count them, and counting is the whole point.

• Give each recurring ticket an estimate in its template. A dependency update that always takes about three points should arrive with three points, so the sprint total is right without discussion.
• Filter on the label. Every issue Recurring Work Items creates carries a label of the form recurring-<rule id>, so a saved filter on that label shows how much of each sprint the routine work took. If it is a third, the supply for new features is a third lower than the velocity chart suggested.
• Create the tickets a day or two before planning. They sit in the backlog while the team ranks and estimates, and they count in capacity like any other item. The longer treatment of timing is in Jira for sprint planning.
• Skip the new ticket if the previous one is still open. Otherwise a skipped chore becomes two identical tickets and the demand doubles on paper. Recurring Work Items has this as a rule option.
• Respect working days. A ticket due on a public holiday gets missed. Each project sets its working days, and a rule can move a due date that lands outside them. Holidays also reduce supply, which is covered in Jira holidays.

A worked month #

Take a team of five with fifteen working days in the month, so seventy-five person-days of supply before leave. Two people are away for three days each, which leaves sixty-nine. The weekly report, the fortnightly dependency update and the monthly access review together take about eight days across the team. If those are tickets with estimates, the plan shows sixty-one days for everything else. If they are not, the team plans sixty-nine days of feature work, delivers sixty-one, and the retrospective blames estimation. The arithmetic is plain. What changes the outcome is whether the eight days were written down.

When the manual way is enough #

You do not need another tool if:

• the team has two or three recurring jobs and the same person runs every planning meeting;
• the routine load is already a fixed deduction everyone agrees on, such as one day per sprint for support;
• the team runs Kanban with WIP limits and does not estimate at all.

In those cases a line in the planning agenda does the job. Add an automated approach when a recurring job has been forgotten twice, since by then the checklist has shown it does not hold. Jira recurring tasks compares the options in more depth.

Common capacity planning mistakes in Jira #

• Planning to committed, not completed. Use the completed bars.
• Forgetting leave and holidays. Subtract them from supply before you look at the backlog.
• Mixing estimate units. Changing from points to hours partway through a quarter makes every earlier velocity figure meaningless.
• Estimating only the new work. Routine tickets need estimates too, or they are invisible to the total.
• Treating a full sprint as a goal. Leave a buffer. A plan at exactly 100% of capacity is already late.

Frequently asked questions #

Does Jira have a capacity planning feature? Jira Cloud's plans include a capacity management feature on the plans that list it. Teams without it use the Velocity chart and the sprint estimate total, plus a spreadsheet for leave.

How do I find my team's capacity in Jira? Read the completed figure on the Velocity chart for the last three to five sprints, then adjust for the people available in the coming one.

How do I account for recurring work? Create it as tickets with estimates before planning, so it is counted in the sprint total. Do it by hand, with a scheduled automation rule, or with a scheduling app.

Can I see how much capacity routine work takes? Yes, if the routine tickets share a label or a work type. Save a filter on it and chart the estimate per sprint.

If routine work keeps shrinking the capacity you planned, set up the recurring tickets once and let them arrive before the next planning meeting.