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

„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 bedeutet 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 – am schlimmsten – technische Schulden, die euch Monate später das Genick brechen.

Die Definition of Done (DoD) ist dein wichtigstes Werkzeug, um dies klar 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.

Der entscheidende Unterschied: Akzeptanzkriterien vs. Definition of Done

Viele Teams werfen Akzeptanzkriterien (AC) und die DoD in einen Topf. Das ist ein strategischer Fehler.

Akzeptanzkriterien sind spezifisch für ein einzelnes Ticket. Sie beschreiben das Was (Beispiel: „Der User kann mit Kreditkarte zahlen.“). Der Product Owner nutzt sie, um zu prüfen, ob die fachliche Anforderung erfüllt ist.

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

Die Analogie: 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, die Brandschutzverordnung und die Elektrik. Der Käufer (PO) entscheidet über die Zimmer, aber du als Experte (Developer) entscheidest, dass das Haus nicht zusammenbricht.

Warum „Works on my Machine“ nicht zählt

In Scrum bedeutet „Done“, dass das Increment in einem Zustand ist, in dem es theoretisch sofort released werden könnte. Wenn Arbeit die DoD nicht erfüllt, nennt man das laut Scrum.org „Undone Work“. Das Problem: Undone Work ist ein verstecktes Risiko. Es erzeugt eine falsche Sicherheit über den Fortschritt. Wenn ihr am Ende des Sprints drei Tickets habt, die „fast fertig“ sind, aber die DoD nicht erfüllen, habt ihr null geliefert.

Ein Increment wird erst in dem Moment „geboren“, in dem das Ticket die DoD erfüllt. Alles andere ist nur ein Versprechen auf die Zukunft, das im nächsten Sprint als Zeitfresser wieder auftaucht.

Die Anatomie einer robusten DoD: Tests, Doku, CI/CD

Eine gute DoD ist kein Papiertiger im Wiki, sondern eine Checkliste, die ihr bei jedem Pull Request im Kopf (oder noch besser: in der Pipeline) habt. Eine gute DoD besteht meist aus diesen vier Säulen (die Spiegelstriche sind natürlich nur Beispiele).

Säule 1: Technische Qualität (Code-Ebene)

• Peer Review: Mindestens ein anderer Dev hat den Code gesehen und freigegeben.
• Static Analysis: Der Code erfüllt die Linting-Regeln und verstößt nicht gegen weitere automatisierte Code-Quality Tests.
• Kein Hardcoding: Secrets sind im Vault, Konfigurationen sind in der Umgebung hinterlegt.

Säule 2: Verifikation (Test-Ebene)

• 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 & Sichtbarkeit

• Code-Dokumentation: Komplexe Algorithmen sind im Code erklärt (nicht das „Was“, sondern das „Warum“).
• User-Doku/Readme: Wenn sich die Bedienung ändert, ist das README oder die API-Doku (Swagger/OpenAPI) aktuell.

Säule 4: Deployment & Infrastruktur

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

Wie man die DoD gegen Druck vom Management verteidigt

Hier wird es politisch. Früher oder später wird ein PO oder Manager sagen: „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?“

Deine Antwort als Developer: „Wir können das Feature morgen releasen, aber dann ist es offiziell 'Undone Work'. Wir verletzen unseren Qualitätsstandard und nehmen technische Schulden auf. Das bedeutet, wir müssen im nächsten Sprint Zeit einplanen, um diese Schulden zurückzuzahlen, sonst riskieren wir die Stabilität des gesamten Produkts.“

Die DoD 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 die DoD aufweicht, sinkt die Vorhersehbarkeit, und das Management verliert das Vertrauen in eure Lieferfähigkeit.

Praxis-Checkliste für Backend & Frontend Teams

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

Für Backend-Teams

• Code erfüllt Team-Coding-Standards (Linting).
• Alle Unit-Tests laufen lokal und in der CI erfolgreich durch.
• API-Änderungen sind in Swagger/OpenAPI dokumentiert.
• Neue Datenbank-Migrationen sind idempotent und getestet.
• Logging & Monitoring (Metriken) für neue Endpunkte implementiert.
• Peer Review durch mindestens einen Senior durchgeführt.
• Der Code ist im Versionierungssystem korrekt eingespielt.
• Korrekte Benutzerberechtigungen sind vergeben.

Für Frontend-Teams

• Feature funktioniert in den unterstützten Browsern.
• Responsives Design auf Mobile/Tablet geprüft.
• Barrierefreiheit (A11y): Grundlegende Screenreader-Kompatibilität geprüft.
• Bundle-Größe wurde nicht signifikant erhöht ohne triftigen Grund.
• E2E-Tests für den Happy Path sind grün.
• UI-Komponenten sind im Storybook (falls vorhanden) aktualisiert.
• Sinnvoller Beispielcontent ist angelegt.
• Übersetzungen sind getestet.

Tipp: DoD regelmäßig durchgehen

Bei uns im Team hat es sich bewehrt, die DoD regelmäßig durchzugehen. Wir schnappen uns aus unserer DoD jede Woche zwei Punkte und lesen diese laut vor. Wir überlegen dann, warum wir die Punkte in unserer DoD haben und ob sie noch für uns passt. Im Zweifel passen wir die Punkte an oder löschen sie auch mal. Auch neue Punkte können so entstehen. Die DoD ist für uns ein living document.

Fazit: Qualität ist kein „Add-on“

Eine Definition of Done zu haben ist einfach. Sie konsequent durchzuziehen, wenn die Hütte brennt, ist wahre Professionalität. Wenn ihr anfangt, die DoD ernst zu nehmen, werdet ihr am Anfang vielleicht langsamer, aber ihr werdet nie wieder von „Zombie-Bugs“ aus alten Sprints heimgesucht.

Wer bei der DoD schlampt, produziert keine Software, sondern technische Schulden. Und wie wir alle wissen: Die Zinsen dafür zahlt ihr im nächsten Sprint, nach Feierabend oder am Wochenende.

Schau als nächstes, was du noch im Entwickler Guide Agile für Entwickler für dich findest.