Investment allocation: where the quarter actually went
Everyone has an opinion about how the team spent its time. This widget replaces the opinion with a count — engineering investment allocation by closed-issue type: feature, bug, tech debt, keep-the-lights-on, or uncategorised. It's the one chart that ends the "we're mostly building new stuff, right?" debate.
Investment allocation by closed-issue count, trailing quarter.
What it measures, and where the data comes from
A donut of completed effort in the window, by count of issues closed — not story points, not hours, just "what type of work did we actually finish." Five buckets: new features (green), bug fixes (rose), tech debt (amber), keep-the-lights-on maintenance (slate), and uncategorised (violet) for anything that couldn't be typed.
- Jira — issues closed in the window, bucketed from issue type and labels (Story/Task → feature, Bug → bug fix, tech-debt label → tech debt, Sub-task/Chore-style types → maintenance).
- Azure DevOps — work items closed in the window, same bucketing logic applied to ADO's work item type field.
- GitHub — issues closed in the window, bucketed from issue labels where a repo tags them; unlabelled GitHub issues are the most common source of the uncategorised slice.
How to read it
Start with the feature slice against everything else. That ratio is your real answer to "how much of the roadmap did we actually deliver versus how much did we spend standing still." Everything else on the chart is either a reasonable cost of doing business or a warning sign, depending on size.
Bug fix and maintenance are supposed to exist — zero in either bucket usually means mislabelling, not a perfect quarter. What matters is whether they're proportionate or whether they've quietly become the majority of the pie.
What it tells you over time
Any one quarter has an alibi — a reorg, a big migration, a rough month everyone remembers by name. What can't be explained away is a feature slice that shrinks two quarters running while maintenance grows; that's the clearest early signal of a codebase accumulating debt faster than anyone's paying it down — long before it shows up in a lead-time or velocity chart.
Watch the tech-debt slice specifically for whether it's a deliberate, sustained line item or something that only appears right after an incident. A tech-debt wedge that spikes once and disappears is reactive firefighting, not investment.
Example situations
1. Justifying a tech-debt investment to the board
Bug and maintenance dominate; tech debt barely registers.
What you're seeing: bug fix and maintenance together eat nearly two-thirds of the quarter, while the deliberate tech-debt slice is a sliver. That's not a healthy split — it's a team paying interest on debt every week without ever touching the principal.
How to react: don't fold tech-debt work into "maintenance" and call it handled — they're different. Maintenance is keeping the lights on; tech debt is the wiring that keeps needing repair. A big bug/maintenance slice with almost no tech-debt slice means nobody's addressing the root cause, just the symptoms.
2. The feature roadmap keeps slipping
Feature slice well under half; maintenance has crept up.
What you're seeing: a third of the quarter went to new features and roughly the same amount went to keep-the-lights-on maintenance alone. Product keeps asking why the roadmap slips, and this is the honest answer: upkeep is quietly eating the capacity the roadmap assumed it had.
How to react: this isn't a "try harder" problem or an estimation problem — it's a capacity-allocation problem nobody decided on purpose. The team didn't choose to spend a third of the quarter on maintenance; it just happened, one urgent ticket at a time.
Frequently asked
- What is engineering investment allocation?
- A breakdown of where delivered effort actually went, by closed-issue type: features, bugs, tech debt, keep-the-lights-on, and uncategorised. It replaces opinions about the mix with a count.
- Where does the classification come from?
- From issue type and classification on closed items across Jira, Azure DevOps and GitHub. Items that cannot be classified land in the uncategorised slice rather than being silently assigned.
- What if a large share is uncategorised?
- Fix that before reading the rest. A large uncategorised slice means the mix shown for the other categories is unreliable, and the fastest remedy is tightening issue-type discipline at the source.
Related widgets
- Bug Rate — the weekly detail behind a growing bug-fix slice.
- Rework Rate — whether that maintenance and bug-fix time is being spent well or wasted redoing recent work.
- Velocity with Confidence — checks whether a shrinking feature slice is also making delivery less predictable.
- Back to the widget reference.
Last updated