Definition of Done

Die Definition of Done (DoD) ist ein wesentliches Konzept in der agilen Softwareentwicklung und definiert einen gemeinsamen Standard, der festlegt, wann eine Arbeitseinheit tatsächlich als "fertig" betrachtet werden kann. Sie dient als Qualitätscheckliste und schafft ein gemeinsames Verständnis innerhalb des Teams und mit Stakeholdern über die erwartete Qualität der gelieferten Arbeit.

Bedeutung und Zielsetzung

Die Definition of Done erfüllt mehrere wichtige Funktionen in agilen Projekten:

• Qualitätssicherung: Sicherstellung eines einheitlichen Qualitätsstandards für alle Arbeitsergebnisse
• Transparenz: Klare Kommunikation darüber, was "fertig" tatsächlich bedeutet
• Planungssicherheit: Verlässliche Basis für Sprint- und Release-Planung
• Risikominimierung: Reduzierung technischer Schulden durch vollständige Fertigstellung
• Gemeinsames Verständnis: Vereinheitlichung der Erwartungen innerhalb des Teams und mit Stakeholdern
• Vermeidung von "Fast fertig": Beseitigung des verbreiteten Phänomens, dass Items als "95% fertig" bezeichnet werden

Ebenen der Definition of Done

Die Definition of Done kann auf verschiedenen Ebenen angewendet werden:

1. Story-Ebene

Definiert, wann eine einzelne User Story als abgeschlossen gilt. Typische Kriterien umfassen:

• Code wurde entsprechend der Coding Standards geschrieben
• Unit Tests wurden implementiert und bestanden
• Code Review wurde durchgeführt
• Alle Akzeptanzkriterien sind erfüllt
• Funktionale Tests wurden bestanden
• Dokumentation wurde aktualisiert

2. Feature-Ebene

Definiert, wann ein größeres Feature oder eine Epic als abgeschlossen gilt. Zusätzliche Kriterien könnten sein:

• Integrationstest-Szenarien wurden bestanden
• Nicht-funktionale Anforderungen wurden validiert
• Feature-spezifische Dokumentation wurde erstellt oder aktualisiert
• UX-Review wurde durchgeführt
• Performance-Tests wurden bestanden

3. Sprint-Ebene (Inkrement)

Definiert, wann das gesamte Sprint-Inkrement als abgeschlossen gilt. Zusätzliche Kriterien könnten sein:

• Alle Stories des Sprints erfüllen ihre individuellen DoD-Kriterien
• Integration aller Stories wurde getestet
• Build ist stabil und lauffähig
• Sprint Demo wurde vorbereitet
• Release Notes wurden erstellt

4. Release-Ebene

Definiert, wann ein Produkt releasefähig ist. Zusätzliche Kriterien könnten sein:

• End-to-End-Tests wurden bestanden
• Sicherheitsaudits wurden durchgeführt
• Benutzerdokumentation wurde aktualisiert
• Marketing-Materialien wurden vorbereitet
• Support-Team wurde geschult
• Releaseplan und Rollback-Strategie wurden definiert

Elemente einer guten Definition of Done

Eine effektive Definition of Done sollte folgende Aspekte abdecken:

1. Codequalität

• Einhaltung von Coding Standards und Best Practices
• Keine kritischen Bugs oder Code Smells
• Ausreichende Code-Kommentierung
• Erfolgreiche Code Reviews
• Einhaltung von Architektur- und Design-Prinzipien

2. Testing

• Unit Tests geschrieben und bestanden
• Integrationstests durchgeführt
• Akzeptanztests erfolgreich
• Manuelle Tests abgeschlossen
• Testabdeckung erfüllt definierte Schwellenwerte
• Regressionstests durchgeführt

3. Dokumentation

• Code-Dokumentation aktualisiert
• Technische Dokumentation ergänzt
• Benutzerdokumentation bei Bedarf angepasst
• API-Dokumentation aktualisiert
• Änderungen in Architektur- oder Design-Dokumenten reflektiert

4. Deployment und DevOps

• CI/CD-Pipeline erfolgreich durchlaufen
• Deployment-Skripte aktualisiert
• Konfigurationsmanagement durchgeführt
• Datenbankmigration definiert und getestet
• Monitoring und Alerting eingerichtet

5. Nicht-funktionale Anforderungen

• Performance-Kriterien erfüllt
• Sicherheitsanforderungen umgesetzt
• Skalierbarkeitsaspekte berücksichtigt
• Barrierefreiheitsrichtlinien eingehalten
• Internationalisierung und Lokalisierung implementiert

Entwicklung und Evolution der Definition of Done

Die Definition of Done ist kein statisches Dokument, sondern sollte sich mit dem Team und dem Produkt weiterentwickeln:

• Initiale Entwicklung: Zu Beginn eines Projekts oder bei der Einführung agiler Methoden wird eine erste Version erstellt
• Kontinuierliche Verfeinerung: Regelmäßige Überprüfung und Anpassung, oft im Rahmen von Sprint-Retrospektiven
• Schrittweise Erhöhung der Standards: Mit zunehmender Reife des Teams und des Produkts werden die Qualitätsanforderungen typischerweise erhöht
• Kontextbezogene Anpassungen: Berücksichtigung spezifischer Anforderungen für verschiedene Produktbereiche oder Entwicklungsphasen

Die Evolution der Definition of Done verläuft oft in Stufen:

1. Grundlegende Qualitätssicherung: Fokus auf funktionale Korrektheit und grundlegende Codequalität
2. Technische Exzellenz: Erhöhung der Standards für Testabdeckung, Refactoring und technische Dokumentation
3. Operationelle Reife: Integration von DevOps-Praktiken, Monitoring und Betriebsanforderungen
4. Geschäftliche Optimierung: Berücksichtigung von Benutzerakzeptanz, Marktfähigkeit und Geschäftswertmetriken

Definition of Done vs. Akzeptanzkriterien

Es ist wichtig, die Definition of Done von Akzeptanzkriterien zu unterscheiden:

Definition of Done	Akzeptanzkriterien
Allgemeingültig für alle Stories/Features	Spezifisch für eine einzelne Story/Feature
Fokus auf Qualitätsstandards und Prozesse	Fokus auf funktionale Anforderungen
Von Team definiert und angewendet	Vom Product Owner/Stakeholdern definiert
Ändert sich relativ selten	Wird für jede Story neu definiert
Prüft "Wurde es richtig gemacht?"	Prüft "Wurde das Richtige gemacht?"

Bei einer User Story müssen sowohl alle spezifischen Akzeptanzkriterien als auch alle Punkte der Definition of Done erfüllt sein, damit die Story als abgeschlossen gilt.

Definition of Done und technische Schulden

Die Definition of Done spielt eine entscheidende Rolle bei der Vermeidung technischer Schulden:

• Verhindert das Verschieben wichtiger Qualitätsaspekte auf "später"
• Macht transparent, wenn Abkürzungen genommen werden (müssen)
• Schafft eine Basis für konsistente Qualität über Zeit
• Reduziert das Risiko versteckter Probleme, die später teuer werden können

Wenn in Ausnahmefällen Abweichungen von der Definition of Done notwendig sind:

• Diese explizit dokumentieren und als technische Schuld erfassen
• Einen Plan zur Behebung erstellen und priorisieren
• Transparenz über die Abweichung gegenüber allen Beteiligten schaffen
• Die Häufigkeit solcher Ausnahmen als Metrik verfolgen

Definition of Done im Kontext verschiedener Rollen

Entwicklungsteam

• Hauptverantwortlich für die Erstellung und Einhaltung
• Nutzt die DoD als täglichen Qualitätsleitfaden
• Überprüft Arbeitsergebnisse gegen die DoD-Kriterien
• Schlägt Verbesserungen basierend auf Erfahrungen vor

Scrum Master

• Unterstützt bei der Erstellung und Verfeinerung
• Hilft dem Team, sie konsequent anzuwenden
• Beseitigt Hindernisse, die die Einhaltung erschweren
• Fördert Diskussionen über Qualitätsverbesserungen

Product Owner

• Stellt sicher, dass die DoD Kunden- und Geschäftsanforderungen abdeckt
• Berücksichtigt die DoD bei der Produktplanung und -priorisierung
• Kommuniziert die Qualitätsstandards an Stakeholder
• Akzeptiert nur Arbeit, die die DoD erfüllt

Management und Stakeholder

• Verständnis der DoD als Qualitätsgarantie
• Unterstützung bei der Bereitstellung notwendiger Ressourcen
• Berücksichtigung bei Budget- und Zeitplanung
• Nutzung als Transparenzinstrument

Best Practices für eine effektive Definition of Done

Bei der Erstellung

• Kollaborative Entwicklung: Einbeziehung aller Teammitglieder und relevanter Stakeholder
• Realistische Standards: Balance zwischen Anspruch und praktischer Umsetzbarkeit
• Klare Formulierung: Eindeutige, überprüfbare Kriterien ohne Interpretationsspielraum
• Visuelle Darstellung: Gut sichtbare Präsentation im Teamarbeitsbereich
• Formale Vereinbarung: Explizite Zustimmung aller Teammitglieder

Bei der Anwendung

• Konsequente Durchsetzung: Keine Ausnahmen ohne explizite Dokumentation
• Regular Reviews: Überprüfung nach jedem Sprint im Rahmen der Retrospektive
• Automatisierung: Wo möglich, Überprüfung durch automatisierte Tests und CI/CD
• DoD-Checklisten: Integration in den Arbeitsablauf, z.B. in Jira oder auf Kanban-Boards
• Reflexion: Regelmäßige Diskussion darüber, ob die DoD den aktuellen Qualitätsanforderungen entspricht

Herausforderungen und Lösungsansätze

Herausforderung: Zu ambitionierte Definition of Done

Lösungsansätze:

• Schrittweise Implementierung mit einer Basis-DoD und Erweiterungsplan
• Priorisierung der wichtigsten Qualitätsaspekte
• Regelmäßige Überprüfung der Praktikabilität
• Investition in Automatisierung zur Effizienzsteigerung

Herausforderung: Inkonsistente Anwendung

Lösungsansätze:

• Regelmäßige Erinnerungen und Reflexionen
• Peer Reviews mit DoD-Fokus
• Visualisierung des DoD-Status für jedes Backlog-Item
• Definition klarer Konsequenzen bei Nichteinhaltung

Herausforderung: Widerstand gegen hohe Qualitätsanforderungen

Lösungsansätze:

• Aufklärung über langfristige Kosten technischer Schulden
• Messung und Visualisierung der positiven Effekte hoher Qualität
• Anerkennung und Würdigung von Qualitätsbeiträgen
• Executive Sponsorship für Qualitätsinitiativen gewinnen

Beispiel einer umfassenden Definition of Done

Eine vollständige Definition of Done könnte folgende Elemente enthalten:

Codequalität:

• Code entspricht den vereinbarten Coding Standards
• Code ist in der Entwicklungssprache dokumentiert
• Code Review wurde durchgeführt und alle Anmerkungen wurden adressiert
• Keine kritischen Probleme in der statischen Codeanalyse
• Komplexitätsmetriken liegen unterhalb definierter Schwellenwerte

Testing:

• Unit Tests decken mindestens 80% des neuen/geänderten Codes ab
• Alle Tests (Unit, Integration, E2E) laufen erfolgreich
• Manuelle Tests der Funktionalität wurden durchgeführt
• Alle Akzeptanzkriterien wurden verifiziert
• Cross-Browser/Cross-Device-Tests wurden bei UI-Änderungen durchgeführt

Dokumentation:

• Architektur- und Design-Dokumentation wurde aktualisiert
• API-Dokumentation (wenn relevant) wurde erstellt/aktualisiert
• Release Notes wurden vorbereitet
• Betriebsdokumentation wurde aktualisiert
• Benutzerdokumentation wurde bei Bedarf angepasst

DevOps und Deployment:

• Feature wurde in der Staging-Umgebung getestet
• CI/CD-Pipeline läuft ohne Fehler durch
• Deployment- und Rollback-Anweisungen wurden aktualisiert
• Monitoring und Alerting wurden konfiguriert
• Datenbankänderungen sind abwärtskompatibel

Nicht-funktionale Anforderungen:

• Performance-Tests zeigen keine Verschlechterung
• Sicherheitsrichtlinien wurden eingehalten
• Barrierefreiheitsanforderungen wurden berücksichtigt
• Internationalisierung und Lokalisierung wurden berücksichtigt
• Datenschutzanforderungen wurden umgesetzt

Business und Stakeholder:

• Product Owner hat die Implementierung abgenommen
• Demo für relevante Stakeholder wurde durchgeführt
• Marketingmaterialien wurden bei Bedarf aktualisiert
• Support-Team wurde informiert/geschult
• Geschäftliche KPIs für Erfolgsmessung wurden definiert

Die Definition of Done ist ein lebendiges Dokument und ein zentraler Bestandteil agiler Qualitätssicherung. Sie unterstützt Teams dabei, konsistente, hochwertige Arbeitsergebnisse zu liefern und schafft Transparenz und Vertrauen zwischen allen Beteiligten. Durch die klare Definition von "fertig" werden Missverständnisse vermieden, technische Schulden reduziert und die langfristige Produktqualität gesichert.