Definition of Done: Kriterien & Beispiele

In agilen Teams wirkt „fertig“ oft eindeutiger, als es tatsächlich ist. Für eine Person ist eine User Story erledigt, sobald der Code geschrieben wurde. Für eine andere gehört ein Code Review dazu. Für das Entwicklungsteam zählen vielleicht Unit Tests, Dokumentation und eine erfolgreiche Prüfung in der Testumgebung. Ohne gemeinsame Vereinbarung entstehen Missverständnisse, technische Schulden und unfertige Ergebnisse.

Genau dafür gibt es die Definition of Done, kurz DoD. Sie beschreibt, welche Qualitätskriterien erfüllt sein müssen, damit ein Product Backlog Item oder ein Inkrement als abgeschlossen gilt. Besonders in Scrum ist sie zentral, aber auch Teams mit Kanban oder anderen agilen Methoden können davon profitieren.

Was ist die Definition of Done?

Die Definition of Done ist eine gemeinsame Vereinbarung darüber, wann Arbeit als fertig gilt. Im Scrum Framework bezieht sie sich auf das Inkrement, also den nutzbaren Produktfortschritt, der im Sprint entsteht. Ein Product Backlog Item wird erst dann Teil dieses Inkrements, wenn es die Definition of Done erfüllt.

In der Praxis funktioniert die DoD wie eine Qualitätsvereinbarung. Sie kann Kriterien enthalten wie erfüllte Akzeptanzkriterien, abgeschlossene Tests, aktualisierte Dokumentation, Code Review, keine bekannten kritischen Fehler oder erfolgreiche Abnahme in einer Testumgebung. Entscheidend ist, dass die Kriterien nicht für eine einzelne User Story erfunden werden, sondern teamweit gelten.

Unser Artikel zur Scrum-Methode zeigt, warum ein gemeinsames Verständnis von „erledigt“ für Sprints, Teamarbeit und kontinuierliche Verbesserung wichtig ist. Ohne diese Klarheit steigt das Risiko, dass Arbeit zwar als abgeschlossen markiert wird, später aber erneut geöffnet werden muss.

Warum ist die Definition of Done wichtig?

Eine gute Definition of Done schützt Qualität. Sie verhindert, dass Teams unfertige Arbeit als abgeschlossen zählen und Probleme in spätere Phasen verschieben. Das ist besonders wichtig in der agilen Softwareentwicklung, weil häufige Lieferung nur dann funktioniert, wenn Ergebnisse tatsächlich nutzbar sind.

Die DoD schafft außerdem Transparenz. Product Owner, Scrum Master, Entwicklungsteam und Stakeholder wissen, was sie von einem fertigen Ergebnis erwarten können. Dadurch werden Sprint Review, Planung und Priorisierung verlässlicher. Wenn ein Team am Ende eines Sprints Arbeit präsentiert, sollte klar sein, dass diese Arbeit nicht nur begonnen, sondern nach vereinbarten Standards abgeschlossen wurde.

Auch im agilen Projektmanagement hilft die Definition of Done, Erwartungen zu klären. Sie macht sichtbar, welche Arbeitsschritte zur Qualität beitragen und welche Punkte nicht jedes Mal neu diskutiert werden müssen.

Was gehört in die Definition of Done?

Eine Definition of Done sollte klar, prüfbar und realistisch sein. Sie darf nicht so oberflächlich sein, dass sie die Qualität kaum schützt. Sie darf aber auch nicht so umfangreich werden, dass sie im Alltag niemand mehr nutzt. Gute Kriterien sind konkret genug, damit das Scrum-Team sie bei jedem relevanten Arbeitsergebnis anwenden kann.

Die konkrete Ausgestaltung hängt vom Produkt ab. Ein Softwareteam braucht andere Kriterien als ein Marketingteam, ein IT-Team oder ein operatives Team. Wichtig ist nicht die perfekte Liste, sondern ein gemeinsames Qualitätsverständnis, das regelmäßig überprüft wird.

Definition of Done Beispiel für Scrum-Teams

Ein einfaches Beispiel für eine Definition of Done in einem Softwareteam könnte so aussehen: Die Akzeptanzkriterien der User Story sind erfüllt, der Code wurde überprüft, relevante Unit Tests laufen erfolgreich, die Dokumentation wurde aktualisiert und die Änderung wurde in der Testumgebung geprüft. Zusätzlich dürfen keine kritischen Fehler offen sein.

Für ein Scrum-Team, das nicht an Software arbeitet, können andere Kriterien gelten. Ein Content-Team könnte festlegen, dass ein Artikel erst fertig ist, wenn Briefing, fachliche Prüfung, SEO-Prüfung, Lektorat, Freigabe und Veröffentlichungsvorbereitung abgeschlossen sind. Ein HR-Team könnte definieren, dass ein Onboarding-Prozess erst fertig ist, wenn Aufgaben, Verantwortlichkeiten, Schulungen und Feedbackschleifen vorbereitet sind.

Der Punkt ist: Die Definition of Done muss zum Arbeitskontext passen. Sie soll nicht blind aus einem Scrum Guide übernommen werden, sondern die tatsächlichen Qualitätsanforderungen des Teams abbilden.

Definition of Done vs. Akzeptanzkriterien

Die Definition of Done und Akzeptanzkriterien werden oft verwechselt. Beide helfen Teams, Qualität zu sichern, aber sie haben unterschiedliche Aufgaben. Akzeptanzkriterien, auf Englisch Acceptance Criteria, beschreiben die Anforderungen an eine konkrete User Story. Die Definition of Done beschreibt dagegen allgemeine Qualitätskriterien, die für viele oder alle Arbeitsergebnisse gelten.

Ein Beispiel: Eine User Story lautet: „Als Nutzer möchte ich mein Passwort zurücksetzen, damit ich wieder Zugriff auf mein Konto erhalte.“ Die Abnahmekriterien könnten festlegen, dass die Person eine E-Mail erhält, der Link nur begrenzt gültig ist und eine Erfolgsmeldung angezeigt wird. Die DoD ergänzt teamweite Kriterien wie Code Review, Tests, Dokumentation und Prüfung in der Testumgebung.

Unser Leitfaden zum Product Backlog zeigt, wie einzelne Product Backlog Items organisiert und priorisiert werden. Die DoD sorgt anschließend dafür, dass diese Items nicht nur ausgewählt, sondern sauber fertiggestellt werden.

Definition of Done vs. Definition of Ready

Auch Definition of Done und Definition of Ready werden häufig zusammen genannt. Die Definition of Ready, kurz DoR, beschreibt, wann ein Product Backlog Item bereit ist, in einen Sprint aufgenommen zu werden. Die Definition of Done beschreibt, wann diese Arbeit nach der Umsetzung abgeschlossen ist.

Einfach gesagt: Die DoR steht vor der Arbeit, die DoD nach der Arbeit. Eine gute Definition of Ready kann Kriterien enthalten wie klare Beschreibung, bekannte Abhängigkeiten, geschätzter Aufwand, verständliche Akzeptanzkriterien und keine offenen Grundsatzfragen. Die DoD stellt danach sicher, dass die Umsetzung den Qualitätsanforderungen entspricht.

Im Sprint Planning ist diese Abgrenzung besonders wichtig. Wenn ein Item nicht bereit ist, entsteht im Sprint unnötige Klärungsarbeit. Wenn ein Item nicht „done“ ist, entsteht nach dem Sprint Nacharbeit. Unser Leitfaden zum Sprint Planning hilft Teams, solche Übergänge strukturierter vorzubereiten.

Wer legt die Definition of Done fest?

Im Scrum Guide ist klar: Wenn eine Organisation eine Definition of Done als Standard vorgibt, müssen Scrum-Teams diese als Mindeststandard einhalten. Gibt es keinen solchen Standard, erstellt das Scrum-Team eine passende Definition of Done für das Produkt.

In der Praxis sollten Product Owner, Scrum Master und Entwicklungsteam gemeinsam beteiligt sein. Der Product Owner bringt fachliche Erwartungen und Nutzerwert ein. Das Development Team oder Entwicklungsteam beurteilt technische Qualität, Tests und Machbarkeit. Der Scrum Master unterstützt den Prozess, achtet auf Transparenz und hilft dem Team, eine praktikable Vereinbarung zu finden.

Wichtig ist, dass die DoD nicht von außen als starre Checkliste aufgezwungen wird. Sie muss verstanden und getragen werden. Nur dann wird sie im Sprint wirklich genutzt und nicht als formaler Pflichtpunkt behandelt.

Definition of Done im Sprint nutzen

Die DoD gehört nicht nur ans Ende eines Sprints. Sie sollte während der gesamten Arbeit sichtbar sein. Schon im Sprint Planning hilft sie, Aufwand realistisch einzuschätzen. Während der Umsetzung erinnert sie das Team daran, welche Qualitätsschritte noch fehlen. Im Sprint Review zeigt sie, ob ein Ergebnis wirklich präsentierbar ist.

Auch das Sprint Backlog profitiert von klaren Fertigstellungskriterien. Wenn Aufgaben, User Stories und Qualitätskriterien gemeinsam sichtbar sind, erkennt das Team schneller, ob die Arbeit wirklich abgeschlossen ist oder nur „fast fertig“ wirkt.

In der Sprint Retrospektive sollte die DoD regelmäßig überprüft werden. Vielleicht fehlen Kriterien für Sicherheit, Dokumentation oder Testabdeckung. Vielleicht sind einzelne Punkte zu unklar oder werden nie angewendet. Eine gute Sprint-Retrospektive hilft, solche Erkenntnisse in konkrete Verbesserungen zu übersetzen.

Definition of Done und Kanban

Auch Kanban-Teams können mit einer Definition of Done arbeiten. Der Unterschied liegt darin, dass Kanban nicht in festen Sprints organisiert sein muss. Stattdessen fließt Arbeit kontinuierlich durch verschiedene Prozessschritte.

In Kanban kann eine DoD für einzelne Spalten oder Übergänge gelten. Eine Aufgabe darf zum Beispiel nur von „In Bearbeitung“ nach „Review“ wechseln, wenn bestimmte Kriterien erfüllt sind. Für den Übergang nach „Fertig“ können weitere Qualitätskriterien gelten. So wird aus einer losen Aufgabenverwaltung ein transparenter Qualitätsprozess.

Der Vergleich von Kanban und Scrum zeigt, dass beide Methoden unterschiedliche Stärken haben. Die Definition of Done ist dabei kein exklusives Scrum-Werkzeug, sondern eine nützliche Arbeitsvereinbarung für Teams, die klare Ergebnisse liefern möchten.

Tools und Anbieter für die Definition of Done

Die Definition of Done ist zuerst eine Teamvereinbarung, kein Tool. Trotzdem hilft passende Software dabei, Kriterien sichtbar, wiederholbar und überprüfbar zu machen.

Asana ist besonders stark, wenn die Definition of Done nicht nur dokumentiert, sondern in tägliche Arbeit übersetzt werden soll. Teams können Qualitätskriterien wie Checklisten, Aufgabenbeschreibungen, Vorlagen oder Workflow-Schritte sichtbar machen. Ein Workflow-Audit kann zusätzlich zeigen, wo Arbeit zu früh als abgeschlossen markiert wird oder wo Qualitätsprüfungen regelmäßig fehlen.

Wie lässt sich die Definition of Done mit Asana abbilden?

In Asana kann die DoD direkt dort sichtbar werden, wo Arbeit stattfindet. Teams können Aufgabenbeschreibungen nutzen, um Akzeptanzkriterien und DoD-Hinweise festzuhalten. Wiederkehrende Kriterien lassen sich in Vorlagen, Unteraufgaben oder Abschnitten abbilden. Statusfelder können zeigen, ob ein Item noch in Umsetzung, im Review, in der Testphase oder wirklich abgeschlossen ist.

Für agile Teams ist das besonders praktisch, weil Asana nicht nur einzelne Aufgaben zeigt, sondern auch Verantwortlichkeiten, Fristen, Abhängigkeiten und Workflows. Dadurch wird klar, wer eine Prüfung übernimmt, welcher Schritt noch offen ist und welche Arbeit nicht als done gelten darf.

Eine gute DoD wirkt außerdem gegen technische Schulden. Wenn Teams Tests, Reviews oder Dokumentation regelmäßig überspringen, entstehen Probleme, die später mehr Aufwand verursachen. Asana hilft, solche Arbeitsschritte sichtbar zu machen, statt sie als unsichtbare Zusatzarbeit zu behandeln.

Welche Rolle spielen Asana AI Teammates?

Asana AI Teammates können Teams bei koordinationsintensiver Arbeit unterstützen. Sie arbeiten im Kontext von Projekten, Aufgaben und Workflows und können Informationen zusammenfassen, offene Punkte sichtbar machen, nächste Schritte vorschlagen sowie Risiken oder Engpässe kennzeichnen.

Für die Definition of Done kann das hilfreich sein, wenn viele Aufgaben, Reviews und Qualitätskriterien zusammenlaufen. Ein AI Teammate kann beispielsweise offene Prüfschritte in einem Sprint sichtbar machen, Statusinformationen zusammenfassen oder Hinweise liefern, welche Aufgaben noch nicht vollständig vorbereitet sind. Die fachliche Prüfung, technische Bewertung und die finale Entscheidung, ob ein Ergebnis wirklich fertig ist, bleiben jedoch beim Scrum-Team.

Erfahren Sie mehr darüber, wie künstliche Intelligenz als Unterstützung in echten Arbeitsabläufen eingesetzt werden kann, statt außerhalb des Teamkontexts zu stehen.

Häufige Fehler bei der Definition of Done

Ein häufiger Fehler ist eine zu vage DoD. Wenn dort nur „getestet“ oder „dokumentiert“ steht, bleibt offen, was genau gemeint ist. Besser sind prüfbare Kriterien: Welche Tests? Welche Dokumentation? Welche Umgebung? Welche Abnahme?

Ein zweiter Fehler ist eine zu große Liste. Wenn jede Kleinigkeit Teil der Definition of Done wird, verliert das Team den Fokus. Die DoD sollte Qualität sichern, aber nicht jede Arbeit unnötig schwer machen.

Ein dritter Fehler ist fehlende Pflege. Teams entwickeln sich weiter, Produkte verändern sich und Qualitätsanforderungen steigen. Deshalb sollte die DoD regelmäßig in der Retrospektive geprüft und angepasst werden.

FAQ zur Definition of Done

Was ist die Definition of Done?

Die Definition of Done ist eine gemeinsame Vereinbarung im Scrum-Team, die festlegt, wann ein Product Backlog Item oder Inkrement als fertig gilt. Sie beschreibt Qualitätskriterien, die erfüllt sein müssen, bevor die Arbeit als abgeschlossen zählt.

Was gehört in die Definition of Done?

Typische Kriterien sind erfüllte Akzeptanzkriterien, abgeschlossene Unit Tests, erfolgreiche Integrationstests, Code Review, aktualisierte Dokumentation, Prüfung in der Testumgebung und keine offenen kritischen Fehler.

Wer legt die Definition of Done im Scrum-Team fest?

Wenn es keinen organisatorischen Standard gibt, legt das Scrum-Team die Definition of Done gemeinsam fest. Product Owner, Scrum Master und Entwicklungsteam sollten beteiligt sein, damit fachliche und technische Anforderungen berücksichtigt werden.

Was ist der Unterschied zwischen Definition of Done und Akzeptanzkriterien?

Akzeptanzkriterien beschreiben, wann eine konkrete User Story fachlich erfüllt ist. Die Definition of Done beschreibt allgemeine Qualitätskriterien, die für mehrere oder alle Arbeitsergebnisse gelten.

Was ist der Unterschied zwischen Definition of Done und Definition of Ready?

Die Definition of Ready beschreibt, wann ein Product Backlog Item bereit für die Umsetzung ist. Die Definition of Done beschreibt, wann das Ergebnis nach der Umsetzung wirklich abgeschlossen ist.

Fazit: Die Definition of Done macht Qualität sichtbar

Eine gute Definition of Done gibt agilen Teams ein gemeinsames Verständnis davon, wann Arbeit wirklich fertig ist. Sie reduziert Missverständnisse, stärkt Qualität und verhindert, dass unfertige Arbeit in Sprint Reviews, Releases oder Folgeprozesse rutscht.

Asana unterstützt Teams dabei, die DoD nicht nur zu dokumentieren, sondern im Arbeitsalltag sichtbar zu machen. Mit Aufgaben, Vorlagen, Workflows, Statusfeldern, Verantwortlichkeiten und AI Teammates können Teams Qualitätskriterien besser koordinieren und kontinuierlich verbessern. So wird „done“ nicht zur Auslegungssache, sondern zu einer verlässlichen Grundlage für bessere Ergebnisse.