Definition of Done Praxis-Guide: Wann ist Code wirklich fertig?

Thomas 23 Dezember 2025

Survival-Kit für Entwickler Teil 3 von 8 Zur Übersicht

„Ist das Ticket fertig?“ „Ja, ich muss es nur noch kurz deployen und die Tests fixen.“

Ehrlich: Dann ist es nicht fertig.

In der Softwareentwicklung ist „fertig“ einer der dehnbarsten Begriffe überhaupt. Für den einen heißt es „der Code kompiliert auf meinem Rechner“, für den anderen „es läuft skaliert in der Cloud und die Dokumentation ist aktuell“. Wenn diese Definitionen im Team auseinanderdriften, entstehen Reibungsverluste, Bugs und technische Schulden, die euch Monate später das Genick brechen.

Die Definition of Done ist dein wichtigstes Werkzeug, um das für alle im Team festzuhalten. Laut Scrum Guide 2020 ist sie nicht nur eine Liste, sondern ein Commitment zur Qualität. Sie ist der Moment, in dem aus ein bisschen Code ein echtes Increment wird.

Akzeptanzkriterien und Definition of Done sind zwei Dinge

Viele Teams werfen beides in einen Topf. Das ist ein strategischer Fehler.

Akzeptanzkriterien sind spezifisch für ein einzelnes Ticket. Sie beschreiben das Was: „Der User kann mit Kreditkarte zahlen.“ Der Product Owner prüft damit, ob die fachliche Anforderung erfüllt ist.

Die Definition of Done ist der Qualitätsstandard für jedes Ticket. Sie beschreibt das Wie: „Dokumentation ist erfolgt, keine kritischen Security-Vulnerabilities, Peer Review erfolgt.“

Wenn du ein Haus baust, sind die Akzeptanzkriterien die Farbe der Wände und die Anzahl der Zimmer. Die Definition of Done ist die Statik, der Brandschutz und die Elektrik. Der Käufer entscheidet über die Zimmer. Du als Experte entscheidest, dass das Haus nicht zusammenbricht.

Warum „Works on my Machine“ nicht zählt

In Scrum heißt „Done“, dass das Increment sofort released werden könnte. Was die Definition of Done nicht erfüllt, ist Undone Work, und Undone Work ist ein verstecktes Risiko. Es erzeugt falsche Sicherheit über den Fortschritt. Wenn ihr am Sprintende drei Tickets habt, die fast fertig sind, habt ihr null geliefert.

Ein Inkrement entsteht in dem Moment, in dem das Ticket die Definition of Done erfüllt. Alles andere ist ein Versprechen auf die Zukunft, das im nächsten Sprint als Zeitfresser wieder auftaucht.

Die Anatomie einer robusten Definition of Done

Eine gute Definition of Done ist kein Papiertiger im Confluence, sondern eine Checkliste, die ihr bei jedem Pull Request im Kopf habt. Vier Säulen, die Punkte darunter sind Beispiele.

Säule 1: Technische Qualität

Peer Review: Mindestens ein anderer Dev hat den Code gesehen und freigegeben.
Static Analysis: Der Code erfüllt die Linting-Regeln und die automatisierten Code-Quality-Tests.
Kein Hardcoding: Secrets sind im Vault, Konfigurationen in der Umgebung.

Säule 2: Verifikation

Unit Tests: Neue Logik ist durch automatisierte Tests abgedeckt.
Integration Tests: Die Schnittstellen zu anderen Modulen funktionieren.
Regression: Die bestehende Funktionalität wurde nicht zerschossen.

Säule 3: Dokumentation und Sichtbarkeit

Code-Dokumentation: Komplexe Algorithmen sind erklärt, und zwar das Warum, nicht das Was.
Readme und API-Doku: Wenn sich die Bedienung ändert, ist Swagger oder OpenAPI aktuell.

Säule 4: Deployment und Infrastruktur

Build: Der Code baut sauber in der CI/CD-Umgebung.
Umgebung: Das Feature ist auf Staging oder Test deployt.

Wie du die Definition of Done gegen Druck verteidigst

Hier wird es politisch. Früher oder später sagt ein PO oder Manager: „Wir haben keine Zeit für die kompletten Tests, wir müssen morgen live gehen. Können wir die DoD für dieses eine Mal ignorieren?“

Die Definition of Done ist dein Schutzschild. Sie erlaubt dir, nein zu sagen, ohne unkooperativ zu wirken. Du sagst nicht nein zum Feature. Du sagst nein zum Verzicht auf Professionalität. Wenn das Team sie aufweicht, sinkt die Vorhersehbarkeit, und dann verliert das Management erst richtig das Vertrauen in eure Lieferfähigkeit.

Pro-Talk

Qualität verteidigen, wenn „schnell“ wichtiger sein soll als „gut“

Jemand sagt...	Deine Antwort als Profi-Dev
„Können wir die Tests diesmal nicht weglassen? Wir müssen morgen live gehen.“	„Wir können das Feature liefern, aber dann verletzen wir unsere DoD. Damit bauen wir bewusst technische Schulden auf, für die wir im nächsten Sprint mit Zins und Zinseszins bezahlen. Wer übernimmt die Verantwortung für die Instabilität?“
„Warum ist das Ticket noch nicht Done? Du hast den Code doch fertig getippt.“	„Tippen ist nur die halbe Arbeit. Gemäß DoD fehlen noch das Peer-Review und der Security-Scan. Ohne diese Schritte ist das Risiko für einen Produktionsfehler zu hoch. 'Done' heißt bei uns: sicher und verlässlich.“
„Die Dokumentation können wir doch auch nach dem Release machen.“	„Erfahrungsgemäß passiert das nie. Undokumentierter Code ist technisches Risiko. Wir machen die Arbeit jetzt einmal richtig fertig, damit der nächste, der dran arbeitet (vielleicht ich selbst in 3 Monaten), nicht raten muss.“

Praxis-Checkliste für Backend und Frontend

Damit ihr nicht bei null anfangen müsst, hier ein Vorschlag für eine pragmatische Definition of Done, die ihr direkt in Jira oder in eure PR-Templates kopieren könnt.

Für Backend-Teams

Code erfüllt die Team-Coding-Standards (Linting).
Alle Unit-Tests laufen lokal und in der CI durch.
API-Änderungen sind in Swagger oder OpenAPI dokumentiert.
Neue Datenbank-Migrationen sind idempotent und getestet.
Logging und Monitoring für neue Endpunkte sind implementiert.
Peer Review durch mindestens einen Senior ist erfolgt.
Der Code ist im Versionierungssystem korrekt eingespielt.
Die Benutzerberechtigungen sind korrekt vergeben.
Boy Scout Rule: Code sauberer verlassen als vorgefunden.

Für Frontend-Teams

Feature funktioniert in den unterstützten Browsern.
Responsives Design auf Mobile und Tablet geprüft.
Barrierefreiheit: grundlegende Screenreader-Kompatibilität geprüft.
Bundle-Größe nicht ohne triftigen Grund gewachsen.
E2E-Tests für den Happy Path sind grün.
UI-Komponenten im Storybook aktualisiert, falls vorhanden.
Sinnvoller Beispielcontent ist angelegt.
Übersetzungen sind getestet.

Geh die Definition of Done regelmäßig durch

Bei uns im Team hat sich ein kleines Ritual bewährt. Wir nehmen jede Woche zwei Punkte aus unserer Definition of Done und lesen sie laut vor. Dann überlegen wir, warum der Punkt drinsteht und ob er noch passt. Im Zweifel passen wir ihn an oder löschen ihn. So entstehen auch neue. Die Definition of Done ist bei uns ein living document.

Qualität ist kein Add-on

Eine Definition of Done zu haben ist einfach. Sie durchzuziehen, wenn die Hütte brennt, ist Professionalität. Am Anfang werdet ihr langsamer. Dafür holt euch nie wieder ein Zombie-Bug aus einem alten Sprint ein.

Nimm dir für diese Woche einen einzigen Punkt vor: Lies in eurer Definition of Done nach, ob überhaupt drinsteht, was ihr tatsächlich tut. Wenn nicht, ist das euer erstes Retro-Thema.

Weiter im Survival-Kit

Teil 4Backlog Refinement: Tickets schneiden wie ein Pro ÜbersichtAlle acht Teile im Agile-Survival-Kit

Falls du hier gerade nickst: genau solche Sachen nehme ich mir in NBA Kompakt vor – ein Thema pro Folge, fünf bis zehn Minuten, jede Woche. Wenn du das im Ohr statt im Feed willst: hier abonnieren.