Where Is Engineering Capacity Going? Measuring Investment Allocation
Every roadmap assumes a certain amount of engineering capacity. Investment allocation shows how much of it actually went to the roadmap, and how much went to production bugs, technical debt, support and operations — so plans and expectations match reality.
- Planned roadmap work 48%
- Added mid-sprint 14%
- Production bugs 22%
- Support & operations 16%
Only 48% of the sprint went to the plan the roadmap assumed.
Investment allocation shows where engineering capacity actually went — strategic initiatives, bugs, debt or support.
What investment allocation is
Investment allocation is the share of a team’s delivered (or handled) work in each kind of investment over a period. A practical set of classes:
| Class | Typically includes |
|---|---|
| Strategic initiatives | Work in roadmap epics and initiatives |
| Production bugs | Defects not linked to an initiative |
| Technical debt | Refactoring, upgrades, platform clean-up |
| Support | Customer and internal support requests |
| Operational | On-call, maintenance, infrastructure tasks |
| Other | Unclassified work |
Strategic initiatives then expand into individual initiatives or epics, so the view answers both “how much went to the roadmap?” and “which parts of the roadmap?”.
Why allocation matters
A team that spends 45% of its capacity on bugs, support and debt has 55% for the roadmap. If the roadmap was planned against 90%, the roadmap slips — and without allocation data, the slip is blamed on delivery speed.
Allocation is the antidote to one of the most common misleading conclusions in engineering reporting: a team looking slow on an initiative when a significant portion of its sprint went to other initiatives, bugs, support or technical work. It is also how leaders check that stated priorities (“Reporting is our top initiative this quarter”) match where capacity actually goes.
How to calculate it from Jira
- Choose the basis: completed work (what was delivered) or sprint work (what the team handled, finished or not).
- Choose the unit: issues or story points. Points under-weight small unestimated bugs and support tickets; issue counts show them.
- Classify work in an epic by the epic’s class (strategic by default; an epic named “Platform Tech Debt” is technical debt).
- Classify work with no epic by its work category (issue type, labels, components).
- Divide each class by the total, per sprint, and look across several sprints.
Allocation share = work in class ÷ all work (same basis, same unit)Make every classification configurable. Organisations define “strategic” differently, and the same Jira issue type means different things in different projects. Hard-coded definitions produce confident, wrong numbers.
How to interpret allocation
- Compare with the plan, not with other teams. There is no universally right split.
- Watch the trend. A bug share rising from 10% to 25% over six sprints is an early quality signal.
- Look at unlinked work. A large “no epic” share means a lot of work is invisible on the roadmap.
- Expand strategic work. An initiative’s share falling from 30% to 10% may be a deliberate reprioritisation — or drift.
Limitations
Allocation measures delivered work, not effort or time. A two-point story that took a week and a five-point story that took a day are counted by their estimates. Linkage quality matters: work that belongs to an initiative but is not linked in Jira shows up elsewhere. And past sprints are attributed to each issue’s current epic unless epic change history is available.
Apply this to your team’s delivery
Create a free account, set up your organization and project, then import a Jira CSV. Start with the available evidence; add sprint dates and history for stronger analysis.
Common mistakes — and keeping it out of individual performance
- Turning allocation into a per-person metric. Who fixed the bugs says nothing about anyone’s value; it usually reflects on-call rotations and system ownership. Keep allocation at team and sprint level.
- Treating “strategic” as good and everything else as waste. Production bugs and operations keep the product alive.
- Assuming every bug is unplanned. Many bugs are deliberately planned; see planned vs unplanned work.
- Using default classifications without review. Ten minutes of mapping review makes every later number more trustworthy.
Leadership implications and questions to ask
Use allocation to set expectations explicitly: “we plan 60% strategic, 20% bugs and support, 20% technical debt” — then check it each sprint. When reality diverges, change the plan or change the work, deliberately.
Questions worth asking
- Does our allocation match the priorities we communicated?
- Has engineering priority intentionally shifted away from any initiative?
- How much capacity should be reserved for bugs and support?
- Should unlinked work be associated with an initiative, or does it represent operational or unplanned demand?
Example
Sprint 18 completed 106 points: strategic initiatives 54%, production bugs 18%, technical debt 11%, support 9%, operational 8%. Within strategic work: Business Profile 21%, Application Workflow 17%, Reporting 10%, Authentication 6%.
The roadmap assumed 75% strategic capacity. The gap explains most of the initiative slippage leaders had been discussing — and makes the next conversation about bug volume and support ownership rather than delivery speed.
Related metrics and how the Epic Delivery report helps
See it on your own data in the Epic delivery report.
Related guides: engineering work mix, engineering initiative progress, engineering capacity planning and planned vs unplanned work.
The Epic Delivery report shows investment allocation for any sprint on a completed or sprint-work basis, expands strategic work into epics and initiatives, charts the trend across sprints, and lets you reclassify any epic. It is team-level only — there are no per-person views. See also the Capacity & Commitment report.
Frequently asked questions
- What is a good engineering investment allocation?
- There is no universal split. What matters is that allocation is chosen, communicated and checked — and that roadmaps are planned against the strategic share the team actually has.
- Should investment allocation be tracked per engineer?
- No. Allocation describes where the team’s capacity went. Per-person allocation mostly reflects rotations and ownership, and quickly becomes a misleading productivity metric.
Related guides
Engineering work mix
How to measure an engineering team’s work mix from Jira — features, bugs, testing, review, technical debt, support, operational work and research — and how to use it to plan realistic sprints.
Initiative progress
How engineering leaders can track initiatives across sprints: the initiative → epic → story hierarchy, sprint contribution, delivery, scope, carryover and investment — from Jira data.
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 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.