„Wir haben zu viel Tech-Debt.” Jeder CTO sagt es irgendwann. Niemand kann erklären, wie viel genau — und genau deswegen kommt im nächsten Sprint doch wieder nur ein Feature statt einer Refactor-Story. Tech-Debt, das nicht gemessen ist, verliert gegen jedes Business-Argument. Hier sind fünf Metriken, mit denen du aus dem Bauchgefühl eine verhandelbare Zahl machst.

1. Change Failure Rate

Prozent der Deployments, die einen Hotfix, Rollback oder Revert nach sich ziehen. Elite-Teams laut DORA-Studie: unter 5 %. Teams mit hohem Tech-Debt: oft über 20 %.

Warum es Tech-Debt-Indikator ist: Fragile Architektur, fehlende Tests, unklare Schnittstellen verursachen kaskadierende Fehler. Wenn fast jeder fünfte Deploy schiefgeht, zahlt ihr die Debt-Zinsen mit jeder Produktionsnacht.

Messung: Deployment-Tool + Issue-Tracker verknüpfen. Jede Production-Issue, die innerhalb 24h nach Deploy aufploppt, zählt.

2. Mean Time to Restore (MTTR)

Wie lange braucht ihr vom Incident-Erkennen bis zur Wiederherstellung? Elite: unter eine Stunde. High-Debt-Teams: sechs Stunden aufwärts.

Warum es Tech-Debt-Indikator ist: MTTR misst nicht nur Infrastruktur-Resilienz, sondern auch Code-Verständlichkeit. Wenn niemand mehr weiß, wie das Payment-Modul intern funktioniert, dauert jede Recovery doppelt so lang.

3. Cycle Time (Lead Time for Changes)

Zeit von „Code committed” bis „im Produktionssystem”. Elite: unter 24 Stunden. High-Debt-Teams: Wochen.

Warum es Tech-Debt-Indikator ist: Lange Cycle-Times entstehen selten durch Faulheit — sie entstehen durch Test-Flakiness, manuelle Deploy-Schritte, Merge-Konflikte in großen PRs, fehlende CI. Alles Tech-Debt-Symptome, die sich messen lassen.

4. Modul-Komplexitäts-Konzentration

Nicht der Durchschnitts-Cyclomatic-Complexity-Wert zählt, sondern: wie viele Module haben eine Cyclomatic Complexity >20 pro Funktion? Diese „komplexen Inseln” verursachen überproportional viele Bugs.

Messung: lizard, sonarlint, radon (Python) oder vergleichbar. Dashboard zeigt die Top 10 — das sind eure Kandidaten für gezielten Refactor.

Faustformel: Teams mit >10 % aller Funktionen in Cyclomatic Complexity >20 haben systemisches Debt. Unter 3 %: gesundes Niveau.

5. Dependency-Age-Quote

Prozent eurer Dependencies, die mehr als 18 Monate hinter der aktuellen Major-Version liegen. Unter 10 %: gut. Über 40 %: Risiko-Zone.

Warum es Tech-Debt-Indikator ist: Veraltete Dependencies bedeuten Security-Risiko (CVEs), Feature-Rückstand (neue Framework-Funktionen nicht nutzbar) und Migrations-Schuld, die mit der Zeit exponentiell wächst. Alte Rails-3-Apps zu Rails-7 zu migrieren ist teurer als fünf Sprünge à 1 Major.

Messung: npm outdated, pip list --outdated, renovate oder dependabot-Dashboards. Lass dir die Quote monatlich als Zahl geben, nicht als Liste.

Wie du die Diskussion führst

Mit diesen fünf Zahlen änderst du das Gespräch im Sprint-Planning. Statt „wir sollten refactoren, weil das Gefühl schlecht ist” sagst du:

„Unsere Change Failure Rate ist auf 18 %. Vor sechs Monaten waren wir bei 9 %. Die Dependency-Age-Quote liegt bei 42 %. Wenn wir zwei Sprints in die komplexen Module im Billing-Service stecken, projizieren wir CFR auf <10 % zurück. Business-Case: weniger Incident-Overhead, schnellere Releases im Q3-Roadmap-Plan.”

Das ist keine Refactor-Lyrik. Das ist Business-Sprache.

Wie man die Zahlen praktisch zieht

Alle fünf Kennzahlen lassen sich mit Open-Source-Werkzeugen oder Standard-CI-Integrationen ziehen — ohne Lizenzkosten:

Der eigentliche Aufwand liegt nicht in der Messung, sondern im regelmäßigen Auswerten und in der Konvertierung der Zahlen in Business-Sprache. Wer dafür keine Ressource im Team frei hat, dem bleibt entweder ein interner „Tech-Debt-Owner”-Rolle oder eine externe, strukturierte Review — aber das ist ein anderes Thema.

Wenn du dir für ein konkretes Projekt eine erste Baseline aufbauen willst und Fragen hast, welche Tool-Kombination für euren Stack am schlanksten ist: kurze Nachricht an hello@solustainable.com. Wir geben Auskunft ohne Sales-Trichter.