4.7 3 Votes
Artikel-Rating

Sinn & Zweck der Definition of Done

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

  • (Kontinuierliche) Lieferung von Wert & Nutzen

  • Transparenz & Risikominimierung

Lieferung von Nutzen & Wert

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.

Definition of Done - Qualitätsanker

Transparenz & Risikominimierung

Zum anderen erhöht ein fertiges Increment 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.

Sicherung von Qualität

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.

The more efficient you are at doing the wrong thing, the wronger you become. It is much better to do the right thing wronger than the wrong thing righter. If you do the right thing wrong and correct it, you get better.

Russell L. AckoffRussell L. Ackoff, Wikipedia

Unterstützung bei der Aufwandsschätzung

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.

Beispiel für eine Definition of Done

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.

Definition of Done für cdi.digital

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

  • Der Blogartikel besitzt ein 1 (primäres) Keyword.

  • Die SEO-Ampel von Yoast ist grün.

  • Die Lesbarkeitsbewertung durch Yoast ist mindestens orange.

  • Es gibt keine bekannten Rechtschreib- oder Grammatikfehler.

  • Der Artikel ist einer (primären) Kategorie zugeordnet und besitzt mindestens 1 Schlagwort (Rubrik).

  • 3+ ältere Artikel verlinken auf den neuen Beitrag.

  • Der Artikel besitzt einen Meta-Text und einen Excerpt.

  • Es gibt ein Featured Image.

  • Im Artikel gibt es mindestens 1 Bild/500 Wörter.

Häufige Fragen zur Definition of Done

Es gibt einige, immer wiederkehrende Fragen zur Definition of Done. Deshalb habe ich hier einmal die häufigsten von ihnen zusammengestellt und kurz beantwortet.
0
Fehlen hier wichtige Fragen zur Definition of Done? Schreib mir gerne, wenn ich noch etwas ergänzen sollte!x

Wer bestimmt, was in der Definition of Done steht?

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.

Dürfen Teams, die am gleichen Produkt arbeiten, unterschiedliche Definitions of Done haben?

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”.)

Was passiert, wenn die Definition of Done geändert wird?

Wenn sich herausstellt, dass Eure aktuelle DoD nicht ausreicht, um ein hochqualitatives, nutzbares Increment 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.

Wann kann bzw. darf die Definition of Done geändert werden?

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.)

Was ist der Unterschied zwischen der DoD und einer DoR?

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.

Was ist der Unterschied zwischen der DoD und Akzeptanzkriterien?

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.

No-Go’s

Der Product Owner akzeptiert die User Story

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

  • Der Product Owner akzeptiert die User Story.

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.

Fazit zur Definition of Done

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.