Engineering Team Capacity Planning: Plan From What You Deliver, Not What You Hope

What engineering capacity means

Engineering capacity is the amount of work a team can realistically finish in a period, given everything that competes for its time: planned roadmap work, bugs, support, operational duties, reviews, meetings and the unfinished work it is already carrying. It is a property of the whole delivery system — people, process, tooling and dependencies — not a sum of individual availabilities.

That distinction matters because capacity is usually estimated from the wrong end. Headcount × working days × a focus factor gives a theoretical number that assumes work flows without waiting. Real sprints are full of waiting: for review, for QA, for a release window, for a product decision. The work a team *delivers* already includes all of that friction, which is why historical delivery is the most reliable capacity signal most teams have.

Capacity, velocity and throughput

Velocity and throughput are *measurements of the past*. Capacity is a *judgement about the future* informed by them. See team capacity vs velocity and engineering throughput for each in depth.

Why story points are not hours

Story points express relative size and uncertainty, not time. A 5-point story is not “two and a half days”; it is “roughly twice as big and uncertain as a typical 2-pointer”. Converting points to hours reintroduces the precision that points were designed to avoid, and it invites comparing teams whose scales mean different things. Plan in points *or* in issue counts, and compare only with the same team’s history in the same unit.

Why capacity planning goes wrong

Missed commitments are rarely caused by a team working slowly. They are usually planning outcomes: the sprint started with more work than the team has ever completed, often without anyone noticing, because the commitment was built from three separate piles that nobody added up.

• Carryover. Unfinished work from the last sprint rolls in and occupies the team before any new work starts. It is easy to overlook because it was “already planned”. See Jira carryover.
• Existing WIP. Work that is started but unfinished competes for attention, reviews and QA. A sprint that starts with a large WIP backlog has less room than its calendar suggests.
• Unplanned work. Incidents, urgent bugs, support escalations and stakeholder requests arrive mid-sprint. See planned vs unplanned work and sprint scope creep.

A sprint can therefore start with a perfectly reasonable amount of *new* work and still end with far more *total* work than the team delivers. That is the pattern capacity planning exists to catch.

The most useful capacity question is not “how many points can we fit?” but “how much of next sprint is already spoken for?”

How to calculate capacity from historical delivery

1. Collect completed work (issues and, if used consistently, points) for the last six to ten closed sprints.
2. Take the median as the planning anchor and the 75th percentile (P75) as the upper end of typical delivery.
3. Estimate existing WIP: work unfinished in the current sprint that will carry into the next.
4. Add the proposed new work for the next sprint.
5. Compare proposed demand = existing WIP + proposed new work with the median and P75.

Proposed demand = existing WIP + proposed new work
Difference     = proposed demand − historical median
Difference %   = difference ÷ historical median

Median vs average throughput

Use the median, not the mean. One sprint that shipped a release backlog, or one that lost half the team to an incident, can move an average a long way; it barely moves the median. For example, completed points of 44, 48, 52, 49, 119 and 13 have a mean of 54 but a median of 48.5. Planning to 54 would build the release-backlog sprint into every future commitment.

How carryover affects capacity

Carryover is not free capacity that “was already planned”. It is work that competes with new commitments. If the team typically completes 50 points and 30 points are carrying in, only about 20 points of new work fit a typical sprint — before any unplanned work arrives.

Planned vs unplanned work and scope creep

If, historically, 20% of what the team completes arrived after sprint start, a plan that fills 100% of median throughput with planned work leaves no room for it. Either reserve explicit room or accept that some planned work will move. Scope added after planning is measurable in Jira; see sprint scope creep.

How to interpret the numbers

These are planning signals, not predictions. A plan above the median is not “going to fail” — it simply asks for more than the team has usually delivered, and leaders should decide consciously whether that is acceptable.

Why individual capacity metrics mislead

Points per developer, individual velocity and “top performer” rankings measure the wrong thing. Delivery is a team outcome: a senior engineer who spends the sprint unblocking reviews may close few tickets and double everyone else’s throughput. Individual metrics reward visible ticket-closing over the collaboration that actually moves work, they are trivially gamed by splitting tickets, and they damage the trust that makes honest estimation possible. Capacity belongs at the team and delivery-system level.

Common capacity planning mistakes

• Planning new work as if the sprint starts empty. Carryover and in-progress work are already there.
• Planning to the best sprint. The maximum is an outlier by definition; plan around the median.
• Using averages. One unusual sprint distorts the mean. Use the median and show the range.
• Converting points to hours. It creates false precision and invites cross-team comparisons that mean nothing.
• Leaving no room for unplanned work. If a fifth of delivered work typically arrives mid-sprint, plan for it.
• Measuring individuals. Capacity is a team property; per-person productivity scores distort behaviour.
• Treating a missed commitment as poor performance. Most misses are planning outcomes. Investigate the plan first.
• Keeping an obsolete plan. When the team loses people or an incident lands, re-plan instead of explaining the miss later.

Leadership implications and questions to ask

For leaders, capacity planning is mostly about making trade-offs visible early. If commitment consistently exceeds delivery, the conversation should move from “why didn’t the team finish?” to “why are we committing to more than we deliver?” — a question about intake, prioritisation and planning, which leaders own.

Questions engineering managers should ask

• Are we planning based on requested scope rather than demonstrated delivery capacity?
• How much of next sprint is already taken by carryover and in-progress work?
• What share of last sprint’s completed work was unplanned, and do we reserve room for it?
• Has our commitment grown while throughput stayed flat?
• Which items would we drop first if the sprint runs like a typical one?
• Is a bottleneck — review, QA, release — limiting delivery more than headcount is?

Worked example

A team’s last six closed sprints completed 51, 13, 119, 48, 44 and 52 points. The median is 49.5; the P75 is 51.75; the mean is 54.5, pulled up by the 119-point release-backlog sprint.

For the next sprint, product proposes 60 points of new work. The current sprint still has 64 points unfinished that will roll forward. Proposed demand is 124 points — about 150% above the median.

Nobody proposed 124 points. Product proposed 60, which already looked ambitious; carryover doubled it. The useful decisions are about the existing work: finish, split or drop the carried items before adding new ones, and agree a stretch line inside the 60.

Related metrics and how the Capacity & Commitment report helps

See it on your own data in the Capacity & commitment report.

Capacity connects to most delivery metrics: carryover, scope creep, bottlenecks, cycle time and aging WIP. For planning with historical ranges in depth, see sprint capacity planning.

The Capacity & Commitment report shows committed vs completed work for every sprint, split into carryover in and new commitment, with scope added on top. It computes median, P75 and rolling averages of throughput, separates planned from unplanned work, shows existing WIP next to proposed new work for the next sprint, and lets you open the Jira issues behind every number. Analysis runs in your browser. With an active organization project, imports are also stored for its members. See data handling.

Frequently asked questions

What is the difference between capacity and velocity?

Velocity is a measurement: story points completed per sprint. Capacity is a planning judgement about how much the team can take on next, informed by velocity or throughput and by how much work is already in progress.

Should capacity planning use hours?

Not for sprint commitments. Hours-based plans assume work flows without waiting and ignore review, QA and interrupts. Historical throughput already includes that friction.

Why use the median instead of the average?

One unusual sprint can move an average a long way. The median is robust to outliers, so it is a more honest planning anchor.

Should we track capacity per developer?

No. Delivery is a team outcome, and individual productivity metrics distort behaviour and damage trust. Measure the team and the delivery system.

Related guides

• Sprint capacity

  A step-by-step method for calculating sprint capacity from historical throughput: median delivery, existing WIP, room for unplanned work, and why hour-based capacity formulas overcommit teams.

• Capacity vs velocity

  Team capacity and velocity are often confused. Learn what each measures, why velocity is not a productivity score, how carryover distorts velocity, and how to combine them for realistic sprint commitments.

• Commitment vs capacity

  Why sprint commitments drift above team capacity — carryover, existing WIP, scope growth — how to measure commitment accuracy without turning it into a performance metric, and how leaders can plan to demonstrated delivery.

• Planned vs unplanned work

  How to measure planned vs unplanned engineering work from Jira by when work entered the sprint — not by issue type — why bugs are not automatically unplanned, and how to reserve capacity for unplanned work.

• Engineering throughput

  What engineering throughput is, how to calculate it from Jira in issues or points, why median and P75 beat averages, what flat throughput under rising demand means, and why throughput is a team measure.

• Jira capacity planning

  How to do capacity planning with Jira data: which fields to export, how to measure throughput, carryover and scope change from a Jira CSV, what needs sprint dates or change history, and what Jira cannot know.