Die Scrum Definition of Done (DoD, mit Beispiel)

Definition of Ready
Von Sebastian Schneider // 04.01.2018 // 0 Kommentare

Die Definition of Done (DoD) Scrum ist eine sogenannte Verpflichtung oder auch Commitment zum Inkrement. Diese Verpflichtungen dienen dazu, die Empirie und die Scrum-Werte für das Scrum-Team und seine Stakeholder zu stärken. Du kannst die Definition of Done dir immer als formale Beschreibung des Zustands des Inkrements vorstellen, wenn es die für das Produkt erforderlichen Qualitätsmaßnahmen erfüllt. Damit Scrum effektiv sein kann, benötigt es Transparenz. Durch die formale Definition der Bedeutung von fertig, reduzierst du die Wahrscheinlichkeit von falscher Erwartung an fertige Arbeit. Eine Messung hinsichtlich von "fertig" oder "nicht fertig" ist damit einfacher.

Details der Scrum Definition of Done 2024

Auch im Jahr 2024 gelten noch die Beschreibungen auf dem Scrum Guide, der die Änderungen von November aus dem Jahr 2020 trägt. Wir betrachten in diesem Abschnitt alle Details, die du brauchst um sie zu verstehen, wie du sie schreibt und wie ein Lebenszyklus dieser aussieht.

Woher kommt die Definition of done?

Zunächst einmal hilft uns der Scrum Guide enorm. Denn zu der Herkunft einer DoD findest du hier bereits wertvolle und konkrete Hinweise. Wenn sie für ein Inkrement Teil der Standards der Organisation ist, müssen sich alle Scrum Teams mindestens daran halten. Wenn es sich nicht um einen Organisationsstandard handelt, muss das Scrum Team eine für das Produkt geeignete Definition of Done erstellen.

Definition of Done in Scrum - Herkunft

Was muss sie alles enthalten?

Eine gute Definition of Done enthält alles, was das Team bzw. die Organisation tun muss, um ein Produkt an die Kunden zu liefern. Dieses Verständnis und der Inhalt dieser Definition of Done wird über die Zeit wachsen und mehr sowie reifer werden. Verwechsle sie aber nicht mit den Akzeptanzkriterien. Manche Teams teilen sie in der Hinsicht noch auf, dass sie hervorheben, was sie für jedes Product Backlog Item tun und was sie grundsätzlich in jedem Sprint tun. Dabei sprechen manche auch von verschiedenen Levels oder Ebenen - so gibt es dann zum Beispiel für den Sprint eine Anzahl an Dingen, die erfüllt sein müssen. Die Frage, nachdem was sie enthält variiert auch nach Branche. In der Softwareentwicklung betrachtest du andere Kriterien, als zum Beispiel im Maschinenbau.

Wie schreibe ich sie?

Du kannst hier jede Form nehmen, die dir im Scrum Team nützlich erscheint. Dabei solltest du auf eine gemeinsame Sprache achten. Wichtig dabei ist, dass Product Owner und Entwickler das gleiche Verständnis haben. Aber auch der Scrum Master ist gut beraten, zu verstehen, was diese Vereinbarung aussagt. Oft wird die DoD als Art Checkliste aufgeführt und dabei eine ganz normale Sprache verwendet.

Scrum Definition of Done (DoD) Workshop Format

Wo halte ich sie?

Auch das steht dir frei und es gibt hier natürlich mehrere Möglichkeiten. Wichtiger als der konkrete Ort ist, wie dich die Definition of Done bei der Arbeit unterstützt. Je weniger "Wege" du hast, sie aufzurufen oder zu finden, desto besser. Sie sollte irgendwo als eine Art Information Radiator existieren. Das hilft dir einfach damit umzugehen und auch schnell zu ändern. Wenn du möchtest, kannst du diese auch in deinem (ggf. erweiterten) Sprint Backlog halten. Ebenso kannst du diese in deinem Wiki oder einen Whiteboard vorhalten. Frage dich einfach immer nur, ob sie bekannt ist und alle damit umgehen können.

Wer schreibt sie?

Das Scrum Team ist dafür verantwortlich eine bereitzustellen. Gibt es, wie oben erwähnt, bereits eine in der Organisation, ist diese zu berücksichtigen. Wichtiger, als wer sie nun konkret schreibt, ist es, dass es sie gibt. Auch hier eignet sich in der Regel ein kleiner kurzer Workshop und dann hast du auch die Basis geschaffen. Das ist unkompliziert, alle sind eingebunden und du bist schnell fertig.

Den Unterschied zwischen der Definition of Done und Akzeptanzkriterien, habe ich dir in einem extra Artikel genauer beschrieben.

Lebenszyklus der Definition of Done

Lass uns nun in die Perspektive der DoD schlüpfen und erleben, was alles mit dieser geschieht. Wir schauen uns an, wie sie entsteht (Geburt), wie das Leben ist und das Ende (Tod)

Die Geburt

Die Erstellung erfolgt sehr oft in einem Scrum Team selbst, es kann aber auch sein, dass die Organisation etwas dazu beiträgt. Sie entsteht dadurch, dass Menschen mit einander sprechen und herausfinden, was seitens der Organisation gefordert und seitens des Scrum Teams notwendig ist. Meistens ist die Geburtsstunde dann ein gemeinsamer Workshop mit dem Scrum Team und ggf. weiteren Vertretern der Organisation. Sie ist dann abgestimmt und unterschiedliche Vorstellungen sind abgeglichen.

Das Leben

Sobald die DoD nach aktuellem Kenntnisstand ausreichend vollständig zum Start ist, ist sie auch mitten im Leben angekommen. Sie wird dann immer wieder genutzt, um zu überprüfen, ob eine z.B. die User Story aus dem Product Backlog als fertig angesehen werden kann. Dabei wird die Definition of Done immer wieder befragt, wenn es darum geht, ein gemeinsames Verständnis für "fertig" zu bekommen. Gegen Ende des Sprint, wenn es in Sprint Review geht, dient die Definition of Done immer wieder als Test, ob wir an alles gedacht haben, um fertige Arbeit zu zeigen

Doch auch im Sprint Planning kann die Definition of Done genutzt werden, um zu prüfen, wie viele Backlog Items voraussichtlich umgesetzt werden können, da die Entwickler so auch wissen, wie viele Qualitätskriterien berücksichtigt werden müssen, um eine Anforderung komplett umsetzen zu können.

Auch im Daily Scrum können die Entwickler nutzen, um zu prüfen, wie weit sie die Einträge liefern und ihr Fortschritt hinsichtlich der Product Backlog Einträge sind. Dabei wird die DoD wird regelmäßig überprüft und kann in Retrospektiven (oder auch dazwischen) verbessert und angepasst werden.

Das Ende

Eine Defintion of Done gibt es, solange es ein Inkrement und damit auch ein Produkt gibt. Wenn das Produkt nicht mehr existiert, dann wird auch die dazugehörige Definition of Done nicht mehr existieren. Was nicht bedeutet muss, dass die Erfahrungen nicht weiter verwendet werden können.

Templates & Beispiele für die Definition of Done

Wenn du nicht mit einem leeren Blatt beginnen möchtest, dann schaue dir die folgende Vorlage dazu gerne an und überlege, was und wie du adaptieren kannst:

Die folgenden Beispiele geben wir einen Eindruck davon, wie es lauten könnte:

  • Alle Akzeptanzkriterien sind erfüllt
  • 4 Augen Prinzip Review hat stattgefunden
  • Die Arbeit ist dokumentiert
  • Es existieren keine bekannten Fehler
  • Unit Test Abdeckung von X% vorhanden

Level of Done

Im Gegensatz zur Definition of Done wird manchmal noch ein Level of Done angesprochen. Das Level of Done wird immer dann wichtig, wenn du aus Organisationssicht nicht in der Lage bist, sofort ein potentiell auslieferbares Produktinkremement zu erstellen. Das kann unterschiedliche und z.B. physikalische Gründe haben. Verlassen wir die reine Softwareentwicklung und betrachten ein Produkt, in dem wir überwiegend Hardware erstellen. Dann kann (aktuell noch) nicht immer die Hardware nach jedem Sprint releasefertig sein. Beachte aber immer: nach jedem Sprint erzeugen Sie trotzdem Wert für den Kunden und es ist auch etwas "erlebbares" vorhanden. Beispiele für unterschiedliche "Level":

  • Die Hardware funktioniert am Aufsteller am Platz des Entwicklers, eingebunden in die Umgebung ohne zum Beispiel auf bestimmte Bussysteme im Auto zurückzugreifen.
  • Die Hardware funktioniert in einem Kontext mit anderer Hardware. Das können verschiedene Komponenten sein, die miteinander interagieren.
  • Die Hardware ist im Systemverbund testbar und unter realen Einsatzbedingungen nutzbar.

Achte aber bitte ganz genau darauf, ob dieses Level of Done nicht eigentlich dafür genutzt wird, etwas wegzulassen. Zum Beispiel die Tests wegzulassen macht kein Sinn und verkennt auch den Sinn des Level of Done.

Fazit

Wie wir gesehen haben, ist die Definition of Done ein zentraler Bestandteil der Transparenz und das Commitment zum Imkrement. Wenn du Scrum erfolgreich einsetzen möchtest, um Produkte zu entwickeln, die deine Kunden lieben, dann kommst du nicht an ihr vorbei. Starte am besten mit deinem Team in einem kleinen Workshop und haltet fest, was ihr schon alles könnt und was ihr noch machen wollt. So hast du in der Regel schon einen guten Startpunkt.

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

>