Scrum-Leitfaden · Artefakte und Praktiken
Technische Schulden in Scrum: erkennen und managen
Technische Schulden sind die künftigen Kosten heutiger Abkürzungen: übereilter Code, fehlende Tests, veraltete Tools. Wie finanzielle Schulden können sie in Maßen nützlich sein, doch unkontrolliert bremsen sie jeden Sprint.
Das Wichtigste in Kürze
- Technische Schulden sind die künftigen Kosten heutiger Abkürzungen.
- Machen Sie sie im Product Backlog sichtbar.
- Verhindern Sie neue Schulden mit einer strengen Definition of Done.
Woher sie kommen
- Termindruck, der zu Abkürzungen führt.
- Eine schwache Definition of Done.
- Fehlende automatisierte Tests.
- Veraltete Bibliotheken und Infrastruktur.
- Wissen, das nur eine Person hat.
- Anforderungen, die sich nach Fertigstellung des Designs geändert haben.
Anzeichen wachsender Schulden
- Sinkend oder schwankend Velocity.
- Mehr Fehler, die bis zu den Nutzern durchrutschen.
- Einfache Änderungen dauern länger.
- Developers scheuen sich, bestimmte Bereiche anzufassen.
Umgang damit in Scrum
- Machen Sie sie sichtbar: Nehmen Sie Schulden-Einträge mit einer klaren Beschreibung der Kosten ins Product Backlog auf.
- Verschärfen Sie die Definition of Done , damit keine neuen Schulden entstehen.
- Kapazität reservieren in jedem Sprint, zum Beispiel einen Anteil der Teamarbeit, für den Abbau von Schulden.
- Refaktorieren Sie kontinuierlich als Teil der normalen Arbeit.
- Besprechen Sie sie im Sprint Review , damit die Stakeholder den Zielkonflikt verstehen.
Schulden gegenüber Stakeholdern erklären
Formulieren Sie Schulden in geschäftlichen Begriffen: „Änderungen in diesem Bereich dauern dreimal so lange und verursachen die meisten unserer Produktionsstörungen. Eine Investition von zwei Sprints würde alle künftigen Arbeiten hier beschleunigen.“
Kostenlose Vorlagen zu diesem Thema
Häufig gestellte Fragen
Wer entscheidet, wann technische Schulden abgebaut werden?
Der Product Owner ordnet das Backlog, informiert durch die Developers, die die Kosten der Schulden erläutern.
Sind alle technischen Schulden schlecht?
Nein. Bewusst eingegangene, kurzfristige Schulden, um schnell zu lernen, können sinnvoll sein, solange sie erfasst und zurückgezahlt werden.
Was sind technische Schulden?
Die künftigen Kosten dafür, jetzt eine schnelle oder einfache Lösung statt einer besseren zu wählen. Sie zeigen sich in langsameren Änderungen, mehr Fehlern und riskanteren Releases.
Wer hat den Begriff technische Schulden geprägt?
Ward Cunningham führte die Schulden-Metapher 1992 ein, um geschäftlichen Stakeholdern zu erklären, warum Refactoring nötig war.
Wie misst man technische Schulden?
Es gibt keine einheitliche Kennzahl. Teams nutzen Anzeichen wie die Zeit für einfache Änderungen, Fehlerraten, Codeanalyse-Tools und den Umfang der Schulden-Einträge im Product Backlog.
Gehören technische Schulden ins Product Backlog?
Ja. Werden Schulden als Product-Backlog-Einträge sichtbar gemacht, kann der Product Owner sie gegen neue Features abwägen.
Wie viel Zeit sollte ein Scrum Team für technische Schulden aufwenden?
Dafür gibt es keine Regel. Viele Teams reservieren dafür einen Teil der Kapazität jedes Sprints und passen ihn daran an, wie stark die Schulden sie bremsen.
Wie verhindert die Definition of Done technische Schulden?
Eine strenge Definition of Done, einschließlich Tests, Code-Review und Dokumentation, verhindert, dass Abkürzungen Teil des Inkrements werden.
Wie verringert Refactoring technische Schulden?
Refactoring verbessert die interne Struktur des Codes, ohne sein Verhalten zu ändern. Regelmäßig durchgeführt, verhindert es, dass sich technische Schulden anhäufen.
Sind technische Schulden nur ein Softwareproblem?
Der Begriff stammt aus der Softwareentwicklung, doch ähnliche Schulden gibt es auch anderswo, etwa veraltete Prozesse, undokumentiertes Wissen oder schnelle Notlösungen bei Inhalten und Daten.
Wie überzeugen Sie Stakeholder, technische Schulden abzubauen?
Erklären Sie sie in geschäftlichen Begriffen, etwa wie viel langsamer Änderungen werden oder wie viele Störungen sie verursachen, und zeigen Sie den erwarteten Nutzen ihrer Behebung im Sprint Review.