Viele Teams haben unterschiedliche Vorstellungen davon, wann eine Aufgabe wirklich abgeschlossen ist. Für die eine Person reicht funktionierender Code, für die nächste gehören Tests, Review, Dokumentation und Deployment dazu. Eine Definition of Done schafft einen gemeinsamen Mindeststandard.
Mit den häufigsten Unklarheiten beginnen
Eine Definition of Done sollte nicht theoretisch entstehen, sondern aus realen Problemen. Werden Tests oft vergessen? Fehlen Migrationshinweise? Bleiben Review-Kommentare offen? Genau solche wiederkehrenden Punkte gehören zuerst in den gemeinsamen Standard.
Klein starten
Ein Team braucht keine Liste mit dreißig Punkten. Fünf bis acht klare Kriterien reichen für den Anfang oft aus. Entscheidend ist, dass sie tatsächlich angewendet werden. Ein kurzer Standard, der gelebt wird, ist besser als ein perfektes Dokument, das niemand prüft.
Kriterien konkret formulieren
„Qualität geprüft“ ist zu vage. Besser sind überprüfbare Aussagen wie „erforderliche Reviews sind abgeschlossen“ oder „relevante automatisierte Tests laufen erfolgreich“. Jede Person im Team sollte dasselbe darunter verstehen.
Nicht jede Aufgabe braucht jedes Kriterium
Manche Punkte gelten nur, wenn sie relevant sind. Eine kleine Textänderung benötigt keine Datenbankmigration. Formulierungen wie „sofern erforderlich“ helfen, den Standard pragmatisch zu halten.
Akzeptanzkriterien getrennt halten
Die Definition of Done beschreibt allgemeine Qualitätsbedingungen. Ticket-spezifisches Verhalten gehört in die Akzeptanzkriterien. Diese Trennung verhindert, dass der allgemeine Standard mit Einzelfällen überladen wird.
Im Review nutzen
Die Definition of Done ist besonders hilfreich, wenn sie vor dem Abschluss eines Tickets kurz geprüft wird. Dadurch werden Diskussionen sachlicher: Es geht nicht um persönliche Erwartungen, sondern um einen gemeinsam vereinbarten Mindeststandard.
Regelmäßig anpassen
Ein Teamstandard darf sich weiterentwickeln. Wenn ein Kriterium ständig ignoriert wird, ist entweder der Prozess nicht sauber oder das Kriterium nicht sinnvoll. Beides sollte offen besprochen und angepasst werden.
Beispiel für einen einfachen Start
1. Akzeptanzkriterien erfüllt.
2. Code verständlich und integriert.
3. Relevante Tests erfolgreich.
4. Erforderliches Review abgeschlossen.
5. Dokumentation aktualisiert, sofern nötig.
6. Migration, Konfiguration und Betrieb berücksichtigt, sofern relevant.
7. Keine versteckten Restarbeiten.
Woran man eine gute Definition of Done erkennt
Sie ist kurz genug, um im Alltag verwendet zu werden, klar genug für eine gemeinsame Auslegung und konkret genug, dass vor dem Abschluss eines Tickets eine eindeutige Prüfung möglich ist.