Kennen Sie die Situation: In Meetings erhalten Sie vom Team Aussagen wie „Dieser Task ist so gut wie erledigt“ oder „Die User Story ist eigentlich fast fertig“. Das Problem: Ob ein Inkrement fertig ist, wird von verschiedenen Personen sehr unterschiedlich definiert und interpretiert. Woher wissen Sie also, wann eine Aufgabe wirklich abgeschlossen ist? Was erwarten Kollegen oder der Product Owner? Um langwierige Diskussionen und unliebsame Überraschungen zu vermeiden, gibt es in agilen Teams das Artefakt „Definition of Done“ oder kurz „DoD“.
Definition of Done – eine Teamvereinbarung
Die Definition of Done ist eine verbindliche Aufstellung von Kriterien, die ein Produkt erfüllen muss, um als „done“ zu gelten. Die Vereinbarung verschwindet nicht in den Schubladen, sondern hängt als Checkliste gut sichtbar für alle im Teamraum, am besten in unmittelbarer Nähe des Taskboards. Wichtig: Die Definition of Done wird nicht von oben vorgegeben, sondern vom Team selbst erarbeitet, am besten im Rahmen eines moderierten Workshops.
Mögliche Kriterien können beispielsweise sein:
- Die Akzeptanzkriterien der User Story sind erfüllt
- Alle Tests sind erfolgreich abgeschlossen
- Die Dokumentation wurde erweitert
- Die User Story wurde vom Product Owner abgenommen
Wo liegen die Stolpersteine der Definition of Done?
Hört sich logisch an. Reicht dafür nicht der gesunde Menschenverstand, sondern braucht man wirklich eine schriftliche Vereinbarung? Ja. Denn was sich auf den ersten Blick simpel liest, ist in der täglichen Praxis etwas komplizierter. Nur Stories, die die DoD erfüllen, zählen zur Sprint-Velocity. Verliert sich das Team in zu hohen, unerreichbaren Kritierien, sinkt die Geschwindigkeit der Produktentwicklung drastisch. In der Definition of Done müssen sich deshalb Qualitätsanspruch und Velocity (im Sinne des Product Owners) und Machbarkeit (im Sinne des Teams) die Waage halten. Ziel ist es, im Rahmen der Deadline das Beste für den Kunden herauszuholen und am Ende der Sprints ein Inkrement liefern zu können. Nicht mehr aber auch nicht weniger.
Beim Formulieren der Definition of Done ist die Sichtweise des Kunden ein Gesichtspunkt, der häufig nicht ausreichend berücksichtigt wird. Es kann betriebswirtschaftlich durchaus sinnvoll sein, ein Inkrement mit kleinen „technischen Schulden“ auszuliefern. Vielleicht ist das Produkt nicht so perfekt, wie es das Team gerne hätte, aber Time to Market rechtfertigt eine schnelle Lösung, die später optimiert wird. Die Grenze hier festzulegen, ist schwierig. Umgeht das Team zu häufig Qualitätsstandards, schlagen sich die nachträglichen Optimierungen auf die Geschwindigkeit in nachfolgenden Sprints nieder – überlegen Sie gemeinsam mit dem Product Owner genau, welche Grauzone für das Projekt akzeptabel ist.
Tipp: Überprüfen Sie Ihre DoD periodisch! Definition of Done ist keine statische Vereinbarung, sondern die Kriterienliste sollte die wachsende Erfahrung des Teams reflektieren.
Warum benötigen agile Teams eine Definition of Done?
Fakt ist, dass agile Teams (und das Projekt) von einer Definition of Done enorm profitieren. Die wichtigsten drei Gründe für das Arbeiten mit DoD sind:
Gemeinsames Qualitätsverständnis
Diskussionen und unterschiedliche Interpretationen von „fertig“ werden vermieden. Alle im Team wissen, was bis zum Ende des Sprints zu tun ist, um Aufgaben abzuschließen.
Mehr Planungssicherheit
Es gibt keine unkalkulierbaren Altlasten von vermeintlich „fast“ erledigten User Stories aus dem letzten Sprint.
Bessere Kundenorientierung
Das Team setzt die richtigen Prioritäten, um auch den betriebswirtschaftlichen Anforderungen des Projekts gerecht zu werden.
Sie haben noch keine Definition of Done? Gerne erarbeiten wir in einem Workshop mit Ihrem Team eine individuelle Checkliste mit Qualitätskriterien. Die Definition of Done ist außerdem Teil unserer Schulung „Anforderungsmanagement 4.0“.
Beitrag teilen
