Was ist die Definition of Ready?
Die Definition of Ready (DoR) legt fest, welche Kriterien ein Backlog Item erfüllen muss, bevor es in einen Sprint aufgenommen werden kann. Einfach ausgedrückt: Eine Aufgabe ist „ready”, wenn alle notwendigen Informationen vorhanden sind, damit Ihr Team sie verstehen und bearbeiten kann.
Im Product Backlog – der Liste aller geplanten Aufgaben in einem Projekt – sammeln sich verschiedenste Aufgaben an. Viele davon sind anfangs noch vage formuliert oder enthalten nicht genügend Details für eine konkrete Umsetzung. Die DoR fungiert hier als Filter und stellt sicher, dass nur gut vorbereitete Aufgaben den Weg ins Team finden.
Diese Vorbereitung geschieht während des Product Backlog Refinements (auch Backlog Grooming genannt). In diesem Prozess werden Aufgaben gemeinsam durchgesprochen, präzisiert und mit allen notwendigen Details versehen, bis sie die „Ready”-Kriterien erfüllen.
Interessanterweise definiert der offizielle Scrum Guide keine formale Definition of Ready. Stattdessen spricht er davon, dass Backlog Items als „ready for selection” gelten, wenn sie innerhalb eines Sprints abgeschlossen werden können. Trotzdem nutzen viele Teams eine DoR als praktisches Werkzeug im Alltag.
Eine typische Definition of Ready könnte so aussehen:
Klare Beschreibung: Die Aufgabe ist verständlich formuliert und alle im Team wissen, worum es geht.
Akzeptanzkriterien: Es ist eindeutig definiert, wann die Aufgabe erfolgreich umgesetzt ist
Schätzung: Das Team hat den Aufwand bewertet und weiß, wie viel Zeit die Umsetzung voraussichtlich benötigt
Was ist die Definition of Done?
Die Definition of Done (DoD) beschreibt präzise den Zustand, den ein Increment erreichen muss, um die geforderten Qualitätsstandards zu erfüllen. Ein Increment ist dabei das konkrete Arbeitsergebnis – etwa ein fertiges Feature, eine implementierte Funktion oder eine abgeschlossene User Story.
Im Gegensatz zur DoR ist die DoD im Scrum Guide offiziell verankert und gilt verbindlich für alle Teammitglieder. Sie schafft Transparenz, indem sie ein gemeinsames Verständnis im Team etabliert, was „fertig” wirklich bedeutet.
Die Definition of Done verfolgt drei zentrale Ziele:
Transparenz schaffen: Jede:r im Team und alle Stakeholder:innen verstehen, was „Done” bedeutet.
Qualität sichern: Nur Arbeit, die alle definierten Standards erfüllt, gilt als abgeschlossen
Klarheit für Releases: Ausschließlich Done-Items können veröffentlicht oder im Sprint Review präsentiert werden
Was passiert, wenn eine Aufgabe die DoD nicht erfüllt? Die Konsequenzen sind eindeutig: Sie kann weder released noch im Sprint Review gezeigt werden. Stattdessen wandert sie zurück ins Product Backlog und wartet dort auf weitere Bearbeitung.
Viele Organisationen etablieren eine unternehmensweite DoD, die alle Teams mindestens einhalten. Falls keine solche Standard-Definition existiert, erstellt das Scrum-Team seine eigene. Bei mehreren Teams, die am selben Produkt arbeiten, gilt eine gemeinsame Definition of Done für alle.
Eine praxisnahe DoD könnte diese Punkte enthalten:
Code ist getestet: Alle Unit-Tests laufen erfolgreich durch
Dokumentation ist aktualisiert: Technische Änderungen sind dokumentiert
Code Review durchgeführt: Mindestens ein anderes Teammitglied hat den Code geprüft und abgenommen
Unterschiede zwischen Ready und Done
Die beiden Konzepte ergänzen sich perfekt, wirken aber zu völlig unterschiedlichen Zeitpunkten im Entwicklungsprozess. Hier die wichtigsten Unterschiede im Überblick:
Aspekt
Definition of Ready
Definition of Done
Zeitpunkt
Vor Beginn der Bearbeitung
Nach Abschluss der Arbeit
Zweck
Aufgabe ist bereit zum Start
Aufgabe erfüllt alle Qualitätsstandards
Verbindlichkeit
Nicht im Scrum Guide formalisiert
Im Scrum Guide verankert
Verantwortung
Product Owner und Team gemeinsam
Entwickler:innen (Developers)
Während die DoR sicherstellt, dass Teams nicht mit unklaren oder unvollständigen Aufgaben starten, garantiert die DoD, dass nur qualitativ hochwertige Arbeit als abgeschlossen gilt. Zusammen bilden sie einen Qualitätsrahmen, der reibungslose Abläufe im agilen Projektmanagement ermöglicht.
Warum sind diese Definitionen im agilen Projektmanagement wichtig?
Stellen Sie sich vor, Ihr Team startet mit der Entwicklung einer neuen Funktion, aber niemand weiß genau, was es eigentlich bauen soll. Oder noch schlimmer: Nach wochenlanger Arbeit diskutiert das Team immer noch, ob die Aufgabe wirklich fertig ist. Genau diese Probleme lösen DoR und DoD.
Die praktischen Vorteile zeigen sich im Arbeitsalltag:
Transparenz im Team: jede:r weiß genau, wann eine Aufgabe startbereit ist und wann sie als erledigt gilt
Bessere Zusammenarbeit: klare Kriterien verhindern endlose Diskussionen und Missverständnisse
Verlässliche Planung: Teams können realistischer einschätzen, was im nächsten Sprint machbar ist
Höhere Qualität: die DoD verhindert, dass halbfertige Lösungen als „fertig” durchgehen
Schnellerer Fortschritt: weniger Nacharbeit und Korrekturen, weil Anforderungen von Anfang an klar sind
Im Scrum-Prozess strukturieren DoR und DoD den gesamten Arbeitsfluss. Von der Planung im Sprint Planning über die tägliche Umsetzung bis zur Präsentation im Sprint Review – beide Definitionen geben klare Leitplanken vor. Obwohl sie besonders in Scrum verbreitet sind, funktionieren diese Konzepte auch in anderen agilen Methoden wie Kanban oder sogar in traditionelleren Projektmanagement-Ansätzen.
Wer bestimmt DoR und DoD im Team?
Die Verantwortlichkeiten für beide Definitionen sind klar verteilt, wobei die Zusammenarbeit aller Beteiligten entscheidend für den Erfolg ist.
Bei der Definition of Ready arbeiten Product Owner und Entwicklungsteam Hand in Hand. Der/die Product Owner:in sorgt dafür, dass Backlog Items klar und verständlich formuliert sind. Die Entwickler:innen prüfen, ob sie die Aufgabe verstehen und den Aufwand realistisch einschätzen können. Gemeinsam entwickeln sie während des Product Backlog Refinements die DoR-Kriterien.
Die Definition of Done liegt primär in der Verantwortung der Entwickler:innen. Der Scrum Guide betont ausdrücklich ihre Rolle bei der Qualitätssicherung durch Einhaltung der DoD. Trotzdem entwickelt das gesamte Scrum-Team – Product Owner:in, Scrum Master:in und Entwickler:innen – die Definition gemeinsam. Arbeiten mehrere Teams am selben Produkt, müssen alle Teams dieselbe DoD verwenden.
Der Schlüssel zum Erfolg: Beide Definitionen funktionieren nur, wenn alle Teammitglieder sie verstehen und mittragen. Es sind keine von oben verordneten Regeln, sondern gemeinsam erarbeitete Vereinbarungen.
Beispiele für konkrete Kriterien
Theoretisches Wissen ist gut, aber konkrete Beispiele machen DoR und DoD erst richtig greifbar. Die folgenden Beispiele zeigen, wie diese Definitionen in der Praxis aussehen können. Denken Sie daran: Jedes Team passt die Kriterien an seine spezifischen Anforderungen und Arbeitsweisen an.
Beispiel für eine Definition of Ready
Eine User Story gilt in vielen Teams als „Ready”, wenn folgende Punkte erfüllt sind:
Titel und Beschreibung vorhanden: die Aufgabe ist klar formuliert (z. B. „Als Nutzer:in möchte ich mein Passwort zurücksetzen können.”)
Akzeptanzkriterien definiert: es ist eindeutig beschrieben, wann die Aufgabe erfolgreich umgesetzt ist
Abhängigkeiten geklärt: alle blockierenden Faktoren sind identifiziert und gelöst
Schätzung durchgeführt: das Team hat den Aufwand in Story Points oder Stunden bewertet
Design/Mockups verfügbar: falls benötigt, liegen visuelle Entwürfe oder Wireframes vor
Technische Machbarkeit geprüft: keine offenen technischen Fragen oder Unklarheiten mehr vorhanden
Mit diesen Kriterien kann Ihr Team sicher sein, dass die Aufgabe im Sprint ohne größere Überraschungen bearbeitet werden kann.
Beispiel für eine Definition of Done
Eine Aufgabe erfüllt die Definition of Done erst, wenn alle folgenden Punkte abgehakt sind:
Code geschrieben und committed: alle Änderungen sind im Versionskontrollsystem (z. B. Git) gespeichert
Unit-Tests erstellt: automatisierte Tests decken die neue Funktionalität ab und laufen erfolgreich
Code Review abgeschlossen: mindestens ein anderes Teammitglied hat den Code geprüft und freigegeben
Integrationstests erfolgreich: die neue Funktion arbeitet reibungslos mit dem Rest des Systems zusammen
Dokumentation aktualisiert: sowohl technische Dokumentation als auch Benutzerhandbücher sind auf dem neuesten Stand
Akzeptanzkriterien erfüllt: alle in der User Story definierten Anforderungen sind umgesetzt
Keine bekannten Bugs: kritische Fehler sind behoben, kleinere Issues sind dokumentiert
Erst wenn wirklich alle Punkte erfüllt sind, gilt die Aufgabe als abgeschlossen und kann Teil des Increments werden.
Tipps zur Einführung von DoR und DoD im Team
Die Einführung von DoR und DoD erfordert Geduld und die Bereitschaft des gesamten Teams. Mit den folgenden Tipps gelingt die Implementierung reibungslos.
Schrittweises Aufstellen der Kriterien
Versuchen Sie nicht, von Anfang an die perfekte Definition zu erstellen. Starten Sie stattdessen mit wenigen, aber wichtigen Kriterien. In einem gemeinsamen Workshop sammeln Sie die Punkte, die allen Teammitgliedern am Herzen liegen.
Halten Sie die erste Version bewusst schlank – drei bis fünf Kriterien reichen völlig aus. Mit jedem Sprint sammeln Sie neue Erfahrungen und können die Definitionen entsprechend erweitern oder anpassen. Denken Sie daran: Agiles Arbeiten bedeutet kontinuierliche Verbesserung, und das gilt auch für DoR und DoD.
Team-Kommunikation sicherstellen
Transparenz ist der Schlüssel zum Erfolg. Besprechen Sie beide Definitionen regelmäßig im gesamten Team, nicht nur in kleinen Gruppen. Das Sprint Planning bietet den perfekten Rahmen, um zu prüfen, ob alle Aufgaben wirklich „Ready” sind.
In der Sprint Retrospektive können Sie gemeinsam evaluieren, wie gut DoR und DoD funktioniert haben. Dokumentieren Sie beide Definitionen an einem zentralen Ort, auf den alle Teammitglieder jederzeit zugreifen können – beispielsweise in einem Projektmanagement-Tool wie MeisterTask. So vermeiden Sie Missverständnisse und schaffen klare Verhältnisse.
Regelmäßige Überprüfung und Anpassung
Planen Sie feste Zeitpunkte ein, um Ihre Definitionen zu überprüfen – etwa alle zwei bis drei Sprints. Stellen Sie dabei folgende Fragen:
Welche Kriterien haben sich bewährt?
Wo gab es trotz DoR oder DoD Probleme?
Haben sich die Projektanforderungen geändert?
Gibt es neue Erkenntnisse aus der täglichen Arbeit?
Holen Sie Feedback von allen Beteiligten ein, auch von Stakeholdern außerhalb des Entwicklungsteams. Starre Definitionen widersprechen dem agilen Gedanken – bleiben Sie flexibel und passen Sie die Kriterien an veränderte Bedingungen an.
Häufige Fehler und wie Sie diese vermeiden
Auch erfahrene Teams stolpern bei der Anwendung von DoR und DoD über typische Fallstricke. Wenn Sie diese kennen, können Sie sie von Anfang an umgehen.
Fehlende Klarheit bei den Kriterien
Vage formulierte Kriterien sind der häufigste Fehler. Was bedeutet „ausreichend dokumentiert”? Wie viel ist „genug getestet”? Solche schwammigen Formulierungen führen zu unterschiedlichen Interpretationen und endlosen Diskussionen.
Formulieren Sie stattdessen messbare und überprüfbare Kriterien:
Statt: „Code ist kommentiert”
Besser: „Alle öffentlichen Methoden haben einen Dokumentationskommentar”
Besprechen Sie im Team genau, was jedes Kriterium bedeutet, und dokumentieren Sie diese Vereinbarungen. Je präziser Ihre Definitionen, desto reibungsloser läuft die Zusammenarbeit.
Unterschätzte Dokumentation und Tests
Viele Teams konzentrieren sich auf die reine Entwicklung und vergessen dabei Dokumentation und Tests. Das rächt sich spätestens im nächsten Sprint, wenn Bugs auftauchen oder neue Teammitglieder sich nicht zurechtfinden.
Tests und Dokumentation gehören von Anfang an in die DoD. Sie sind keine lästige Pflicht, sondern ein Investment in die Zukunft Ihres Projekts. Technische Schulden durch fehlende Tests oder Dokumentation holen Sie früher oder später ein – meist dann, wenn Sie es am wenigsten gebrauchen können.
Fehlendes Team-Commitment
DoR und DoD funktionieren nur, wenn das gesamte Team dahintersteht. Werden sie von einzelnen Personen oder der Führungsebene vorgegeben, fehlt die Akzeptanz. Die Folge: Kriterien werden ignoriert, umgangen oder nur halbherzig umgesetzt.
Investieren Sie Zeit in gemeinsame Workshops zur Erstellung der Definitionen. Jedes Teammitglied sollte seine Perspektive einbringen können. Dieses gemeinsame Erarbeiten schafft Verständnis und Verbindlichkeit – die Grundlage für erfolgreiche Anwendung im Alltag.
Der nächste Schritt zum erfolgreichen Projektabschluss
Definition of Ready und Definition of Done mögen auf den ersten Blick wie zusätzliche Bürokratie wirken. In Wahrheit sind sie jedoch mächtige Werkzeuge, die Ihrem Team Klarheit, Struktur und Qualität bringen.
Die DoR stellt sicher, dass Sie nur mit gut vorbereiteten Aufgaben starten. Die DoD garantiert, dass nur wirklich fertige Arbeit als abgeschlossen gilt. Gemeinsam schaffen sie einen Rahmen, in dem Teams effektiv zusammenarbeiten und hochwertige Ergebnisse liefern können.
Beginnen Sie klein: Entwickeln Sie mit Ihrem Team erste, einfache Versionen beider Definitionen. Nutzen Sie die Beispiele aus diesem Artikel als Inspiration, aber passen Sie sie an Ihre spezifischen Bedürfnisse an.
Mit einem Tool wie MeisterTask können Sie DoR und DoD direkt in Ihren Arbeitsablauf integrieren. Erstellen Sie Checklisten für Ihre Kriterien, dokumentieren Sie Ihre Definitionen und behalten Sie den Überblick über den Status aller Aufgaben. Starten Sie noch heute Ihre kostenlose Testphase und erleben Sie, wie klare Definitionen Ihre Projektarbeit spürbar verbessern.
