Delivery Capacity Planning: A Practical Guide
your work tracker holds most of what you need for honest capacity planning — if you know which fields to use and which questions the data cannot answer. This guide walks through the export, the calculations and the limits.
68 issues of demand against 57 typically completed: about 11 more than the team has recently delivered — before any interrupts.
Plan capacity after inherited work: carryover consumes the sprint before any new commitment is made.
What delivery capacity planning is
delivery capacity planning means using the sprint history in your delivery workflow to decide how much work a team should commit to next. Instead of asking people to estimate their availability, you use what the delivery data shows the team actually completed, how much work was already in flight, and how much arrived after planning.
your work tracker’s built-in sprint report and velocity chart show part of this. They do not separate carryover from new commitment, they rarely make existing WIP visible at planning time, and they do not tell you how much of your delivered work was unplanned. A CSV export plus a little structure closes those gaps.
Why it matters
Sprint planning in your delivery workflow usually starts from the backlog: drag items into the next sprint until it “looks full”. What the board does not show clearly is that unfinished issues from the current sprint will be moved into the same sprint when it closes. The commitment that looked reasonable at planning quietly grows by the size of the carryover.
Using delivery data for capacity planning makes three things explicit before the sprint starts: how much the team usually completes, how much is already spoken for, and how much typically arrives unplanned.
How to calculate capacity from a delivery data export
Demand = carried-in work + new commitment = 24 + 44 = 68 issues, against a median of 57 completed
1. Export the right fields
From a board or filter covering at least six recent sprints, choose Export → Export CSV (all fields). The fields that matter:
| Field | Used for |
|---|---|
| Issue key, Issue type, Status | Identity, work category, current stage |
| Sprint (all values) | Which sprints an issue was in — the basis of carryover |
| Created, Resolved | Completion timing; additions after sprint start (a minimum) |
| Story points (optional) | Point-based throughput; issue counts work without them |
| Labels | Categories such as tech debt, support or operational work |
2. Add sprint dates
A standard delivery data file does not include sprint start and end dates. Without them you cannot tell work committed at planning from work added later. Add them from the sprint report or board settings.
3. Optionally add change history
Exact scope added and removed needs the history of the Sprint field (from the issue changelog). With only Created dates, additions are a minimum: an older issue pulled into the sprint mid-way looks like it was planned. Removals are invisible without history, because a removed issue no longer lists the sprint.
4. Calculate
Carryover in = committed issues that list an earlier sprint
New commitment = original commitment − carryover in
Throughput = issues (or points) resolved inside the sprint window
Proposed demand = existing WIP + proposed new workHow to interpret your work tracker capacity data
Sprint 20
60 → 56gap 4
Sprint 21
65 → 57gap 8
Sprint 22
72 → 58gap 14
Sprint 23
78 → 59gap 19
- Committed ↑ +18
- Completed → +3
When commitment keeps rising and demonstrated throughput does not, carryover follows — plan against what the team has actually completed.
- Multi-value Sprint fields are your carryover record. An issue listing Sprint 18 and Sprint 19 was carried from 18 to 19.
- Resolved dates define throughput. Work resolved after the sprint ended belongs to the next sprint’s throughput, even if it was committed earlier.
- Evidence levels matter. A number derived from Created dates is a minimum; say so. A number that needs change history you do not have should be shown as “insufficient data”, not zero.
- Compare with the same team only. Different teams use points differently; delivery data does not make them comparable.
Apply this to your team’s delivery
Import a delivery data file and analyze it in your browser. Start with the available evidence; add sprint dates and history for stronger analysis.
Common mistakes with delivery data capacity data
- Using only the first Sprint column. delivery data exports one column per sprint value; reading only the first hides carryover.
- Trusting “Completed” from the sprint report as throughput. It excludes work finished after an issue was moved out, and treats removed work inconsistently.
- Treating missing data as zero. No removals in a CSV does not mean nothing was removed.
- Planning from delivery data’s capacity fields (hours). Hour estimates ignore waiting time; historical throughput does not.
- Ranking people by resolved issues. your work tracker makes it easy; it measures the wrong thing and damages trust.
Leadership implications and questions to ask
delivery data is good at showing patterns across sprints, which is exactly what leaders need: whether commitment is creeping up, whether carryover is accumulating, whether unplanned work is growing. It is poor at explaining individual days or individual people — and it should not be used for that.
Questions engineering managers should ask
- Does our planning view show carryover separately from new work?
- Do we record sprint dates and keep issue history, so scope change is measurable?
- Which labels or issue types represent support and operational work, and how much capacity do they take?
- Are we comparing next sprint’s plan with median throughput or with our best sprint?
Example
A team exports eight sprints. Throughput per closed sprint is 18, 15, 18, 14, 18, 5, 35 and 20 issues; the median is 18. The latest sprint started with 23 issues: 7 carried in and 16 new. Three issues created mid-sprint were added (a minimum, since there is no Sprint history). At close, 7 issues moved on to the next sprint — which already contains 16 proposed new issues. Proposed demand is 23 issues against a median of 18: about 28% above typical delivery, with carryover accounting for nearly a third of it.
Related metrics and how the Capacity & Commitment report helps
See it on your own data in the Capacity & commitment report.
Related guides: engineering capacity planning, sprint capacity, sprint carryover and sprint health.
Import your delivery data file (and optionally sprint dates and change history) and the Capacity & Commitment report does these calculations for you, labelling every number as Observed, Inferred or Unavailable and linking it to the issues behind it. Processing happens in your browser; nothing is uploaded.
Frequently asked questions
- Does a delivery data export include sprint dates?
- No. The Sprint field lists sprint names only. Add start and end dates from the sprint report or board to separate committed from added work.
- Can I see scope removed from a sprint in a delivery data file?
- No. A removed issue no longer lists the sprint, so it disappears. Removals need the Sprint field change history.
- Do I need story points for delivery capacity planning?
- No. Issue counts work well, especially when estimation is inconsistent. Use points only if the team estimates consistently.
Related guides
Engineering capacity planning
A practical guide to engineering team capacity planning: capacity vs velocity and throughput, carryover and existing WIP, planned vs unplanned work, median throughput, and the mistakes that make sprints overcommit.
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.
Sprint carryover
How to calculate sprint carryover from a delivery data export, classify it by reason (review, QA, release, blocked), and tell the difference between observed and inferred causes.
Sprint health
A practical guide to sprint health for engineering managers: commitment reliability, scope change, carryover and throughput — how to calculate them from delivery data and what to do about them.