Technische Schulden quantifizieren: Wie Sie sie CTOs und Geschäftsführung verständlich machen

Ein Satz, der in jedem Sprint-Review fällt und selten etwas bewirkt

„Dieser Service braucht dringend Refactoring." Diesen Satz hört fast jede Geschäftsführung regelmäßig und in den meisten Fällen passiert danach: nichts. Nicht weil das Anliegen falsch wäre, sondern weil es in dieser Form keine Entscheidung ermöglicht. Ein Budget-Verantwortlicher kann mit „das ist unangenehm zu warten" wenig anfangen, mit „das kostet uns jeden Monat konkret etwas" dagegen schon.

Aus eigener Erfahrung mit Projektübernahmen zeigt sich, dass technische Schulden fast nie an fehlendem Problembewusstsein scheitern. Sie scheitern daran, dass niemand sie in eine Sprache übersetzt, die neben anderen Budgetposten bestehen kann. Dieser Artikel zeigt, wie sich das ändern lässt, gestützt auf aktuelle Studienlage und konkrete Kommunikationsframeworks.

Die Ausgangslage: Was aktuelle Studien tatsächlich zeigen

Die Größenordnung technischer Schulden lässt sich inzwischen belastbarer einschätzen als noch vor wenigen Jahren. Die Deloitte 2026 Global Technology Leadership Study, eine Befragung von mehr als 660 Technologie-Führungskräften zwischen Dezember 2025 und Februar 2026, kommt zu dem Ergebnis, dass technische Schulden zwischen 21 und 40 Prozent der gesamten IT-Ausgaben binden. Deloitte nutzt in eigenen Modellrechnungen den Mittelwert von 30 Prozent als Baseline-Annahme.

Die Software Improvement Group hat in ihrem State of Software 2026 Report, veröffentlicht am 09.06.2026, die Kostenseite auf Systemebene konkretisiert: Die Reduktion von Code-Level-Tech-Debt spart im Schnitt rund 870.000 Euro Entwicklerzeit pro System und Jahr. Gleichzeitig liegen 86 Prozent des untersuchten Codes unter dem von SIG empfohlenen Wartbarkeits-Rating, 50 Prozent unter dem empfohlenen Architektur-Rating. Eine stärkere Architektur senkt laut demselben Report die Zeit zur Behebung von Issues um 30 Prozent.

Diese beiden Zahlen ergänzen sich: Deloitte liefert die Größenordnung auf Portfolio-Ebene, SIG die konkrete Kostenwirkung auf Systemebene. Zusammen liefern sie genug Substanz, um eine interne Diskussion von der Gefühlsebene auf die Zahlenebene zu heben.

Optionen mit wirtschaftlicher Einordnung

Für die Kommunikation technischer Schulden gibt es im Kern drei Herangehensweisen.

Qualitative Beschreibung ohne Zahlen. Der Zustand wird verbal beschrieben, etwa als „schwer wartbar" oder „fehleranfällig". Das kostet wenig Aufwand, verpufft aber in den meisten Priorisierungsrunden, weil es sich nicht gegen andere, konkret bezifferte Anträge behaupten kann.

Einzelne Vorfallskosten benennen. Konkrete Incidents mit ihren Recovery-Kosten und der dadurch verlorenen Zeit werden dokumentiert und als Argument genutzt. Das ist deutlich überzeugender als die rein qualitative Beschreibung, bleibt aber reaktiv und wirkt erst, nachdem bereits etwas schiefgelaufen ist.

Strukturierte Priorisierung mit Framework. Technische Schulden werden systematisch erfasst und mit einem Bewertungsmodell wie RICE oder Cost of Delay in dieselbe Sprache übersetzt, in der auch andere Investitionsentscheidungen getroffen werden. Das erfordert anfänglich mehr Aufwand für die Erhebung, liefert dafür aber eine Priorisierung, die sich im Zeitverlauf wiederholen und mit anderen Vorhaben direkt vergleichen lässt.

Entscheidungskriterien: Wie Sie technische Schulden verständlich machen

Vier Ansatzpunkte helfen dabei, aus einem vagen Befund ein tragfähiges Argument zu machen.

Vom Zustand zur Konsequenz wechseln. Statt „Service X braucht Refactoring" trägt die Formulierung deutlich weiter, wenn sie die konkrete Auswirkung benennt: Service X verlängert jedes Major-Release um mehrere Wochen, verursachte in der Vergangenheit mehrere Incidents mit bezifferbaren Recovery-Kosten und blockiert aktuell laufende Roadmap-Initiativen. Diese Übersetzung ist der wichtigste einzelne Schritt, weil sie das Anliegen aus der technischen Sprache in die Sprache der Geschäftsführung überführt.

Ein Bewertungsframework konsequent anwenden. RICE bewertet einen Kandidaten nach Reichweite, Wirkung und Vertrauen in die Einschätzung, geteilt durch den Aufwand. Cost of Delay bewertet, was das Aufschieben einer Maßnahme über die Zeit tatsächlich kostet. Die Technical Debt Ratio setzt den geschätzten Behebungsaufwand ins Verhältnis zum ursprünglichen Entwicklungsaufwand. Welches Framework passt, hängt von der bereits etablierten Priorisierungslogik im Unternehmen ab, wichtiger als die Wahl des Frameworks ist die konsequente, wiederholte Anwendung.

Architektur- von Code-Level-Schulden unterscheiden. Nicht jede Form technischer Schulden lässt sich mit denselben Mitteln beheben. Code-Level-Probleme lassen sich oft gezielt und lokal refaktorieren, architektonische Schulden erfordern dagegen strukturelle Eingriffe, die sich nicht in einem einzelnen Sprint erledigen lassen. Diese Unterscheidung schützt davor, ein architektonisches Problem mit einem punktuellen Refactoring-Ticket zu unterschätzen. Wie sich Performance-Bottlenecks konkret beziffern lassen.

Regelmäßigkeit vor Einmaligkeit stellen. Eine einzelne, gut aufbereitete Präsentation verschafft kurzfristig Aufmerksamkeit, verliert aber an Wirkung, wenn sie nicht wiederholt wird. Technische Schulden verändern sich kontinuierlich, eine wiederkehrende, mit denselben Kennzahlen arbeitende Berichterstattung baut dagegen Vertrauen auf und macht Entwicklungen über die Zeit sichtbar.

Ein ehrlicher Punkt zur Grenze dieser Herangehensweise: Ein Framework macht die Priorisierung nachvollziehbar, es macht sie nicht automatisch richtig. Die Qualität der Einschätzung hängt weiterhin davon ab, wie realistisch Reichweite, Wirkung und Aufwand tatsächlich geschätzt werden. Ein sorgfältig ausgefülltes Framework mit unrealistischen Eingangswerten liefert am Ende trotzdem eine unzuverlässige Priorisierung.

Was diese Zahlen für Ihre nächste Priorisierungsrunde bedeuten

Die aktuelle Studienlage liefert erstmals eine belastbare Größenordnung, die sich intern zitieren lässt, ohne auf einen einzelnen, möglicherweise nicht repräsentativen Einzelfall angewiesen zu sein. Damit lässt sich der grundsätzliche Handlungsbedarf begründen, die konkrete Priorisierung im eigenen Portfolio bleibt trotzdem Aufgabe des jeweiligen Teams.

Wer beim nächsten Refactoring-Antrag nicht mit dem Zustand des Codes beginnt, sondern mit der konkreten Konsequenz für Release-Zeiten, Incidents und Roadmap, hat bereits den größten Teil der Übersetzungsarbeit geleistet.

Dennis Schwenker-Sanders ist PHP- und Symfony-Entwickler und unterstützt Agenturen und KMU im DACH-Raum dabei, technische Schulden in gewachsenen Systemen einzuschätzen und zu priorisieren. Mehr zur Zusammenarbeit als Symfony-Entwickler finden Sie auf der Leistungsseite.