Die Definition of Done

Die Definition of Done (kurz: DoD) ist neben dem Produktziel und dem Sprintziel eines der drei Scrum Commitments. Eines der wichtigsten Prinzipien von Scrum ist die Fertigstellung eines nutzbaren Inkrements am Ende eines jeden Sprints. Deshalb liefert die DoD jedem Teammitglied eine klare Definition davon, wann etwas fertig ist (und wann nicht). Dadurch fördert sie ein gemeinsames Verständnis von fertig in Deinem gesamten Scrum Team.

Die Definition of Done sorgt dafür, dass das Euer Inkrement (Produkt) seinen Zweck erfüllen kann. Dieser besteht vor allem in zwei Dingen:

Inkrementelles Arbeiten dient zum einen dazu, regelmäßig neuen Wert beziehungsweise Nutzen für Kunden zu stiften. Am Ende eines jeden Sprints, soll Euer Produkt für Kunden und Nutzer eine Verbesserung beinhalten, die es für Eure Zielgruppe wertvoller macht.

Wirklichen Nutzen stiftet jedoch nur das, was (wirklich) fertig ist.

Zum anderen erhöht ein fertiges Inkrement die Transparenz über seinen eigenen, aktuellen Zustand. Gerade in der Softwareentwicklung (wo Scrum ja seinen Ursprung hat) trugen in der Vergangenheit lange Entwicklungszyklen dazu bei, dass man erst am Ende eines mehrmonatigen Projektes bemerkte, was alles nicht funktionierte. Die Folge waren aufwändige Nacharbeiten oder sogar das komplette Scheitern eines Vorhabens.

Die Nutzbarkeit des Produktes dient also nicht nur dazu, neuen Wert für Kunden zu stiften, sondern hilft auch dabei, unerwünschte Abweichungen, Fehler und Probleme so früh wie möglich zu erkennen.

Die Definition of Done ist deshalb ein Qualitätsanker. Sie stellt sicher, dass das Ergebnis Eurer Arbeit immer nutzbar ist und funktioniert.

Das Prinzip, mit dessen Hilfe Scrum in der Produktentwicklung eine hohe Geschwindigkeit erzeugt, ist also nicht schneller zu arbeiten, sondern permanent hohe Qualität abzuliefern.

Darüber hinaus hilft Euch die DoD dabei, den Aufwand von User Stories (und anderen Aufgaben) zu schätzen. Denn nur dann, wenn Ihr wisst, wann eine Aufgabe (wirklich) von allen Beteiligten als fertig betrachtet wird, könnt Ihr bemessen, wieviel Aufwand es sein wird, sie zu erledigen.

Vielleicht fragst Du Dich gerade, was denn nun genau in einer DoD steht. Deshalb hab ich Dir hier einmal ein kleines Beispiel mitgebracht. Dabei habe ich ganz bewusst kein Beispiel aus der Softwareentwicklung genommen, um Dir zu zeigen, dass sie auch für einen normalen Webseiten-Blog sinnvoll ist.

Jeder Blogartikel (und sinngemäß jede andere Seite auf cdi.digital) muss folgende Punkte erfüllen:

Euer Scrum Team einigt sich gemeinsam auf die Definition of Done. Das bedeutet, dass bei ihrer Erstellung sowohl Product Owner als auch Scrum Master als auch Entwickler beteiligt sind.

Allerdings müsst Ihr darauf achten, dass Eure DoD eventuell vorhandenen Qualitätsrichtlinieren Eurer Organisation entspricht. Diese Vorgaben sind sozusagen Eure Minimalbedingungen.

Jein. Falls mehrere Scrum Teams an ein und dem gleichen Produkt arbeiten, gilt für jedes dieser Teams grundsätzlich die gleiche Definition of Done wie für alle anderen Scrum Teams. Darüber hinaus ist es jedem einzelnen Scrum Team jedoch möglich, sich auf eine schärfere oder härtere DoD zu committen. (Abweichung ist also erlaubt, jedoch nur „nach oben“.)

Wenn sich herausstellt, dass Eure aktuelle DoD nicht ausreicht, um ein hochqualitatives, nutzbares Inkrement zu liefern, muss diese von Euch entsprechend angepasst bzw. erweitert werden.

Alle vorherigen Inkremente, die Euer Scrum Team bisher abgeliefert hat, werden dadurch (potenziell) unfertig (undone).

Das Resultat einer solchen Aktualisierung sind damit Nacharbeiten an allen bisherigen Auslieferungen. Eventuell entstehen durch Eure neue DoD sogar (explizit gemachte) technische Schulden.

Der formale Ort, an dem ein Scrum Team seine DoD inspiziert und eventuelle Anpassungen daran vornimmt, ist die Sprint Retrospektive.

Das ergibt auch durchaus Sinn, denn wenn Ihr in Eurer Retrospektive feststellt, warum bestimmte Fehler und Probleme im Produkt aufgetreten sind, ist Eure Definition of Done genau das Werkzeug, mit dem Ihr derartige Probleme in Zukunft vermeiden könnt. (Grundsätzlich ist eine Überarbeitung jedoch jederzeit möglich und nicht auf die Retrospektive begrenzt.)

Manche Teams nutzen neben der Definition of Done auch eine sogenannte Definition of Ready. Im Gegensatz zur DoD soll letztere für möglichst viel Klarheit während des Sprints sorgen. Allerdings ist die DoR kein fester Bestandteil des Scrum Frameworks, sondern lediglich eine recht weit verbreitete Praxis.

Auch der Unterschied zwischen der Definition of Done und Akzeptanzkriterien ist häufig nicht auf den ersten Blick klar. Der Hauptunterschied besteht darin, dass die DoD für alle Product Backlog Items gilt und Qualtität sicherstellen soll, während Akzeptanzkriterien dazu dienen sollen, mehr Klarheit über ein einziges, konkretes Item zu erzeugen.

Genauso wie die Definition of Ready sind Akzeptanzkriterien ebenfalls nur eine weit verbreitete (und sehr nützliche) Praktik.

In einigen Blogartikeln (beispielsweise bei ScrumEvents.de) findest Du bei den Beispielen für eine gelungene Definition of Done folgenden Punkt:

Ich halte solche und ähnliche Punkte in einer DoD für ein echtes NoGo. Erstens machen solche Einträge die Entwickler eines Scrum Teams vollkommen abhängig vom Product Owner, der (nach Gutdünken?) entscheiden kann, ob ein Backlog Item fertig ist oder nicht. Die Sprint Review gerät damit zu einem echten Abnahme-Meeting und nicht zu einem Workshop, in dem neue Ideen durch Feedback generiert werden.

Zweitens läuft in einem solchen Scrum Team etwas Grundsätzliches falsch, wenn ein Product Owner erst in der Sprint Review bemerkt, dass eine User Story nicht so umgesetzt wurde, wie er oder sie sich das vielleicht vorgestellt hat. In diesem Fall stimmt höchstwahrscheinlich etwas nicht mit dem gemeinsamen Backlog Refinement und oder dem Sprint Planning. Eventuell sind auch die Akzeptanzkriterien unklar oder sogar gar nicht vorhanden.

Die Definition of Done ist kein hübsches Beiwerk, um sich vorzunehmen, (nebenbei) auch hochwertige Produkt-Features auszuiefern, sondern ein zentraler Bestandteil des Scrum Frameworks, der für hohe Entwicklungsgeschwindigkeit sorgt. Denn gerade in der Softwareentwicklung sorgen schlechte Codequalität, Bugs, technische Schulden und dergleichen mehr für die größten Verzögerungen.