I'mBoard API Docs

Breakdown of engineering capacity across new features, maintenance, and tech debt — typically reported as a three-way split summing to 100%. The execution-level view of where engineering hours are actually going (vs. `innovation_capacity_pct` which is a single percentage for new-capabilities work, and vs. `offensive_roadmap_pct` which is a roadmap-classification percentage). Common pitfall: capacity allocation reported in plan rather than actuals. The plan can say 60% new features but the actuals can be 30% new features and 50% support work — the gap is the operating signal. Boards should require both planned and actual splits, at least quarterly. — Product KPI, I'mBoard-authored (editorial tier).

I'mBoard-authored (editorial tier)

No public third-party standard anchors this KPI yet, so I'mBoard authors and maintains the definition — transparently labeled as editorial tier. See the ontology methodology for the published vs editorial tier system and the back-attribution workstream.

Rogue ID: product.capacity_allocation_pct Type: Percentage (%) Domain: Product

Definition

Breakdown of engineering capacity across new features, maintenance, and tech debt — typically reported as a three-way split summing to 100%. The execution-level view of where engineering hours are actually going (vs. innovation_capacity_pct which is a single percentage for new-capabilities work, and vs. offensive_roadmap_pct which is a roadmap-classification percentage). Common pitfall: capacity allocation reported in plan rather than actuals. The plan can say 60% new features but the actuals can be 30% new features and 50% support work — the gap is the operating signal. Boards should require both planned and actual splits, at least quarterly.

Formula

Three-way breakdown: new_features_pct + maintenance_pct + tech_debt_pct = 100%. Measured in the same unit as capacity (eng-weeks, story points, or sprint capacity). Report planned vs actual split — the gap is the operational signal.

Why it matters

Names where engineering hours actually go. The plan-versus-actual gap is one of the highest-signal operational metrics for the board — a persistent 20+ point gap between planned and actual new-feature allocation is the loudest possible flag that the company is under-investing in platform health (the missing hours are going to firefighting).

How to interpret

Industry folk-wisdom, not citation-grade: a healthy steady-state split at growth-stage SaaS is roughly 50–70% new features, 15–30% maintenance, 10–20% tech debt. Companies in platform-investment cycles will skew toward maintenance and tech debt. Pair with innovation_capacity_pct and delivery_predictability — capacity allocation tells you where time goes, predictability tells you whether commitments hold, innovation capacity tells you the available headroom for offense.

Calculation policy

How an AI agent should compute this KPI from messy company data. Free-text rules consumed at reasoning time — not a deterministic DSL. The most common ways to get this wrong are listed under Common miscomputations.

Inclusion rules

Three-way breakdown of engineering capacity by WORK TYPE — new_features_pct + maintenance_pct + tech_debt_pct = 100% — over a measurement window (typically a quarter).
Denominator is total engineering capacity for the window, measured in a single unit (eng-weeks, story points, or sprint capacity).
Report BOTH the planned and the actual split — the plan-vs-actual gap is the operating signal this KPI exists to surface.

Exclusion rules

The offensive / defensive / commitments roadmap percentages — that is the separate product.*_roadmap_pct partition with a different denominator (roadmap capacity, not all engineering capacity); do not merge the two.
Capacity outside the engineering org (sales, CS) unless the board capacity definition explicitly includes embedded engineers — pin the boundary once.
Non-capacity counts (headcount, dollars) — this is a share-of-hours partition.

Required inputs

Engineering time / capacity tracked by work type (new features / maintenance / tech debt) for the window.
Both the planned split and the actual split.
The capacity unit and the inclusion boundary of "engineering capacity".

Data-source priority

Engineering time / issue tracker tagged by work type (the actuals source).
Sprint / roadmap plan for the planned split.
Engineering-leadership estimate when actual time is not tracked — flag the lower confidence.

Edge cases

A bucket omitted (e.g. customer-support engineering silently folded into maintenance): define the three buckets once and keep them stable, or the split will not sum to 100%.
Plan reported as actual: require both — reporting only the plan hides the gap this KPI exists to surface.
An item spanning buckets (a refactor that also ships a feature): split its capacity rather than forcing one bucket.

Validation checks

new_features_pct + maintenance_pct + tech_debt_pct must sum to 100% (the three buckets are a mutually-exclusive partition of total engineering capacity) — a sum off 100% means a bucket was omitted or work was double-counted.
A persistent 20+ point gap between planned and actual new-feature allocation is a loud signal the company is under-investing in platform health (the missing hours go to firefighting).
This work-type partition is distinct from the product.*_roadmap_pct strategic-intent partition — do not expect the two to reconcile to each other.

Common miscomputations

Reporting the planned split as if it were actuals — hides the plan-vs-actual gap that is the whole point.
Conflating this work-type partition with the offensive / defensive / commitments roadmap-intent partition (different denominator).
Omitting a bucket (e.g. support engineering) so the three shares do not sum to 100%.

product.innovation_capacity_pct
product.offensive_roadmap_pct
product.defensive_roadmap_pct
product.delivery_predictability
product.total_engineers

Source

I'mBoard editorial — authored and maintained by I'mBoard, first published 2026-04-01. No third-party standard is cited for this KPI; when one emerges, the definition is back-attributed and promoted to the published tier (a minor version bump). Read the ontology methodology for the published vs editorial tier system, attribution rules, and dispute process.