·
9 min
Definition of Done: Bedeutung, Beispiel und Abgrenzung zu Akzeptanzkriterien
Roman Kirchmeier - Autemos
Die Definition of Done (DoD) ist die verbindliche Qualitätsvereinbarung eines Scrum Teams: Sie legt fest, welche Prüfungen ein Increment bestanden haben muss, bevor es als fertig gilt. Der Scrum Guide 2020 nennt sie das Commitment des Increments. Ein Eintrag, der sie verfehlt, darf weder released noch im Sprint Review gezeigt werden. In Banken hat die DoD eine zweite Aufgabe: Sie bringt Testpflichten aus der EU-Verordnung DORA oder dem FINMA-Rundschreiben 2023/1 in jeden Sprint. Eine gute DoD trennt automatisierte Pipeline-Checks von manuellen Prüfungen und enthält eigene Punkte für KI-generierten Code.
Kurz gefasst: Die DoD ist laut Scrum Guide 2020 eine formale Beschreibung des Zustands, den jedes Increment erreichen muss. Sie gilt für alle Backlog-Einträge, Akzeptanzkriterien gelten pro Story, die Definition of Ready steht nicht im Guide. In Banken gehören regulatorische Mindestpunkte hinein, etwa die Pflicht aus DORA Art. 9(4)(e), jede IKT-Änderung zu erfassen und zu testen.
Abbildung 1: Wann ein Increment als fertig gilt
Was ist die Definition of Done?
Die Definition of Done ist eine formale Qualitätsbeschreibung, die für jedes Increment eines Scrum Teams gilt und festlegt, wann Arbeit fertig ist. Im Scrum Guide steht: „Die Definition of Done ist eine formale Beschreibung des Zustands des Increments, wenn es die für das Produkt erforderlichen Qualitätsmaßnahmen erfüllt.“ (Scrum Guide 2020, 2020)
Die Konsequenz steht im selben Abschnitt: „Wenn ein Product-Backlog-Eintrag nicht der Definition of Done entspricht, kann es weder released noch beim Sprint Review präsentiert werden.“ (Scrum Guide 2020, 2020) Der Eintrag wandert zurück ins Product Backlog. Die Developer:innen sind verpflichtet, der DoD zu entsprechen. Halbfertige Arbeit hat im Increment keinen Platz.
Eine brauchbare DoD hat wenige Merkmale:
Sie gilt für jeden Backlog-Eintrag gleich, ob Feature, Bugfix oder technische Aufgabe.
Sie wird auf Team- oder Organisationsebene festgelegt und bleibt über viele Sprints weitgehend stabil, so beschreibt es ein Professional-Scrum-Trainer auf Scrum.org (2024).
Jeder Punkt lässt sich mit Ja oder Nein beantworten und hat einen sichtbaren Nachweis.
Was trennt DoD, Akzeptanzkriterien und Definition of Ready?
Die DoD gilt für jedes Increment, Akzeptanzkriterien gelten für genau eine User Story, und die Definition of Ready ist eine Teampraxis für den Eintritt einer Story in den Sprint. Nur die DoD steht im Scrum Guide 2020, die anderen beiden kommen darin nicht vor (Scrum Guide 2020, 2020).
Abbildung 2: DoD, Akzeptanzkriterien und DoR im Vergleich
Merkmal | DoD | Akzeptanzkriterien | Definition of Ready |
|---|---|---|---|
Geltungsbereich | Jedes Increment, jeder Backlog-Eintrag | Eine einzelne User Story | Eine Story vor dem Sprint Planning |
Im Scrum Guide 2020 | Ja, als Commitment des Increments | Nein | Nein, der Guide beschreibt nur Refinement |
Festgelegt von | Organisation als Mindestmaß, dann Scrum Team | Product Owner mit Team und Stakeholdern | Team, freiwillig |
Beispielpunkt | „Regressionstests der betroffenen Funktionen grün“ | „Überweisung über dem Tageslimit wird abgelehnt“ | „Abhängigkeiten zu anderen Teams geklärt“ |
Sicht der ISTQB | Endekriterien (CTFL §5.1.3) | Testbedingungen (CTFL §4.5.2) | Eingangskriterien (CTFL §5.1.3) |
Typisches Risiko | Punkte ohne Nachweis | Nur Positivfälle beschrieben | Wird zum Stage-Gate |
Auch die DoD ordnet der Lehrplan ein: „In der agilen Softwareentwicklung werden die Endekriterien oft als Definition-of-Done bezeichnet, die die objektiven Metriken des Teams für ein freizugebendes Element definieren.“ (ISTQB CTFL Lehrplan 4.0.2, 2025)
Akzeptanzkriterien kommen aus dem Requirements Engineering. Der deutsche ISTQB-Lehrplan sagt, sie können „als die Testbedingungen betrachtet werden, die durch die Tests ausgeführt werden sollten“ (ISTQB CTFL Lehrplan 4.0.2, 2025). Wie Sie prüfbare Kriterien mit Positiv- und Negativszenarien schreiben, zeigt der Beitrag über Akzeptanzkriterien für User Stories.
Mike Cohn beschreibt die DoD als besondere Sammlung von Akzeptanzkriterien, die jeder User Story hinzugefügt wird (Mountain Goat Software, 2024). Vor der Definition of Ready warnt er: Sie kann ein großer Schritt in Richtung eines sequenziellen Stage-Gate-Vorgehens werden (Mountain Goat Software, 2016). Wer eine DoR einsetzt, hält sie kurz und nutzt sie als Gesprächsgrundlage im Refinement.
Warum gehören Regulierungspflichten in die DoD einer Bank?
In einer Bank ist die organisationsweite DoD der Ort, an dem regulatorische Mindestanforderungen an Tests und Änderungen in jeden Sprint gelangen. Der Scrum Guide liefert dafür die Regel: „Wenn die Definition of Done für ein Increment Teil der Standards der Organisation ist, müssen alle Scrum Teams diese als Mindestmaß befolgen.“ (Scrum Guide 2020, 2020)
Abbildung 3: Änderungsmanagement nach DORA-Verordnung (EU) Art. 9(4)(e)
Für Finanzunternehmen in der EU gilt seit dem 17. Januar 2025 die DORA-Verordnung (EU) 2022/2554. Art. 9 Abs. 4 Bst. e verlangt Richtlinien für das IKT-Änderungsmanagement, damit alle Änderungen an IKT-Systemen „auf kontrollierte Weise erfasst, getestet, bewertet, genehmigt, implementiert und überprüft werden“ (EUR-Lex, DORA, 2022).
Die delegierte Verordnung (EU) 2024/1774 wird konkreter. Art. 16 verlangt ein Verfahren für Test und Genehmigung aller IKT-Systeme vor ihrer Nutzung und nach Wartung. Art. 17 fordert, dass die genehmigende Funktion unabhängig von der umsetzenden ist (EUR-Lex, RTS 2024/1774, 2024).
Schweizer Banken unterliegen dem FINMA-Rundschreiben 2023/1, in Kraft seit 1. Januar 2024. Im Teil zum IKT-Risikomanagement verlangt es, dass funktionale und nicht-funktionale Anforderungen „gemäss ihrer Kritikalität getestet“ werden (FINMA-RS 2023/1, 2022). DORA betrifft eine Schweizer Bank nur über EU-Tochtergesellschaften oder Dienstleistungen in der EU.
Als DoD-Punkte für ein Bank-Team:
Jede Änderung ist in einem Ticket erfasst und mit ihren Tests verknüpft.
Die Tests sind nach der Kritikalität der Änderung ausgewählt, gelaufen und als Nachweis abgelegt.
Die Freigabe kommt von einer Person, die die Änderung nicht selbst umgesetzt hat.
Nach Wartung oder Hotfix laufen die betroffenen Tests erneut.
Die Richtlinie bleibt Aufgabe der Organisation; die DoD macht ihre Mindestpunkte Story für Story prüfbar. Die Verknüpfung von Anforderung, Testfall und Ergebnis liefert den Nachweis für das Wort „getestet“.
Wie sieht ein Definition of Done Beispiel aus?
Ein brauchbares DoD-Beispiel trennt Punkte, die die CI-Pipeline automatisch prüft, von Punkten, die Menschen prüfen. Die erste Gruppe lässt sich technisch erzwingen, die zweite braucht Disziplin und einen sichtbaren Nachweis. Die folgende Checkliste passt zu einem Scrum Team in einer Bank, das eine Web-Anwendung mit REST-API entwickelt.
DoD-Punkt | Prüfart | Nachweis |
|---|---|---|
Unit- und Integrationstests grün | Automatisiert in der Pipeline | Pipeline-Lauf |
Regressionstests der betroffenen Funktionen grün | Automatisiert in der Pipeline | Testbericht, Ergebnis am Ticket |
Akzeptanzkriterien der Story als Tests umgesetzt und bestanden | Automatisiert, Rest manuell | Verknüpfung Story zu Testfall |
Negativtests für neue Eingabefelder bestanden | Automatisiert in der Pipeline | Testbericht |
Statische Analyse ohne Befunde der Stufe hoch | Automatisiert in der Pipeline | Analysebericht |
Code-Review durch eine zweite Person | Manuell, Tool erzwingt Freigabe | Freigabe im Merge Request |
Explorativer Test der Story in fester Timebox | Manuell | Session-Notiz |
Keine offenen Fehler hoher Schwere | Manuell | Fehlerliste |
Änderung erfasst, Freigabe durch nicht umsetzende Person | Manuell | Audit-Trail im Ticket |
Mike Cohn nennt als Beispielpunkt, dass der Code mit automatisierten Tests auf allen passenden Ebenen kommt (Mountain Goat Software, 2024). Negativtests für neue Eingaben gehören in die Pipeline; wie Sie sie aus ungültigen Eingaben ableiten, steht im Beitrag zum Negativtest. Der explorative Test bleibt Handarbeit, mit fester Timebox pro Story und einer kurzen Notiz der Befunde.
Der Punkt „Regressionstests grün“ kostet in der Pflege am meisten. Jede Änderung an der Oberfläche kann Tests brechen lassen, die fachlich nichts Falsches prüfen. Wie gut Sie den Umfang Ihres Regressionstests schneiden, bestimmt, ob dieser Punkt Sprint für Sprint hält oder zur Ausrede wird.
Welche DoD-Punkte braucht KI-generierter Code?
KI-generierter Code braucht eigene DoD-Punkte: eine menschliche Durchsicht jeder generierten Änderung und automatisierte Tests, die vor dem Merge laufen. Die Daten stammen vom DORA-Forschungsprogramm (DevOps Research and Assessment) von Google Cloud, das mit der gleichnamigen EU-Verordnung nichts zu tun hat.
Im DORA-Report 2024 ging ein Anstieg der KI-Nutzung um 25 % mit 1,5 % weniger Liefer-Durchsatz und 7,2 % weniger Lieferstabilität einher (Google Cloud, DORA Report 2024, 2024). Der Report 2025 mit rund 5.000 Befragten zeigt: 90 % nutzen KI bei der Arbeit, 30 % haben wenig oder kein Vertrauen in KI-generierten Code (Google Cloud, DORA Report 2025, 2025).
Die Forschenden nennen starke automatisierte Tests, reife Versionskontrolle und schnelle Feedbackschleifen als Kontrollsysteme. Fehlen sie, führt laut Report ein höheres Änderungsvolumen zu Instabilität (Google Cloud, DORA Report 2025, 2025).
Daraus ergeben sich vier DoD-Punkte:
Eine Person hat jede KI-generierte Änderung gelesen und im Merge Request freigegeben.
Der Merge Request kennzeichnet, welche Teile von einem KI-Assistenten stammen.
Tests für generierten Code hat eine Person geprüft, bevor sie in die Suite kommen.
Die bestehende Regressionssuite läuft grün, bevor der Merge erfolgt.
Was unterscheidet die DoD von einem Quality Gate?
Die Definition of Done ist eine Vereinbarung des Teams über den Zustand des Increments, ein Quality Gate ist eine automatisierte Regel in der Pipeline, die einen Build bei Verstoß anhält. Ein Gate erzwingt den automatisierbaren Teil der DoD. Explorative Tests, fachliche Reviews und die Freigabe durch eine zweite Person bleiben Teamdisziplin.
Abbildung 4: Welche DoD-Punkte das Quality Gate prüft und welche das Team
Laut DORA-Forschungsprogramm sorgen Tests, die kontinuierlich in der Pipeline laufen, für schnelles Feedback an Entwickler:innen, kurze Durchlaufzeit vom Check-in bis zum Release und eine niedrige Fehlerquote in Produktion (DORA, Test Automation, o. J.). Welche Schwellen sich als Gate eignen, erklärt der Beitrag zu Quality Gates in der CI/CD-Pipeline. Den Aufbau der Pipeline selbst beschreibt der Artikel über Testautomatisierung in CI/CD.
Autemos, die KI-gestützte Testautomatisierung von selementrix, senkt den Pflegeaufwand für einen einzelnen DoD-Punkt: „Regressionstests grün“. Findet ein Locator nach einer UI-Änderung sein Element nicht mehr, greift das Self-Healing von Autemos. Jede Heilung wird dokumentiert und lässt sich zurücknehmen.
Die Testergebnisse synchronisiert Autemos bidirektional mit Jira und Xray, der Nachweis liegt damit direkt am Ticket. Die DoD selbst, Akzeptanzkriterien, Last- und Performancetests, Sicherheits- und Penetrationstests oder Codeabdeckung deckt Autemos nicht ab.
Wie führen Sie eine DoD ein?
Eine Definition of Done führen Sie in fünf Schritten ein, beginnend beim Mindeststandard Ihrer Organisation und endend mit einer regelmäßigen Überprüfung im Team.
Mindeststandard übernehmen. Klären Sie, ob Ihre Organisation eine Definition of Done vorgibt, etwa aus der Richtlinie zum Änderungsmanagement. Gibt es keine, muss das Scrum Team laut Scrum Guide „eine für das Produkt geeignete Definition of Done erstellen“. Arbeiten mehrere Teams an einem Produkt, gilt für alle dieselbe DoD.
Teampunkte ergänzen. Das Team fügt Punkte hinzu, die zum Produkt passen, zum Beispiel Barrierefreiheit einer Web-Oberfläche.
Jeden Punkt prüfbar machen. Vage Punkte wie „Code ist sauber“ ersetzen Sie durch messbare, etwa „Statische Analyse ohne Befunde der Stufe hoch“.
Automatisierbares in die Pipeline verschieben. Was ein Werkzeug prüfen kann, wird ein Quality Gate. Der Rest bekommt einen Nachweis im Ticket.
Regelmäßig überprüfen. Werden Punkte Sprint für Sprint gebrochen, ändert das Team bewusst die Liste oder die Arbeitsweise.
Häufige Fehler bei der DoD
Story-spezifische Anforderungen landen in der DoD. Sie gehören in die Akzeptanzkriterien.
Am Sprintende fallen einzelne Punkte stillschweigend weg. Laut Scrum Guide geht der Eintrag dann zurück ins Product Backlog.
Die Definition of Ready wird zur Schranke, die Stories wochenlang vor dem Sprint festhält.
Die Liste enthält Punkte, die niemand prüft oder nachweist.
Häufig gestellte Fragen
Ist die DoD in Scrum verpflichtend?
Ja, laut Scrum Guide 2020 sind die Developer:innen verpflichtet, der DoD zu entsprechen. Sie ist das Commitment des Increments. Ein Product-Backlog-Eintrag, der sie nicht erfüllt, darf weder released noch im Sprint Review präsentiert werden und geht zurück ins Product Backlog (Scrum Guide 2020, 2020).
Was ist der Unterschied zwischen DoD und Akzeptanzkriterien?
Die DoD gilt für jedes Increment, Akzeptanzkriterien gelten für eine einzelne User Story. Die DoD beschreibt produktweite Qualitätsmaßnahmen wie grüne Regressionstests. Akzeptanzkriterien beschreiben das fachliche Verhalten einer Story und sind laut ISTQB-Lehrplan 4.0.2 die Testbedingungen, die Tests abdecken sollen (ISTQB CTFL Lehrplan 4.0.2, 2025).
Steht die Definition of Ready im Scrum Guide?
Nein, die Definition of Ready kommt im Scrum Guide 2020 nicht vor. Der Guide beschreibt nur, dass Einträge, die das Team innerhalb eines Sprints fertigstellen kann, als bereit für die Auswahl im Sprint Planning gelten. Mike Cohn warnt, eine starre DoR könne zu einem Stage-Gate-Vorgehen führen (Mountain Goat Software, 2016).
Gilt die DORA-Verordnung für Schweizer Banken?
Direkt gilt die DORA-Verordnung seit dem 17. Januar 2025 nur für Finanzunternehmen in der EU. Schweizer Banken betrifft sie über EU-Tochtergesellschaften oder Dienstleistungen in der EU. Für Schweizer Banken gilt das FINMA-Rundschreiben 2023/1, in Kraft seit 1. Januar 2024, mit Anforderungen an das IKT-Risikomanagement (FINMA-RS 2023/1, 2022).
Lässt sich eine DoD automatisiert prüfen?
Teilweise: Tests, statische Analyse und Build-Regeln prüft ein Quality Gate in der CI-Pipeline automatisch. Manuell bleiben alle Prüfungen, die Urteilsvermögen brauchen, etwa das Erkunden einer Story oder das Vier-Augen-Prinzip bei der Freigabe. Laut DORA-Forschungsprogramm tragen kontinuierlich laufende Tests zu einer kurzen Durchlaufzeit vom Check-in bis zum Release bei (DORA, Test Automation, o. J.).
Fazit
Die Definition of Done legt fest, welche Qualitätsmaßnahmen jedes Increment erfüllen muss, und der Scrum Guide 2020 macht sie verbindlich. Sie gilt für alle Backlog-Einträge. Akzeptanzkriterien beschreiben die einzelne Story, die Definition of Ready ist eine freiwillige Teampraxis. In Banken trägt die organisationsweite DoD die regulatorischen Mindestpunkte: Änderungen erfassen, testen, unabhängig freigeben und nach Wartung erneut testen. Trennen Sie in Ihrer Checkliste die Punkte, die ein Quality Gate automatisch prüft, von den manuellen und explorativen. Für KI-generierten Code gehören menschliche Durchsicht und grüne Tests vor dem Merge dazu. Wenn Sie den Punkt „Regressionstests grün“ mit dokumentiertem Self-Healing halten und die Ergebnisse als Nachweis in Jira und Xray haben möchten, sprechen Sie mit dem Autemos-Team.
