Was ist eigentlich ... Definition of Done (DoD)?

definition-of-done

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“. Wunderbar, alles „in time“ – doch am Ende des Sprints stellen Sie erstaunt fest, dass nur ein Teil der User Stories lieferbar ist. 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 sein:

  • Die Akzeptanzkriterien der User Story sind erfüllt
  • Alle Unit Tests sind erfolgreich abgeschlossen
  • Die Code-Konventionen werden eingehalten
  • 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 Entwicklungsgeschwindigkeit drastisch. In der Definition of Done müssen sich deshalb Qualitätsanspruch und Velocity (im Sinne des Product Owners) und Machbarkeit (im Sinne der Entwickler) 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 der Code nicht ganz so elegant wie es die Entwickler gerne hätten, 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!
 

 


Ü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 Entwicklerteam setzt die richtigen Prioritäten, um auch den betriebswirtschaftlichen Anforderungen des Projekts gerecht zu werden.


Sie haben noch keine Definition of Done? Wir bieten Workshops an, in denen wir gemeinsam mit Ihrem Team eine Checkliste mit Qualitätskriterien erarbeiten – melden Sie sich gerne bei uns!


„Modern Agile“ auf der Agile World Konferenz 2017
Design Thinking #2: Der Business-Beschleuniger