Definition of Done

Der Sinn einer Definition of Done

„Ich bin fast fertig.“ Oder: „Die Aufgabe ist zu 90% erledigt.“ Vielleicht haben Sie solche Aussagen auch schon einmal gehört, die Hinweise zum Fortschritt einer Aufgabe liefern, aber nicht sonderlich konkret sind. Was bedeutet „fast fertig“? Welche 10% fehlen noch zur Fertigstellung?

Mit einer Definition of Done erzeugen Sie Klarheit. Durch die Verwendung wissen Sie, was benötigt wird, damit etwas als „fertig“ gelten kann. Diese Klarheit hängt nicht von persönlichen Einschätzungen ab; sie ist das Ergebnis von vereinbarten Kriterien, die allesamt erfüllt sein müssen, so dass aus einem „fast fertig“ ein „Fertig“ bzw. „Done“ wird. Darüber hinaus steht eine DoD für einen Qualitätsanspruch, für eine Ausrichtung auf Werte und Prozeduren.

Das Commitment zur Definition of Done

Eine Definition of Done steht und fällt mit dem Commitment des Teams. Es ist der Anspruch des Teams, die vereinbarten Kriterien konkret umzusetzen. Es ist eine Verpflichtung und eine wesentliche Basis für die erfolgreiche Entwicklung von Produkten. Damit sie ihre Wirkung entfaltet, ist es wichtig, dass sie gemeinsam im Team entwickelt wird. Eine DoD, die nur vom Product Owner erstellt wurde, führt nicht zu einem solchen Commitment.

Damit die Definition of Done ihre größtmögliche Wirkung entfalten kann, empfiehlt es sich, sie für alle Beteiligten jederzeit gut sichtbar, idealerweise als Ausdruck an einer Wand, zu veröffentlichen. Durch diese Transparenz steigt zusätzlich das Commitment des Teams, die vereinbarten Kriterien zu erfüllen.

Beispiele für eine Definition of Done

Sie können eine Definition of Done ausformulieren oder als Kriterienliste anlegen. Wenn Sie Software entwickeln, könnte eine ausformulierte DoD wie folgt lauten:

„Eine User Story gilt als fertig, sofern die Akzeptanzkriterien erfüllt sind, die Codeerzeugung nach Standard XYZ erfolgt ist, der Code in der Versionsverwaltung gesichert, die manuelle Überprüfung durch ein Teammitglied und die automatisierten Tests keine Fehler ergeben haben und die Dokumentation angepasst wurde.“

Häufig entscheiden sich Organisationen dazu, ihre Definition of Done als Kriterienliste anzulegen, denn dies bietet die Option, einzelne Kriterien separat abzuhaken. Eine solche Liste könnte unter anderem folgende Punkte beinhalten:

• Alle Akzeptanzkriterien werden erfüllt.
• Der Code ist vollständig implementiert und kommentiert.
• Der Code wurde im Pair Programming erarbeitet.
• Die Coding Standards von XYZ und die internen Konventionen ABC wurden eingehalten.
• Der Code steht unter Versionsverwaltung.
• Ein Code Review wurde durchgeführt.
• Die Unit-Tests wurden durchgeführt und bestanden.
• Eine Dokumentation wurde erstellt.
• Ein Eintrag im Changelog wurde angelegt.

Bei der Erstellung einer Definition of Done sollten Teams darauf achten, dass die festgelegten Kriterien überprüft werden müssen. Je mehr Kriterien definiert werden, desto mehr Kriterien gilt es zu überprüfen. Würde die Überprüfung nicht stattfinden, wäre schon bald der Sinn der DoD hinfällig. Anspruch und Realität müssen also zusammenpassen.

Der Unterschied zu Akzeptanzkritieren

Es gibt einen wesentlichen Unterschied zwischen Akzeptanzkriterien und einer Definition of Done:

Akzeptanzkriterien beziehen sich immer konkret auf ein Item wie bspw. eine User Story. Sie sorgen für mehr Klarheit, was im Rahmen der User Story umzusetzen ist, und sind sie Quelle für Akzeptanztests. Die Definition of Done hingegen bezieht sich bspw. auf das generelle Arbeiten mit User Storys, d.h. die dort formulierten Kriterien sind invariant. Müssen bspw. Entwicklungen vor der Freigabe einer Peer-Prüfung und einem QA-Test unterzogen werden, finden sich diese Kriterien in der DoD und nicht in den Akzeptanzkriterien der User Story wieder.

Zum Fertigstellen einer User Story reicht also nicht, lediglich die Akzeptanzkriterien zu erfüllen, auch die Kriterien der DoD müssen erfüllt sein. Grundsätzlich kann die Erfüllung der Akzeptanzkriterien auch ein Kriterium bei der DoD darstellen.

Vorteile einer Definition of Done

Das Arbeiten mit einer Definition of Done bietet verschiedene Vorteile:

• Es gibt ein gemeinsames Verständnis von Qualität und das Commitment des Teams, diese Qualität zu liefern. Dabei ist der Qualitätsgedanke umfassender, denn er bezieht sich auf mehr als nur eine Aufgabe oder eine User Story.
• Jeder im Team weiß, was von jedem erwartet wird und was das Team als Einheit zu liefern hat.
• Der Anspruch im Team, qualitative Arbeit zu leisten, steigt.
• Die vereinbarten Kriterien lassen sich überprüfen, d.h. die DoD ist ein Arbeitsmittel.
• Es lassen sich für verschiedene Aspekte DoDs definieren, bspw. für User Storys, Features, Sprints oder Releases. So entstehen zu Themen passende DoDs, die sich auch gemeinsam im Team weiterentwickeln lassen.
• Es entsteht Klarheit darüber, ob ein Backlog Item, ein Feature oder eine User Story tatsächlich „done“ ist.

Die konsequente Anwendung der Definition of Done

Unternehmen stehen bei der Nutzung einer Definition of Done vor mehreren Herausforderungen:

• Wie gelingt die konsequente Anwendung einer Definition of Done?
• Wie wird das Zusammenspiel zwischen verschiedenen DoDs organisiert?
• Wie lässt sich die Checkliste mit Qualitätskriterien weiterentwickeln?

Bei der Nutzung einer Definition of Done stellt sich Organisationen früher oder später die Frage, ob es akzeptabel ist, nicht immer alle Kriterien vollständig zu erfüllen. Vielleicht sind die definierten Kriterien doch umfangreicher als ursprünglich beabsichtigt, vielleicht ist es in Einzelfällen in Ordnung, technische Schulden zu akzeptieren? Eine allgemeingültige Antwort auf die Frage gibt es nicht; sie liegt in einer Grauzone. Für eine Organisation ist es aber wichtig zu unterscheiden, ob es eine einmalige Abweichung sein wird oder ob die DoD dauerhaft verändert werden soll. Die Weiterentwicklung der Kriterien kann so zur Reduzierung oder im umgekehrten Fall zur Aufstockung von Kriterien führen.

Die Verwendung mehrerer DoDs auf verschiedenen Ebenen kann zu einem Overhead und einem Verlust an Transparenz führen. Sind die Akzeptanzkriterien einer User Story erfüllt, gilt es die Definition of Done zu überprüfen. Die DoD für die Entwicklung von User Storys ist naheliegend. Ergänzend greift bspw. die Definition of Done des Sprints und dann evtl. die des Releases. Wo verwalten Organisationen die entsprechenden Informationen? Wie erfolgt die Abnahme einer User Story, wenn auf einer anderen Ebene ein Kriterium nicht erfüllt wurde? Führt das Arbeiten mit mehreren DoDs in der Konsequenz nicht dazu, dass Kriterien der höheren Ebenen schrittweise in Richtung der User Storys verlagert werden? Auch diese Fragen lassen sich nicht allgemeingültig beantworten. In anderen Worten: Organisationen müssen einen pragmatischen Weg im Umgang mit Qualitätskriterien der verschiedenen Ebenen finden und ggf. nicht nur eine einzelne sondern auch das Zusammenspiel verschiedener DoDs weiterentwickeln.¹

Definition of Done in der Praxis

Hier finden Sie einige englisch- und deutschsprachige Beiträge, die sich mit der Definition of Done in der Praxis beschäftigen:

• Five reasons for having a Definition of Done – Beitrag von Michael Küsters bei Fail Fast, Move On.
• Schwächen der Definition of Done in der Anwendung – Beitrag von Felix Stein bei One Lean and Agility.
• Wer ist eigentlich für die Definition of Done verantwortlich? – Beitrag von Marc Kaufmann bei srcum.org.
• Definition of Done Canvas – Beitrag von Rickard Jones auf DZone.
• Definition of Done vs. User Stories vs. Acceptance Criteria – Beitrag bei agile pain relief.
• Why Scrum Requires Completely “Done” Software Every Sprint – Beitrag von Christiaan Verwijs bei scrum.org.

Gerne ergänzen wir die Liste mit weiteren spannenden Beiträgen.

Ist eine Definition of Done eher ein Commitment des Teams zu Qualität oder ein Hilfsmittel für Transparenz?

Hinweise:

Wenn Ihnen der Beitrag gefällt, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für Tipps aus der Praxis interessieren, dann testen Sie unseren beliebten Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter.

[1] Es empfiehlt sich in der Praxis eher, eine unternehmensweite, zumindest aber eine teamübergreifende Definition of Done als Mindeststandard zu vereinbaren. Diesen Standard können einzelne Teams bei Bedarf mit individuell ergänzten Inhalten erweitern.

Hier finden Sie einen interessanten Podcast zum Fokus und der Konsistenz für Teams durch die DoD.

Und hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.