Definition of Ready vs. Definition of Done: So bringst Du Klarheit ins Team

Was ist die Definition of Ready (DoR)?

Die Definition of Ready beschreibt die Kriterien, die ein Backlog Item erfüllen muss, bevor Dein Team mit der Umsetzung beginnen kann.
Typische Kriterien sind:

• Akzeptanzkriterien sind klar formuliert.
• Abhängigkeiten sind bekannt oder gelöst.
• Alle benötigten Informationen sind vorhanden.
• Das Item ist so geschnitten, dass es in einem Sprint umgesetzt werden kann.

Kurz gesagt: Ein Ticket ist „ready“, wenn das Team sofort loslegen kann, ohne noch Fragen oder Blocker zu klären.

‍

Was ist die Definition of Done (DoD)?

Die Definition of Done beschreibt, wann ein Item wirklich abgeschlossen ist. Sie stellt sicher, dass alle Qualitäts- und Abnahmekriterien erfüllt sind.
Beispiele für Kriterien:

• Code ist geschrieben, getestet und gemergt.
• Dokumentation ist aktualisiert.
• QA hat das Feature abgenommen.
• Stakeholder können es im Produkt nutzen.

„Done“ bedeutet nicht nur, dass etwas „funktioniert“ – sondern dass es vollständig lieferbar ist.

‍

Warum die Unterscheidung so wichtig ist

Viele Teams verwechseln DoR und DoD oder haben keine klaren Definitionen. Die Folgen:

• Tickets starten zu früh → Entwickler blockieren sich, weil Infos fehlen.
• Tickets werden zu früh als fertig markiert → Nacharbeit in QA oder Doku kostet Zeit.
• Missverständnisse zwischen Business und Tech → Stakeholder denken, etwas sei live, obwohl es noch nicht freigegeben ist.
  ‍

Wenn Dein Team dagegen klare Kriterien für Ready und Done hat, entstehen:

• weniger Diskussionen,
• höhere Qualität,
• transparente Fortschritte.
  ‍

Praxisbeispiel: Ein Team ohne Klarheit

Ein SaaS-Team startete regelmäßig mit halbfertigen Tickets. Während des Sprints stellte sich heraus, dass noch Akzeptanzkriterien fehlten. Entwickler mussten nachfragen, Product Owner ergänzen. Am Ende waren die Items nie wirklich abgeschlossen, und der Sprint Review war chaotisch.

Erst als das Team eine klare Definition of Ready festlegte („Keine Stories ohne Akzeptanzkriterien“) und eine Definition of Done ergänzte („Keine Story ohne automatisierten Test abgeschlossen“), verbesserte sich die Lage. Plötzlich waren die Sprints planbarer – und die Qualität der Auslieferungen stieg.

‍

Wie Du Ready und Done in Deinem Team einführst

1. Workshop mit dem Team:
   Erkläre den Unterschied zwischen Ready und Done. Lasse die Entwickler und QA selbst Vorschläge machen.
2. Konkrete Kriterien festlegen:
   Keine vagen Formulierungen wie „gut dokumentiert“. Stattdessen klare Aussagen wie „Akzeptanzkriterien in Jira eingetragen“.
3. Visualisieren:
   Hänge Ready- und Done-Kriterien im Teamraum oder digital im Board auf. So sind sie jederzeit sichtbar.
4. Regelmäßig prüfen:
   In Retrospektiven: Werden die Kriterien eingehalten? Müssen sie angepasst werden?
   ‍

Typische Fehler und wie Du sie vermeidest

• Fehler 1: DoR ist zu umfangreich → Tickets kommen nie ins Sprint Planning.
  Tipp: Konzentriere Dich auf 3–5 Kriterien.
• Fehler 2: DoD ist zu technisch formuliert („Code compiled“) → Kein Mehrwert für Stakeholder.
  Tipp: Immer auch den Nutzer- oder Business-Impact einbeziehen.
• Fehler 3: DoR und DoD werden einmal erstellt und nie angepasst.
  Tipp: Agil heißt auch hier: Regeln regelmäßig weiterentwickeln.
  ‍

So profitieren Product Owner direkt

Für Dich als PO bieten DoR und DoD klare Vorteile:

• Bessere Planbarkeit: Du weißt, welche Tickets realistisch im Sprint umgesetzt werden können.
• Weniger Nacharbeit: Stories sind wirklich abgeschlossen und verursachen keine Schleifen.
• Mehr Vertrauen: Stakeholder sehen, dass „done“ auch wirklich „done“ bedeutet.
• Klare Kommunikation: Dein Team spricht dieselbe Sprache.
  ‍

Klarheit bringt Geschwindigkeit

Definition of Ready und Definition of Done sind keine Formalitäten – sie sind die Basis für effiziente Zusammenarbeit im agilen Umfeld. Wenn Dein Team weiß, wann ein Ticket „bereit“ und wann es „wirklich fertig“ ist, vermeidest Du Missverständnisse, sparst Zeit und erhöhst die Qualität.

Fang klein an: Definiere 3 Kriterien für Ready und 3 für Done. Setze sie in Deinem Team um und überprüfe regelmäßig, wie sie wirken. Schon nach wenigen Sprints wirst Du merken: Klarheit ist einer der größten Produktivitäts-Booster.

‍

Du willst mehr Klarheit in Dein Projektmanagement bringen – ohne endlose Nacharbeit? Teste LastTycket jetzt kostenlos und erlebe, wie automatisierte Dokumentation Dein Team unterstützt.

‍

‍

FAQ - Häufig gestellte Fragen

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

Die Definition of Ready (DoR) sorgt dafür, dass ein Backlog Item so vorbereitet ist, dass das Team sofort starten kann. Die Definition of Done (DoD) definiert, wann ein Item wirklich abgeschlossen, getestet und lieferbar ist. Beide zusammen schaffen Klarheit und verhindern Missverständnisse.

Warum sind Ready und Done entscheidend für agile Teams?

Ohne klare Definitionen entstehen Verzögerungen: Stories starten zu früh, Features werden unfertig ausgeliefert. Mit DoR und DoD schafft Dein Team eine gemeinsame Sprache, die die Qualität steigert und die Zusammenarbeit beschleunigt.

Wie viele Kriterien sollte eine DoR oder DoD enthalten?

Für die Praxis haben sich 3–5 konkrete Kriterien bewährt. Zu viele Regeln führen zu Overhead, zu wenige bringen keine Klarheit. Der Fokus sollte auf überprüfbaren Punkten liegen – zum Beispiel klare Akzeptanzkriterien oder automatisierte Tests.

Wer ist verantwortlich für die Definitionen?

DoR und DoD werden vom gesamten Team festgelegt – nicht nur vom Product Owner. Nur wenn Entwickler, QA und PO die Kriterien gemeinsam erarbeiten, entstehen Regeln, die akzeptiert und gelebt werden.

Wie oft sollten Ready und Done überprüft werden?

Agile Prozesse sind dynamisch. Deshalb solltest Du Deine Kriterien mindestens einmal pro Quartal in einer Retrospektive prüfen. Wenn Dein Team neue Tools, Workflows oder Stakeholder einführt, lohnt sich eine sofortige Anpassung.