Definition von „Fertig“-Vorlagen

Was ist eine Definition of Done (DoD)-Vorlage?

Eine Definition of Done (DoD)-Vorlage ist eine umfassende Checkliste technischer und funktionaler Kriterien, die eine User Story oder Aufgabe erfüllen muss, bevor sie als „abgeschlossen“ gilt. Im Gegensatz zu den „Akzeptanzkriterien“ (die für jede User Story individuell sind) ist die DoD ein globaler Standard, der auf jede Arbeit angewendet wird. Sie verhindert „technische Schulden“, indem sie sicherstellt, dass Tests, Dokumentation und Compliance niemals der Geschwindigkeit zuliebe übersprungen werden.

Der „Qualitäts“-Audit: 3 Wege, um „lieferfähige“ Standards durchzusetzen

Eine DoD ist nur so gut wie die Disziplin deines Teams. Bevor du deine Vorlage abschließt, wende diese drei fachlichen „Health-Checks“ an:

1. Audit „Unvollendete Arbeit“

Das Audit: Verschiebst du Stories auf "Done", während du die Dokumentation oder Integrationstests auf den "nächsten Sprint" verschiebst? Die Lösung: Prüfe auf aufgeschobene Qualität. Ein professionelles DoD muss Regressionstests und Aktualisierungen der Dokumentation enthalten. Wenn es nicht dokumentiert ist und nicht am gesamten System getestet wurde, ist es nicht "Done"; es ist nur "Developed". Deine Vorlage sollte explizit "Keine neuen technischen Schulden" als Anforderung aufführen.

2. Der "Automated Truth"-Test

Das Audit: Beruht deine DoD auf "menschlichen Versprechen" (z. B. "Ich habe den Code geprüft")? Die Abhilfe: Prüfe auf Binäre Überprüfung. Wann immer möglich, ersetze manuelle Prüfungen durch automatisierte. Statt "Code is reviewed," verwende "Pull Request von 2 Reviewern genehmigt." Statt "Unit tested," verwende "Unit-Test-Abdeckung > 80%." Das entfernt Subjektivität und stellt sicher, dass der "Done"-Zustand messbar und unumstritten ist.

3. Der "Global vs. Local"-Konflikt

The Audit: Ist euer DoD so lang, dass das Team die Hälfte davon ignoriert, um das Sprintziel zu erreichen? The Fix: Prüft auf Realität. Beginnt mit einem "Minimum Viable DoD" und erweitert ihn, während das Team reift. Wenn das Team nicht realistisch in jedem Sprint ein vollständiges Sicherheitsaudit durchführen kann, setzt es das nicht ins Story-Level-DoD. Verschiebt es stattdessen in eine "Definition of Release". So bleibt das tägliche DoD erreichbar und wird respektiert.

Strategische Frameworks: Die drei Ebenen von "Done"

Eine professionelle Organisation verwendet oft drei unterschiedliche Vorlagen, um verschiedene Fertigstellungsphasen zu verwalten:

• Stufe 1: Die User Story-DoD (Sprint-Stufe)

  • Fokus: Codequalität, Peer-Review und das Erfüllen spezifischer Akzeptanzkriterien.

  • Beispiel: "Unit-Tests bestanden," "PO genehmigt," "Funktionale Tests bestanden."

• Stufe 2: Die Sprint/Feature-DoD (Integrations-Stufe)

  • Fokus: Wie das Feature mit dem Rest der App interagiert.

  • Beispiel: "Keine Regressionsfehler," "Leistungskennzahlen stabil," "Staging-Umgebung aktualisiert."

• Stufe 3: Die Release-DoD (Markt-Stufe)

  • Fokus: Rechtliche, Marketing- und Sicherheits-Compliance.

  • Beispiel: "Penetrationstest bestanden," "Übersetzung abgeschlossen," "Benutzerhandbuch aktualisiert."

Schlüsselelemente einer Definition of Done-Vorlage

Für ein leistungsfähiges DoD sind diese fünf Kernkategorien erforderlich:

• Development Standards: Der Code ist kommentiert, refaktoriert und in den Main-Branch eingecheckt.

• Testing & Quality: Unit-, Integration- und manuelle "smoke tests" sind abgeschlossen und bestanden.

• Environment & DevOps: Der Code ist in einer Staging-Umgebung bereitgestellt und besteht die Build-Pipeline.

• Review & Approval: Die Peer Review ist abgeschlossen und der Product Owner (PO) hat die Funktionalität freigegeben.

• Non-Functional Requirements: Das Feature erfüllt spezifische Vorgaben zu Geschwindigkeit, Barrierefreiheit und Sicherheit.