Seminare der PW-Akademie

Definition of Done

Was bedeutet Definition of Done?

Die Definition of Done (kurz DoD) ist ein Begriff aus dem agilen Arbeiten und gehört zum Scrum-Framework. Der Begriff taucht oftmals in der Softwareentwicklung auf. Darin arbeitet man mit einem Product-Backlog, das alle Anforderungen an das zu entwickelnde Produkt enthält. Für jeden Sprint, also für jeden Arbeitsabschnitt, werden aus diesem Product-Backlog einige Anforderungen, sogenannte Items, in das Sprint-Backlog übernommen. Die dort enthaltenen Items sind diejenigen, die am Sprintende erledigt sein sollen – also „done“.

Für ein gemeinsames Verständnis, wann ein solches Item als „done“ angesehen wird, wird die Definition of Done als Definition festgelegt. Die Definition of Done gilt dabei für jedes Item im Product Backlog. Sie wird vom Entwicklerteam definiert und mit dem Product Owner abgesprochen. Die Definition of Done ist also eine Teamvereinbarung, die sich auf die Qualität des zu entwickelnden Produkts statt auf dessen Funktionalität bezieht. Eine Definition of Done kann auch für einen gesamten Sprint oder über mehrere Sprints hinweg für das Release gelten. Dann bezieht sich die DoD jeweils auf den Abschluss eines Sprints oder auf die an den Kunden ausgelieferte Version des Systems.

Was bedeutet Definition of Ready?

Zusätzlich zur Definition of Done, deren Erklärung gerade geliefert wurde, gibt es den Begriff der Definition of Ready. Im Gegensatz zur Definition of Done, die ein etabliertes Scrum-Konzept ist, ist die Definition of Ready (kurz DoR) nicht ganz so verbreitet. Die DoR im Scrum definiert, wann ein Product-Backlog-Item so weit ausgearbeitet ist, dass es in das Sprint-Backlog übernommen werden darf. Eine gute DoR ist dabei schlank und auf die Zusammenarbeit fokussiert. Ein gutes Definition of Ready und Akzeptanzkriterien Beispiel wäre Folgendes: „Akzeptanzkriterien wurden gemeinsam im Refinement vereinbart“. Diese DoR ist besser geeignet als beispielsweise die Vereinbarung „Mindestens 4 Akzeptanzkriterien vorhanden“, da sich letztere nur auf das Item selbst, statt die Zusammenarbeit bezieht. Dennoch beinhalten beide Beispiele die Kernaussage, dass Akzeptanzkriterien vorhanden sein müssen. Ein weiteres Definition of Ready Beispiel ist das Folgende, das sich dann einen Schritt weiter auf das Verständnis bezieht: „Akzeptanzkriterien sind von jedem Beteiligten verstanden“. Im Gegensatz zur Definition of Done ist bei der DoR im Scrum der Product Owner für die Einhaltung verantwortlich.

Während der Zusammenarbeit entwickeln sich Definition of Done und Definition of Ready in der Regel weiter. Während die DoR meist immer kleiner wird, da sich die Zusammenarbeit einpendelt und das Team besser wird, wir die DoD im Scrum oft aus gleichem Grund immer umfangreicher: Das Team arbeitet effektiver zusammen und ist somit in der Lage, zum Sprintende immer mehr fertige Ergebnisse zu liefern.
Bezogen auf das Testing umfasst die Definition of Done zum Beispiel Anforderungen an Tests oder an Testende-Kriterien, wann man zu testen aufhört. Ideen zu sinnvollen Definition of Done Kriterien für Testings können beispielsweise die Tester-Einbindung, die Testfall-Erstellung, die Testabdeckung sowie das Testende sein. Korrespondierend dazu verhält es sich mit der Definition of Ready: Mit Bezug auf Testing muss hier das Item vom Tester beispielsweise als testbar eingestuft sowie Testfälle und ein Testplan erstellt werden.

Vorteile und Nutzen der Definition of Done

Insgesamt sind also sowohl Definition of Ready als auch besonders die Definition of Done wichtig. Die DoR sichert im Entwicklerteam das Verständnis der Product-Backlog-Items und somit auch die Arbeitsfähigkeit des Teams während eines Sprints. Weiterhin wird verhindert, dass Unklarheiten bezüglich der Items auftreten, die das Entwicklerteam allein nicht klären kann. Wäre dies der Fall, müsste die Arbeit zur Klärung unterbrochen werden, was zu Verzögerungen und Gefährdung des Sprinterfolgs führen kann. Mit einer guten DoR kann also der Entwicklungsaufwand gering gehalten und zugesichert werden, dass am Sprintende auch das geliefert wird, was von den Beteiligten erwartet wird.

Eine aussagekräftige Definition of Done in einem Scrum Projekt zu haben, ist ebenfalls essentiell. So wird sichergestellt, dass man keine Aussagen erhält wie „Die Aufgabe ist fast fertig“, wobei „fast“ sehr subjektiv ist. Durch die Definition of Done herrscht absolute Klarheit darüber, wann etwas als fertig eingestuft wird. Es dient also dazu, ein explizites und geteiltes Verständnis bei Definition of Done von „done“ zwischen Entwicklerteam und Product Owner zu schaffen. So hilft die Definition of Done bei Dokumentation von Fortschritten. Vorteile sind die Verbesserung der Transparenz bei der Arbeit und das Vorhandensein klarer Erwartungen, welche die Grundlage für eine gute Zusammenarbeit bilden. Durch eine klare Definition of Done steigt auch die Geschwindigkeit, mit der qualitativ hochwertige Arbeiten geliefert werden können. Mit einer gut etablierten Definition of Done lässt sich weiterhin die Velocity etablieren, sodass aussagekräftigere Vorhersagen getroffen und die Release-Planung reliabler werden kann.

Beispiel für eine gute Definition of Done

Als gutes Definition of Done Beispiel lässt sich folgender Text ansehen: „Ein Backlog-Item gilt als done, wenn die festgelegten Definition of Done Akzeptanzkriterien erfüllt sind, der Code nach Standard X erzeugt wurde, der Code in der Versionsverwaltung gesichert wurde, durch automatisierte Tests sowie manuelle Überprüfung keine Fehler gefunden wurden und die Dokumentation angepasst wurde.“ Eine Definition of Done lässt sich daneben auch als Kriterienkatalog darstellen:

  • Alle Akzeptanzkriterien sind erfüllt.
  • Code ist vollständig implementiert, kommentiert und steht unter Versionsverwaltung.
  • Code wurde im Pair Programming erarbeitet bzw. es gab einen Code-Review.
  • Vereinbarter Coding Standard und interne Konventionen sind eingehalten.
  • Unit-Tests sind vorhanden, durchgeführt und bestanden.
  • Funktionale Tests für die vereinbarte Testumgebung sind vorhanden.
  • Dokumentation und Release Dokumentation sind aktuell.
  • Keine kritischen Bugs sind offen.
  • Eintrag im Changelog ist angelegt.

Möchten Sie darüber hinaus weitere Definition of Done Beispiele kennenlernen, lohnt sich ein Blick auf die Schulungen unserer PW-Akademie. Die Definition of Done wird hier in unseren Projektmanagement Seminaren sowie den Schulungen zu Agile Scrum, CPPM und PRINCE2 thematisiert.

 

Auf einen Blick:

Was versteht man unter Definition of Done?+

Die Definition of Done (kurz DoD) ist ein Begriff aus dem agilen Arbeiten und gehört zum Scrum-Framework. Die dort enthaltenen Items sind diejenigen, die am Sprintende erledigt sein sollen – also „done“. Für ein gemeinsames Verständnis, wann ein solches Item als „done“ angesehen wird, wird die Definition of Done als Definition festgelegt.

Was versteht man unter Definition of Ready?+

Im Gegensatz zur Definition of Done, die ein etabliertes Scrum-Konzept ist, ist die Definition of Ready (kurz DoR) nicht ganz so verbreitet. Die DoR im Scrum definiert, wann ein Product-Backlog-Item so weit ausgearbeitet ist, dass es in das Sprint-Backlog übernommen werden darf.

Was sind die Vorteile und der Nutzen der Definition of Done?+

Durch eine klare Definition of Done steigt auch die Geschwindigkeit, mit der qualitativ hochwertige Arbeiten geliefert werden können. Mit einer gut etablierten Definition of Done lässt sich weiterhin die Velocity etablieren, sodass aussagekräftigere Vorhersagen getroffen und die Release-Planung reliabler werden kann.

Was sind die Kriterien der Definition of Done?+

Eine Definition of Done lässt sich als Kriterienkatalog darstellen:

  • Alle Akzeptanzkriterien sind erfüllt.
  • Code ist vollständig implementiert, kommentiert und steht unter Versionsverwaltung.
  • Code wurde im Pair Programming erarbeitet bzw. es gab einen Code-Review.
  • Vereinbarter Coding Standard und interne Konventionen sind eingehalten.
  • Unit-Tests sind vorhanden, durchgeführt und bestanden.
  • Funktionale Tests für die vereinbarte Testumgebung sind vorhanden.
  • Dokumentation und Release Dokumentation sind aktuell.
  • Keine kritischen Bugs sind offen.
  • Eintrag im Changelog ist angelegt.