Retrospektive zu technischen Schulden

Technische Schulden finden, priorisieren und gezielt abbauen

Probieren Sie diese Retrospektive live aus

Quellen der Schulden

In welchen Bereichen der Codebasis haben sich technische Schulden angesammelt?

Das Authentifizierungsmodul ist durch unzählige Hacks und Workarounds über die Jahre viel zu komplex und schwer wartbar geworden.
Wir haben jede Menge duplizierten Code in verschiedenen Komponenten, der in gemeinsame Utilities ausgelagert werden sollte.
Viele unserer zentralen Datenmodelle sind eng gekoppelt, deshalb riskieren wir bei jeder Erweiterung oder Änderung Regressionen.
Auswirkungen und Risiken

Wie wirken sich diese technischen Schulden auf Team und Produkt aus?

Neue Entwickler einzuarbeiten ist extrem schwierig, weil manche Bereiche so komplex und kaum dokumentiert sind.
Wir löschen ständig Brände und schaffen es wegen der Instabilität durch die Schulden nicht, neue Features in vernünftigem Tempo zu liefern.
Unser Deployment-Prozess ist fragil und fehleranfällig, was regelmäßig zu Problemen und Ausfällen in Produktion führt.
Priorisierung

Welche Schuldenbereiche sollten wir zuerst angehen?

Wir sollten mit dem Authentifizierungsmodul anfangen, weil es eine zentrale Abhängigkeit ist, die viele Bereiche der Anwendung betrifft.
Mehr Testabdeckung für unsere instabilsten Komponenten wäre eine solide Grundlage für künftige Refactorings.
Das Upgrade unseres Frontends auf die neueste React-Version sollte ganz oben stehen, damit wir von Performance-Verbesserungen und neuen Features profitieren.
Maßnahmenplan

Wie bauen wir die priorisierten Schulden systematisch ab?

Wir reservieren 20 % jedes Sprints für Schuldenpunkte mit hoher Priorität und beginnen mit dem Refactoring des Authentifizierungsmoduls.
Alle zwei Wochen gibt es einen festen „Tilgungstag“, an dem wir anhand der Priorisierung schrittweise Verbesserungen umsetzen.
Im nächsten Quartal kümmert sich ein Senior-Entwickler ausschließlich darum, den Abbau unserer technischen Schulden voranzutreiben.

Was ist eine Retrospektive zu technischen Schulden?

Eine Retrospektive zu technischen Schulden ist eine fokussierte Sitzung, in der euer Team die Schulden in Codebasis oder System erfasst, sich darauf einigt, was sie kosten, und entscheidet, was zuerst abgebaut wird. Am Ende steht ein Plan mit Verantwortlichen und Terminen. Technische Schulden sind die Ansammlung von Abkürzungen und suboptimalen Lösungen in einer Codebasis. Manches entsteht, weil kurzfristige Lieferung Vorrang vor langfristiger Qualität hatte, manches durch Wissenslücken und manches durch Refactorings, die immer wieder verschoben wurden. Lässt man sie liegen, wird jede Änderung langsamer und riskanter. Das Board hat vier Spalten. Unter „Quellen der Schulden“ benennt das Team die konkreten Problemstellen: verworrene Module, duplizierten Code, fehlende Tests, veraltete Frameworks. „Auswirkungen und Risiken“ beschreibt, was diese Schulden für Lieferung, Qualität, Onboarding und Stimmung bedeuten. Unter „Priorisierung“ werden die Punkte nach Auswirkung, Aufwand und Wichtigkeit gereiht. Der „Maßnahmenplan“ macht aus den wichtigsten Punkten Arbeit mit Verantwortlichen, Zeitplänen und Check-ins, etwa einem festen Anteil jedes Sprints für den Schuldenabbau. Führt sie etwa einmal pro Quartal durch oder immer dann, wenn das Team merkt, dass Schulden es ausbremsen. So bleiben die Schulden sichtbar und klein.

Format der Retrospektive zu technischen Schulden

Quellen der Schulden

In welchen Bereichen der Codebasis haben sich technische Schulden angesammelt?

Bitte die Teilnehmenden, konkret zu benennen, um welche Art von Schulden es sich handelt und wo sie stecken: Code Smells, Architekturprobleme, fehlende Tests, veraltete Abhängigkeiten.

Auswirkungen und Risiken

Wie wirken sich diese technischen Schulden auf Team und Produkt aus?

Sprecht darüber, was die Schulden tatsächlich kosten: langsamere Lieferung, Bugs, die Kunden sehen, mühsames Onboarding, frustrierte Entwickler. Konkrete Kosten liefern die Argumente für den Abbau.

Priorisierung

Welche Schuldenbereiche sollten wir zuerst angehen?

Reiht die Schuldenpunkte nach Auswirkung, Aufwand und danach, wie stark sie andere Arbeit blockieren. Eine schnelle Matrix aus Nutzen und Aufwand hilft dem Team, sich zu einigen.

Maßnahmenplan

Wie bauen wir die priorisierten Schulden systematisch ab?

Erstellt einen konkreten Plan: Wer macht was bis wann, und wann prüft ihr den Fortschritt? Legt fest, wie viel Kapazität jedes Sprints in den Schuldenabbau fließt.

Wann sollte diese Retrospektive durchgeführt werden?

  • Wenn eure Codebasis mit jeder Änderung schwerer zu warten und zu erweitern ist.
  • Wenn das Team vor allem Brände löscht und neue Features wegen Instabilität immer wieder verschoben werden.
  • Wenn das Onboarding neuer Entwickler lange dauert, weil manche Bereiche verworren oder nicht dokumentiert sind.
  • Wenn Wartung und Bugfixes mehr Zeit beanspruchen als neue Arbeit.
  • Wenn Entwickler Sprint für Sprint von denselben Problemstellen frustriert sind.

Vorschläge für Fragen zum Icebreaker

  • Wenn unsere Codebasis ein Gebäude wäre, wie würde es aussehen und warum?
  • Was war deine lustigste oder schmerzhafteste Begegnung mit technischen Schulden?

Möchten Sie eine Aufwärmübung, bei der Ihr Team aktiv mitmacht, und nicht nur laut Antworten gibt? Kostenlose Icebreakers durchsuchen →

Ideen und Tipps für Ihre Retrospektive

  • Haltet die Diskussion frei von Schuldzuweisungen. Jede Codebasis baut Schulden auf, die Frage ist, was ihr jetzt dagegen tut.
  • Sorgt dafür, dass auch nicht-technische Teilnehmende verstehen, was technische Schulden sind und warum sie für die Lieferung wichtig sind.
  • Priorisiert Schulden nach Auswirkung, Aufwand und Wichtigkeit, statt alles auf einmal beheben zu wollen.
  • Versehrt den Plan mit Zeitplänen, Verantwortlichen und regelmäßigen Check-ins, damit er nicht ins Stocken gerät.
  • Reserviert einen festen Anteil jedes Sprints oder Zyklus für den Schuldenabbau.
  • Automatisiert Linting, Tests und Teile des Code-Reviews, damit weniger neue Schulden hinzukommen.

Häufig gestellte Fragen

Was ist eine Retrospektive zu technischen Schulden?
Ein fokussiertes Team-Meeting, um herauszufinden, wo sich technische Schulden angesammelt haben, zu besprechen, was sie kosten, festzulegen, was zuerst angegangen wird, und den Abbau zu planen.
Wann sollte man eine Retrospektive zu technischen Schulden durchführen?
Wenn ihr merkt, dass die Lieferung langsamer wird, Bugs immer wiederkehren oder sich Abkürzungen aus früheren Entscheidungen häufen. Viele Teams führen sie auch in einem festen Rhythmus durch, etwa einmal pro Quartal, zusätzlich zu ihren üblichen Sprint-Retrospektiven.
Wie priorisiert man technische Schulden in der Retrospektive?
Bewertet jeden Punkt nach Auswirkung, Aufwand und Wichtigkeit, statt alles auf einmal anzugehen. Macht dann aus den wichtigsten Punkten einen Maßnahmenplan mit Verantwortlichen und Zeitplänen.
Wer sollte an einer Retrospektive zu technischen Schulden teilnehmen?
Die Entwickler, die mit dem Code arbeiten, und der Product Owner oder wer sonst die Prioritäten festlegt. Ist die Person, die entscheidet, was gebaut wird, nicht dabei, bekommt der Plan selten Zeit im Sprint.
Wie viel Zeit sollten wir in den Abbau technischer Schulden investieren?
Eine allgemeingültige Zahl gibt es nicht. Viele Teams reservieren einen festen Anteil jedes Sprints. So läuft der Abbau stetig weiter, statt auf einen eigenen Aufräum-Sprint zu warten, der nie kommt.

Verwandte Vorlagen

Bug-Fixing-Retrospektive

Verstehen, warum Bugs entstehen, und ihre Wiederkehr verhindern

Produktentwicklungsprozess-Retrospektive

Tretet einen Schritt von den Sprints zurück und prüft, wie ihr Produkte entwickelt.

DevOps-Retrospektive

Deployments, Incidents und Übergaben zwischen Dev und Ops auswerten.

Code-Review-Retrospektive

Macht die Code Reviews eures Teams schneller und hilfreicher

Sind Sie bereit, diese Retrospektive durchzuführen?Probieren Sie diese Retrospektive live aus