Die Definition of Done (DoD, deutsch: Fertigstellungsdefinition) ist eine verbindliche Checkliste von Qualitaetskriterien, die erfuellt sein müssen, damit eine Aufgabe, ein Feature oder ein Sprint-Inkrement als "fertig" gilt. In Scrum und anderen agilen Frameworks ist die DoD ein zentrales Instrument gegen das "Zu 90 % fertig"-Problem, bei dem Aufgaben endlos in einem Fast-Fertig-Zustand verharren.
Ohne klare DoD interpretiert jedes Teammitglied "fertig" anders. Das führt zu inkonsistenter Qualitaet, versteckten Resttaetigkeiten und wachsender Technical Debt.
Warum eine DoD unverzichtbar ist
Qualitaetssicherung
Die DoD definiert den Mindeststandard, den jede Lieferung erfuellen muss. Ohne sie werden Qualitaetsprufungen uebersprungen, wenn die Zeit knapp wird.
Transparenz
Alle Beteiligten, Team, Product Owner und Stakeholder, haben ein gemeinsames Verständnis davon, was "fertig" bedeutet.
Planungsgenauigkeit
Wenn die DoD klar ist, kann das Team den Aufwand für Aufgaben realistischer schaetzen, weil Review, Testing und Dokumentation einberechnet werden.
Vermeidung von Nacharbeit
Eine strenge DoD verhindert, dass "Kleinigkeiten" auf später verschoben werden und sich als versteckte Aufwaende akkumulieren.
DoD für Webdesign-Projekte
Beispiel-DoD für Frontend-Aufgaben
| Kriterium | Beschreibung |
|---|---|
| Funktional korrekt | Feature funktioniert wie in der User Story beschrieben |
| Responsive | Getestet auf Mobile (<735px), Tablet (735-1068px), Desktop (>1068px) |
| Cross-Browser | Funktioniert in Chrome, Firefox, Safari, Edge (aktuelle Versionen) |
| Barrierefreiheit | Mindestkontrast 4.5:1, Keyboard-Navigation, Screenreader-tauglich |
| Code Review | Von mindestens einer weiteren Person reviewed und approved |
| Tests bestanden | Alle automatisierten Tests sind gruen |
| Performance | Keine Verschlechterung der Core Web Vitals |
| SEO | Meta-Tags gesetzt, Structured Data vorhanden, Bilder mit Alt-Text |
| Dokumentation | Änderungen in der Projektdokumentation nachgefuehrt |
| Deployment-Ready | Kann ohne manuelle Eingriffe deployed werden |
Beispiel-DoD für Design-Aufgaben
| Kriterium | Beschreibung |
|---|---|
| Design-System konform | Verwendet Farben, Typografie und Spacing aus dem Design System |
| Alle Zustaende | Normal, Hover, Active, Focus, Disabled, Error, Loading |
| Responsive Varianten | Mobile, Tablet, Desktop in Figma angelegt |
| Developer Handoff | Specs, Assets und Animationsbeschreibungen dokumentiert |
| Kundenfeedback | Vom Product Owner oder Kunden abgenommen |
Beispiel-DoD für Content-Aufgaben
| Kriterium | Beschreibung |
|---|---|
| Inhaltlich korrekt | Fakten geprüft, keine Halluzinationen bei KI-gestuetztem Content |
| SEO-optimiert | Ziel-Keyword integriert, Meta-Description geschrieben, interne Links gesetzt |
| Lektoriert | Rechtschreibung und Grammatik geprüft |
| Formatiert | H2/H3-Struktur, Absaetze, Listen und Tabellen wo sinnvoll |
| Bilder | Optimierte Bilder mit Alt-Text und korrekt dimensioniert |
| Freigegeben | Vom Kunden oder Redaktionsleiter abgenommen |
DoD erstellen: Schritt für Schritt
Schritt 1: Team-Workshop
Alle Teammitglieder sammeln Kriterien, die für "echte Fertigstellung" relevant sind. Brainstorming ohne Filterung.
Schritt 2: Priorisieren und vereinfachen
Zu viele Kriterien machen die DoD unpraktikabel. Fokussieren Sie auf die 8-12 wichtigsten Punkte, die den größten Qualitaetsunterschied machen.
Schritt 3: Konsens herstellen
Jedes Teammitglied muss die DoD akzeptieren und sich daran gebunden fuehlen. Keine aufgezwungenen Kriterien.
Schritt 4: Sichtbar machen
Haengen Sie die DoD physisch ans Teamboard oder pinnen Sie sie im digitalen Projektmanagement-Tool (Kanban-Board, Jira, Notion).
Schritt 5: Regelmäßig überprüfen
In jeder Sprint-Retrospektive: Ist unsere DoD noch aktuell? Brauchen wir strengere oder pragmatischere Kriterien?
DoD auf verschiedenen Ebenen
Die Definition of Done kann auf mehreren Ebenen definiert werden:
- Story-Ebene: Einzelne User Stories oder Aufgaben
- Sprint-Ebene: Zusaetzliche Kriterien für das gesamte Sprint-Inkrement (z. B. Regressionstests bestanden)
- Release-Ebene: Anforderungen für eine Veröffentlichung (z. B. Staging-Test durch Kunden, Performance-Audit)
Je höher die Ebene, desto umfassender die Kriterien. Eine strenge Release-DoD kann auch Punkte wie Lighthouse-Score über 90, keine offenen Bugs mit Prioritaet "Hoch" und vollstaendige Analytics-Integration umfassen.