Vorlagen für die Definition von „Fertig“

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 „Fertig“ 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 nie zugunsten von Geschwindigkeit übersprungen werden.

Das „Quality“-Audit: 3 Wege, „lieferbare“ Standards durchzusetzen

Eine DoD ist nur so gut wie die Disziplin des Teams. Bevor du deine Vorlage abschließt, wende diese drei fachlichen Prüfungen an:

1. Das „Undone Work“-Audit

Die Prüfung: Verschiebst du Stories auf „Done“, während Dokumentation oder Integrationstests auf den „nächsten Sprint“ verschoben werden? Die Lösung: Prüfe auf Aufgeschobene Qualität. Eine professionelle DoD-Vorlage muss Regressionstests und eine Aktualisierung der Dokumentation enthalten. Wenn etwas nicht dokumentiert und nicht im Gesamtsystem getestet ist, ist es nicht „Done“; es ist nur „Entwickelt“. Deine Vorlage sollte ausdrücklich „Keine neue technische Schuld“ als Anforderung aufführen.

2. Der Test „Automatisierte Wahrheit“

Die Überprüfung: Basiert eure DoD auf "menschlichen Versprechen" (z. B. "Ich habe den Code geprüft")? Die Lösung: Prüft auf Binäre Verifikation. Wann immer möglich, ersetzt manuelle Prüfungen durch automatisierte. Statt "Code is reviewed," verwendet "Pull Request approved by 2 peers." Statt "Unit tested," verwendet "Unit-Test-Abdeckung > 80%." Das entfernt Subjektivität und stellt sicher, dass der "Done"-Status messbar und unumstritten ist.

3. Der "Global vs. Local"-Konflikt

Die Prüfung: Ist deine DoD so lang, dass das Team die Hälfte davon ignoriert, um das Sprintziel zu erreichen? Die Lösung: Prüfe auf Realität. Beginne mit einer "Minimum Viable DoD" und erweitere sie, während das Team reift. Wenn das Team realistischerweise nicht bei jedem Sprint ein vollständiges Sicherheits-Audit durchführen kann, nimm es nicht in die DoD auf Story-Ebene auf. Verschiebe es stattdessen in eine "Definition of Release". So bleibt die tägliche DoD erreichbar und respektiert.

Strategische Frameworks: Die drei Ebenen von "Done"

Eine professionelle Organisation nutzt oft drei unterschiedliche Vorlagen, um verschiedene Fertigstellungsstufen zu verwalten:

• Level 1: Die User Story-DoD (Sprint-Ebene)

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

  • Beispiel: „Unit-Tests bestanden“, „PO genehmigt“, „Funktionstests bestanden“.

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

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

  • Beispiel: „Keine Regressionsfehler“, „Performance-Kennzahlen stabil“, „Staging-Umgebung aktualisiert“.

• Level 3: Die Release-DoD (Markt-Ebene)

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

  • Beispiel: „Penetrationstest bestanden“, „Übersetzung abgeschlossen“, „Bedienungsanleitung aktualisiert“.

Zentrale Bestandteile einer Definition-of-Done-Vorlage

Eine leistungsfähige DoD erfordert diese fünf Kernkategorien:

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

• Testing & Quality: Unit-, Integrations- und manuelle „Smoke-Tests“ sind abgeschlossen und bestanden.

• Environment & DevOps: Der Code wurde in eine Staging-Umgebung bereitgestellt und durchläuft die Build-Pipeline erfolgreich.

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

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