Magazine

Was ist die Definition of Done? Wie du die perfekte DoD formulierst!

4 Min. Lesezeit

👉 Die wichtigsten Fakten zusammengefasst:

  • Die Definition of Done schafft ein gemeinsames Verständnis darüber, wann eine Aufgabe als "fertig" betrachtet wird.
  • Ein klar definiertes DoD minimiert Missverständnisse und fördert die Produktqualität.
  • Die DoD ist nicht nur in der Softwareentwicklung, sondern in vielen Bereichen anwendbar.
  • Die Formulierung der DoD erfolgt meist durch das Entwicklerteam und den Product Owner, basierend auf organisatorischen Vorgaben.

Für agile Kenner ist sie wohl kein neuer Begriff: Die Definition of Done.

Diese Definition des „Fertig-Zustandes“ dient dazu, allen Beteiligten eines Projektes (oder auch nur eines Teilaspektes dessen) dieselbe Vorstellung davon zu geben, wann eine Aufgabe wirklich „fertig“ ist. Ein Feature oder in Produkt darf also nicht weitergereicht, bzw. veröffentlicht werden, wenn es nicht diese Definition of Done erreicht hat.

So wird ein Feature nicht zu früh und nicht zu spät abgegeben und Missverständnisse vermieden. Die Definition of Done hat sich vor allem Scrum Projekten (besonders in der IT) stark etabliert und ist somit unter anderem Grund für den Erfolg agiler Herangehensweisen.

Doch wie in anderen Bereichen, muss auch eine Definition of Done erst gekonnt formuliert sein, um sie bestmöglich einzusetzen. Denn was ist eigentlich der richtige „Fertig-Zustand“ der DoD? Und wo macht sie Sinn? Auf diese Fragen möchten wir Dir in diesem Artikel Antworten geben.

Zusätzlich hat unser Scrum Experte Lars, das Thema noch in diesem YouTube Video besprochen:

Warum überhaupt eine Definition of Done?

Vor allem aber nicht nur im agilen Arbeiten sollen Entwickler und Teams Features und To-Do’s oft möglichst schnell erledigen, um auch dementsprechend schnelles Feedback zu erhalten. Das geschieht dann in manchen Fällen auf Kosten der Qualität.

Um das zu vermeiden, muss im Vorfeld geklärt werden, wann ein Feature oder eine User Story überhaupt bereit ist, ausgeliefert oder weitergereicht zu werden. Denn oftmals herrschen in Teams unterschiedliche Vorstellungen darüber, wann ein Produkt fertig ist und ausgeliefert werden darf.

Wenn von Anfang an klar ist, in welchem Zustand das Produkt sein muss, um „fertig“ zu sein und diese Definition of Done auch von Kunden- beziehungsweise Stakeholder-Seiten so abgenommen wird, kommt es im Nachhinein zu weniger Änderungen.

Ohne diese gemeinsame Abklärung bleiben für Entwicklerinnen und Entwickler oft viele Fragen offen und es herrscht Unklarheit über den Zustand eines Features. Die Folge davon ist, dass ein Produkt entweder zu früh ausgeliefert oder aber bis in die Ewigkeit unnötig weiterentwickelt wird.

Mit einer Definition of Done kann ein Feature oder Item reibungslos (beispielsweise) auf einem Kanban-Board weitergeschoben werden ohne, dass sich Entwicklerinnen und Entwickler erst fragen müssen, ob es denn schon bereit dazu ist.

DoD: Nicht nur in der Softwareentwicklung sinnvoll

Die Einführung der Definition of Done macht also überall dort Sinn, wo ein Produkt oder auch eine Dienstleistung an eine nächste Partei abgeliefert wird – somit quasi überall. Egal ob der oder die Abnehmerin ein Endkunde ist oder die nächste Abteilung, die an dem Produkt arbeitet, ist: Um diese Abnehmer auch zufrieden zu stellen und Missverständnisse zu vermeiden, macht es Sinn, davor zu klären, wann das Produkt wirklich als „fertig“ gilt.

Obwohl die Formulierung einer Definition of Done ihren Ursprung wohl in der agilen Softwareentwicklung (und somit auch Scrum) hat, kann ihr Einsatz in den unterschiedlichsten Branchen und Teams wertvoll sein. Ähnlich wie die agile Methode Scrum selbst, wurde die Praktik in der IT getestet und geschliffen, um sich dann auch auf alle anderen Bereiche auszuweiten.

„The definition of Done by itself will drive a doubling of the productivity of the team!“ – Jeff Sutherland (Scrum Mitbegründer)

Wie formuliere ich eine Definition of Done?

In der Regel kümmern sich die Entwicklerinnen und Entwickler gemeinsam mit dem Product Owner um die Formulierung der DoD – aufbauend auf bestimmte Vorgaben, die im Vorfeld von der Organisation kommen. Die Anforderungen, die von den Stakeholdern ausgehen werden vom Product Owner vertreten.

Bei der Formulierung ist es wichtig an den Sinn der Definition of Done zu denken: Sobald sie eingetroffen ist, ist das Inkrement da und – wie vermutet – fertig.

Eine solche Definition könnte also lauten: „Das Produkt ist fertig, wenn alle Backlog Items erledigt sind, das Produkt getestet wurde und der Product Owner die Möglichkeit hatte, zu überprüfen, ob er damit zufrieden ist“

Die DoD kann auch angepasst werden, sollte aber nicht unbedingt vollständig umformuliert werden. Anpassungen sollten außerdem nur der Qualitätsmaximierung dienen und müssen dem gesamten Team transparent gemacht werden.

Selbstverständlich soll die Definition des „Fertig-Zustands“ durchgehend für das ganze Team zugänglich und auch verständlich sein. Deshalb muss sie klar formuliert und dem ganzen Team bekannt sein, um auch die erhoffte Wirkung zu erzielen.

Ein Beispiel von scruminc für eine DoD eines Software Projektes ist: “Done means coded to standards, reviewed, implemented with unit Test-Driven Development (TDD), tested with 100 percent test automation, integrated and documented.”

Ob die DoD als Checkliste oder in vollständigen Sätzen formuliert ist grundsätzlich jedem Team überlassen, wobei eine Auflistung meist einfacher zu verstehen ist.

Mehr zu agilen Projekten nach Scrum?

Neben der Definition of Done hat das Scrum Framework auch viele weitere hilfreiche Praktiken und Events hervorgebracht, die auch außerhalb von Scrum Projekte sinnvoll im Einsatz sind. Besuche unseren Agile Heroes YouTube Kanal, um noch mehr zum Thema Scrum und anderen agilen Herangehensweisen herauszufinden.

💁 Unser Fazit:

Die Definition of Done (DoD) ist ein Schlüsselkonzept in agilen Arbeitsmethoden, insbesondere im Scrum-Framework. Sie dient dazu, ein gemeinsames Verständnis im Team darüber zu schaffen, wann eine Aufgabe oder ein Feature als "fertig" gilt. Dies hilft, Missverständnisse zu vermeiden und die Produktqualität sicherzustellen. Die DoD sollte klar formuliert und allen Teammitgliedern bekannt sein. Obwohl sie ihren Ursprung in der Softwareentwicklung hat, ist ihre Anwendung in vielen anderen Bereichen ebenso sinnvoll.

👆 FAQ - Häufig gestellte Fragen

✍️ Über den Autor

Michel Abé

Geschäftsführer bei den Agile Heroes

Michel ist neben seinen Aufgaben als Geschäftsführer bei den Agile Heroes auch noch als Consultant bei seinen Kunden und setzt spannende agile Projekte um.

Gratis Playbook

Die wichtigsten Infos zuAgile Coach kurz und knapp

Playbook erhalten