Tech Debt sichtbar und verhandelbar machen
Tech Debt sichtbar und verhandelbar machen
Wie Product Owner technische Schulden aus der Nerd-Ecke holen und produktiv priorisieren.
Technische Schulden sind selten das eigentliche Problem. Das Problem ist, dass niemand außerhalb des Entwicklungsteams versteht, was sie bedeuten, warum sie gefährlich sind und wann sie relevant werden.
Als Product Owner stehst du genau dazwischen. Und genau dort kannst du den Unterschied machen.
Warum Tech Debt für Product Owner so schwer greifbar ist
Tech Debt fühlt sich oft abstrakt an:
- „Das müssten wir mal refactoren“
- „Das skaliert so nicht“
- „Das wird später richtig teuer“
Für Stakeholder klingt das nach:
„Nice to have, aber nicht dringend.“
Und für viele Product Owner ehrlich gesagt auch. Nicht aus Ignoranz, sondern weil Übersetzung fehlt.
Schritt 1: Tech Debt in Produkt-Sprache übersetzen
Solange Tech Debt technisch beschrieben wird, ist sie kaum verhandelbar. Der erste Hebel ist Sprache.
Statt:
- „Legacy-Code“
- „Unsaubere Architektur“
- „Hohe Komplexität“
Besser:
- Erhöhte Time-to-Market
- Steigende Fehleranfälligkeit
- Eingeschränkte Erweiterbarkeit
- Abhängigkeit von Einzelpersonen
- Erhöhtes Ausfall- oder Sicherheitsrisiko
👉 Frage dein Team aktiv:
„Was bedeutet diese technische Schuld konkret für Nutzer, Business oder Delivery?“
Schritt 2: Tech Debt sichtbar machen (nicht nur erwähnen)
Was nicht sichtbar ist, existiert in Priorisierungen faktisch nicht.
Bewährte Visualisierungen:
- Tech-Debt-Backlog als gleichwertiger Teil des Product Backlogs
- Ampel-Logik pro System oder Modul
Grün = unkritisch, Gelb = wachsend, Rot = produktgefährdend - Trend statt Einzelwert
Wird es besser oder schlechter über Zeit? (z. B. mit einfachen Metriken)
Wichtig: Nicht jede Schuld braucht sofort eine Story. Aber jede relevante Schuld braucht Transparenz.
Schritt 3: Tech Debt priorisierbar machen
Tech Debt konkurriert immer mit Features. Also muss sie vergleichbar werden.
Drei bewährte Fragen zur Einordnung:
- Was passiert, wenn wir nichts tun?
(Kosten, Risiken, Verzögerungen) - Wann wird es spürbar?
(Jetzt, in 3 Monaten, beim nächsten Skalierungsschritt) - Was blockiert es konkret?
(Feature X, Markt Y, SLA Z)
Erst wenn diese Fragen beantwortet sind, wird aus „technisch sinnvoll“ eine produktstrategische Entscheidung.
Wenn du dafür eine klare Priorisierungslogik brauchst, hilft das Eisenhower-Prinzip als schnelle Entscheidungshilfe.
Schritt 4: Verhandeln statt Durchdrücken
Tech Debt ist kein Selbstzweck. Aber sie ist auch kein „Restposten für freie Kapazitäten“.
Gute Muster:
- Debt-Tickets mit klarem Business-Kontext
- Fixe Capacity-Anteile (z. B. 20 % pro Sprint)
- Debt gekoppelt an Features
„Feature X nur sinnvoll, wenn wir vorher Y aufräumen“
Schlechte Muster:
- Schuld „unter Feature-Stories verstecken“
- Vage Formulierungen ohne Impact
- Alles oder nichts fordern
Die Rolle des Product Owners dabei
Du musst Tech Debt nicht selbst bewerten. Aber du bist verantwortlich dafür, dass sie verstanden, eingeordnet und entschieden wird.
Deine Kernaufgaben:
- Übersetzen
- Sichtbarkeit schaffen
- Priorisierung ermöglichen
- Entscheidungen moderieren
Nicht mehr. Aber auch nicht weniger.
Fazit
Tech Debt verschwindet nicht, weil man sie ignoriert. Und sie wird nicht priorisiert, nur weil sie technisch sinnvoll ist.
Sie wird priorisiert, wenn sie:
- verständlich,
- sichtbar
- und vergleichbar ist.
Genau hier kann ein Product Owner enormen Wert liefern.
Bonus-Frage zum Mitnehmen:
👉 Welche technische Schuld in deinem Produkt würdest du heute nicht mehr erklären können?
