Was ist die Definition of Done in agilen Teams?

Warum eine DoD

Ohne klare Definition gibt es Streit: Ist die Aufgabe fertig? Der Entwickler sagt ja, der Tester nein, der Product Owner will noch Dokumentation. Die DoD klärt das vorher. Alle wissen: fertig heißt diese 7 Kriterien sind erfüllt. Punkt. Verhindert versteckte Restarbeit, die später als Bug oder technische Schuld auftaucht.

Typische DoD-Kriterien

Code reviewed (mindestens 1 Reviewer). Unit-Tests geschrieben und grün. Integrations-Tests laufen. Dokumentation aktualisiert. Akzeptanz-Kriterien der User Story erfüllt. Deployment in Staging erfolgreich. Product Owner hat abgenommen. Diese 7 sind in Software-Teams Standard. In anderen Kontexten andere Kriterien.

DoD vs Akzeptanz-Kriterien

DoD ist generell für alle Stories des Teams. Akzeptanz-Kriterien sind spezifisch für jede einzelne Story. Beide ergänzen sich: Akzeptanz-Kriterien sagen, was die Funktion können muss. DoD sagt, welche Qualitäts-Standards für jede Funktion gelten. Beides muss erfüllt sein, sonst ist nicht fertig.

DoD pflegen

DoD ist nicht statisch. Bei jeder Retrospektive prüfen: Funktioniert die DoD? Brauchen wir neue Kriterien (z.B. Security-Check)? Können alte weg? Diese Pflege hält die DoD relevant. Klassischer Fehler: DoD bei Team-Gründung definieren und nie wieder anschauen. Folge: nach 2 Jahren passt sie nicht mehr zur Realität.