Skip to main content
The Investment view answers a question every VP of Engineering and CFO eventually asks: where is our engineering time actually going? DevPerform classifies merged work into categories and shows the split by effort. The investment mix, its week-over-week trend, effort-by-initiative, and cost capitalization all live together on the Investment & Cost page (Business section of the sidebar) — one home for effort-and-money questions.

Categories

Every merged PR is bucketed into one of: Classification is derived from PR titles — conventional-commit prefixes first (feat:, fix:, chore:…), then a keyword fallback. It’s a heuristic, not perfect labeling — DevPerform says so in the UI — but across many PRs it gives a reliable mix.

The views

  • Investment mix — the share of effort (by lines changed) in each category for the selected period, as a single bar plus per-category breakdown.
  • Per-team scope — filter the mix to a team and its sub-teams to compare how different groups spend their time.
  • Over time — a weekly stacked bar on the executive dashboard shows the mix shifting across the last several weeks, so you can see (for example) maintenance creeping up over a quarter.

Why it matters

A team spending 70% on KTLO is sending a clear signal about tech debt or operational load. Investment mix turns that from a gut feeling into a number you can track and act on — and it’s the basis for the cost-capitalization / R&D reporting that finance teams care about.

Custom categorization rules

When title conventions aren’t enough — a repo that’s entirely KTLO, a platform/* branch family that’s always Features — admins can define categorization rules under Admin → Settings → Investment categorization rules. A rule matches PRs on structured fields, ANDed together:
  • Repository and branch (glob patterns, e.g. infra-* or release/*)
  • Title (contains, or a regex — validated when you save it)
  • Changed file paths (prefix, e.g. docs/)
Rules are ordered by priority — the first enabled rule that matches wins, and anything no rule matches falls back to the title conventions above. The same rule engine drives the investment mix, the weekly trend, and cost capitalization, so the numbers always agree, and the views show how many PRs were rule-matched vs convention-categorized so the split stays explainable. Rules are read-only analytics: DevPerform never writes labels, reviewers, or anything else back to your code host.
Rules recompute live, including for past periods — if you change rules after capturing a cost-capitalization report, re-running it can differ. Export the CSV when you need a point-in-time record.

Improving categorization accuracy

Categories come from PR titles, so title hygiene directly improves the mix. What the categorizer understands, in priority order:
  1. Conventional-commit prefixesfeat:, perf: (Features); fix:, hotfix: (Maintenance); chore:, refactor:, ci:, docs:, deps: … (Keep-the-lights-on). The most precise signal — adopt these if you adopt nothing else.
  2. Version bumpspkg: 1.2 -> 1.3, “update foo to v2.1”, any A -> B transition (KTLO).
  3. Recognizable shapesinit at X (new component → Features), [Backport …] (Maintenance), scope: remove/drop/disable (Maintenance), scope: use/move/replace/migrate (KTLO).
  4. Branch prefixesfeat/…, fix/…, dependabot/… rescue a PR whose title carries no signal.
“Uncategorized” means none of the above matched — usually a title like “various improvements”. A team using conventional commits typically sees under 5% uncategorized.