HelloAgile® eine Marke der HelloNew GmbH & Co. KG
Mosbacher Straße 9, 65187 Wiesbaden
HelloAgile Blog

Definition of Ready: Was sie ist, woher sie kommt & warum sie so wichtig ist

In der agilen Produktentwicklung ist gute Vorbereitung der halbe Erfolg. Die Definition of Ready (DoR) sorgt dafür, dass ein Arbeitselement erst dann begonnen wird, wenn es wirklich „startklar“ ist – und das für alle Beteiligten eindeutig.

David Hillmer

13.5.2025

Eine Person erklärt zwei weiteren die Definition of Ready in einem Workshop

Was ist die Definition of Ready?

Die Definition of Ready (DoR) ist einegemeinsam getroffene Vereinbarung im agilen Team darüber, wann ein Arbeitselement als ausreichend vorbereitet gilt, um in einem Sprint bearbeitet zu werden. Sie funktioniert wie ein Qualitätsfilter für die Arbeit im Backlog: Nur wenn ein Item bestimmte, im Voraus festgelegte Kriterien erfüllt,darf es in die Umsetzung gehen.

Ein typisches Beispiel: Eine User Story enthälteine Beschreibung, Akzeptanzkriterien, eine Aufwandsschätzung und allenotwendigen Informationen oder Zugänge, die das Team für die Bearbeitungbraucht. Erst dann gilt sie als „ready“.

Wichtig ist: Die Definition of Ready ist kein starres Regelwerk, sondern ein lebendiges Agreement, das vom Teamgemeinsam erarbeitet und regelmäßig angepasst wird. Was für ein erfahrenes Scrum Team als „bereit“ gilt, kann für ein neu formiertes Team noch zu vagesein – deshalb sollte die DoR immer zum Reifegrad und zur Arbeitsweise desTeams passen.

Darüber hinaus hilft die DoR auch dabei, Verantwortlichkeiten zu klären: Sie macht sichtbar, ob z. B. noch Input vom Product Owner fehltoder externe Abhängigkeiten zu klären sind. So können potenzielle Stolpersteinefrühzeitig erkannt und behoben werden – bevor sie mitten im Sprint zumProblem werden.

In der Praxis erleichtert die Definition of Readynicht nur die Sprint-Planung, sondern schafft auch Vertrauen zwischen Product Owner und Entwicklungsteam: Beide Seiten wissen, dass nur gutvorbereitete Stories in die Umsetzung kommen – und dass es dafür klare,gemeinsame Standards gibt.

Woher stammt die Idee?

 

Die Ursprünge der DoR lassen sich auf die Werte und Prinzipien des Agilen Manifests von 2001 zurückführen. Zwar wird derBegriff dort nicht direkt genannt, doch das Bedürfnis nach Transparenz, Klarheit und Zusammenarbeit bildet den konzeptionellen Nährboden.
Agilisten wie Ken Schwaber und Jeff Sutherland, die Mitbegründervon Scrum, haben das Konzept maßgeblich geprägt. Ihre Betonung derNotwendigkeit klarer Voraussetzungen vor Beginn eines Sprints führte dazu, dasssich in der Praxis die Definition of Ready als Standard etablierte. Die agileCommunity hat diesen Gedanken weiterentwickelt – heute ist die DoR in vielenTeams ein zentrales Werkzeug.

 

Warum ist die Definition of Ready wichtig?

Die Definition of Ready (DoR) sorgt dafür, dass ein Arbeitselement erst dann in Angriff genommen wird, wenn es vollständigvorbereitet ist. Ohne eine klare DoR können unvollständige oder unklareAufgaben zu Missverständnissen und unnötigen Verzögerungen führen. Sie hat mehrere wesentliche Vorteile:

  1. Vermeidung  von Missverständnissen: Eine klare DoR sorgt dafür,  dass alle Teammitglieder das selbe Verständnis vom Arbeitselement haben und  die Anforderungen eindeutig sind.
  2. Effizientere  Arbeit: Mit einer DoR sind alle nötigen  Informationen im Voraus geklärt, wodurch das Team kontinuierlich und ohne  Unterbrechungen arbeiten kann.
  3. Bessere  Sprint Planung: Da alle Aufgaben „bereit“ sind,  können Aufwand und Ressourcen besser eingeschätzt werden, was zu einer  realistischeren Planung führt.
  4. Förderung  der Teamzusammenarbeit: Die DoR wird im Team  erarbeitet, was die Kommunikation stärkt und Missverständnisse minimiert.
  5. Reduzierung  von Risiken und technischer Schulden:  Frühzeitige Klärung von Abhängigkeiten und Problemen verhindert spätere  Blockaden und technische Schulden.

Wie wird die Definition of Ready korrekt formuliert?

  1. Klarheit über das Arbeitselement schaffen
           

    • Was muss erledigt werden?
      Beschreibe das Arbeitselement klar und verständlich. Dies kann eine User Story, ein Feature oder eine Aufgabe sein. Stelle sicher, dass der Umfang des Elements genau definiert ist und keine unklaren oder offenen Fragen bestehen.
  2.  
  3. Akzeptanzkriterien festlege
       
    • Wie sieht das gewünschte Ergebnis aus?
      Die Akzeptanzkriterien beschreiben die Bedingungen, unter denen das Arbeitselement als erfolgreich abgeschlossen gilt. Diese sollten messbar und eindeutig sein, sodass das Team weiß, was zu tun ist, um das Arbeitselement zu erfüllen.
  4.  
  5. Abhängigkeiten identifizieren und kläre
       
    • Gibt es externe Abhängigkeiten?
      Stelle sicher, dass alle externen Abhängigkeiten (z. B. Systeme, APIs, andere Teams) erkannt und dokumentiert sind. Diese müssen entweder bereits zugänglich sein oder der Zugriff sollte im Vorfeld organisiert werden, damit keine Blockaden während der Arbeit entstehen.
  6. Ressourcen und Zugänge bereitstellen
           

    • Haben alle die nötigen  Ressourcen?
      Überprüfe, ob das Team alle benötigten Ressourcen hat, z. B. Zugang zu Datenbanken, APIs, Tools oder Testumgebungen. Fehlen bestimmte Ressourcen, müssen diese vor Arbeitsbeginn sichergestellt werden.
  7.  
  8. Aufwandschätzung  durchführen
           
    • Wie viel Aufwand ist erforderlich?
      Stelle sicher, dass das Team den Aufwand für das Arbeitselement eingeschätzt hat – entweder in Form von Story Points, T-Shirt-Größen oder einer anderen Schätzmethode. Diese Schätzung hilft, den Umfang und die Komplexität der Aufgabe zu verstehen und besser zu planen.    
  9. Testbarkeit sicherstellen
           

    • Kann das Ergebnis überprüft werden?
      Das Arbeitselement muss so formuliert sein, dass es später testbar ist. Stelle sicher, dass sowohl die Akzeptanzkriterien als auch der Testaufwand klar definiert sind. Dies stellt sicher, dass das Team den Erfolg oder Misserfolg des Features eindeutig messn
  10.  
  11. Teamverständnis sichern
             

    • Verstehen alle das Arbeitselement?
      Alle Teammitglieder (Product Owner, Entwickler, Tester, etc.) müssen sich einig sein, was das Arbeitselement umfasst und wie es umgesetzt wird. Ein kurzes Gespräch oder eine Refinement Session kann helfen, Missverständnisse zu klären und sicherzustellen, dass jeder das gleiche Verständnis hat.

Definition of Ready vs. Definition of Done – die Unterschiede

Vorteile einer Definition of Ready

 

Die Definition of Ready (DoR) bietet zahlreiche Vorteile, die den gesamten agilen Entwicklungsprozess erheblich verbessern können. Sie sorgt vor allem für eine klare und transparente Grundlage, auf der das Team arbeiten kann. Ein wesentlicher Vorteil ist die Reduzierungvon Missverständnissen. Wenn alle Beteiligten ein einheitliches Verständnisdavon haben, wann ein Arbeitselement „bereit“ ist, können Unklarheiten und unnötige Rückfragen während der Umsetzung vermieden werden. Das Team weißgenau, was erwartet wird, und kann fokussiert mit der Arbeit beginnen.

Ein weiterer Vorteil ist die Effizienzsteigerung. Ohne die Notwendigkeit, ständig nach Informationen zu suchen oder fehlende Ressourcen zu organisieren, können Entwickler ohne Unterbrechungen arbeiten. Die DoR stellt sicher, dass alles, was für die Umsetzung notwendig ist, bereits vor Beginn der Arbeit bereitsteht. Das führt zu einer höherenVorhersagbarkeit und besseren Sprint-Planung, da die Arbeitslast bessereingeschätzt und realistisch kalkuliert werden kann. Mit klar definierten Kriterien können Aufgaben präzise in die Sprintplanung aufgenommen werden, wasfür das Team und die Stakeholder eine bessere Transparenz und Planbarkeitschafft.

Die Förderung der Zusammenarbeit im Team ist ein weiterer wichtiger Vorteil. Die DoR wird oft gemeinsam im Team erarbeitet, was den Austausch und das Verständnis zwischen Product Owner, Scrum Master und Entwicklern fördert. Dieser Prozess stellt sicher, dass alle Parteien ein gemeinsames Ziel verfolgen und sich über Anforderungen, Prioritäten und notwendige Ressourcen im Klaren sind. Dadurch werden Missverständnisse undKonflikte in späteren Phasen des Projekts vermieden.

Zudem trägt eine klare Definition of Ready zur Reduzierungvon Risiken und technischer Schulden bei. Durch die frühzeitige Klärung von Abhängigkeiten, technischen Anforderungen und offenen Fragen können möglicheProbleme im Voraus identifiziert und behoben werden, bevor sie zu größeren Blockaden führen. Dadurch wird das Risiko verringert, dass während derSprintarbeit unerwartete Hindernisse auftauchen.

Insgesamt sorgt die DoR für eine optimierte Arbeitsweise, bei der alle Beteiligten mit einem klaren Ziel und einem definierten Rahmen arbeiten können. Sie steigert die Effizienz, verbessert die Zusammenarbeit und hilft, Risiken frühzeitig zu minimieren – all das führt zu einer höheren Produktivität und besseren Ergebnissen im Sprint.

DoR in Scrum

In Scrum spielt die Definition of Ready eine entscheidende Rolle für eine erfolgreiche Sprint Planung und -Umsetzung. Im Scrum Prozess dient die DoR dazu, sicherzustellen, dass alle Arbeitselemente im Product Backlog ausreichend vorbereitet sind, bevor sie in den Sprint aufgenommen werden. Ohne eine klar formulierte DoR könnte es dazu kommen, dass unklare oder unvollständige Aufgaben in den Sprint eingeplant werden, was zu Missverständnissen und Verzögerungen führen würde.

In Scrum wird die DoR besonders im Rahmen des Sprint Planning relevant, da das Scrum-Team sicherstellen muss, dass alleAufgaben, die ins Sprint Backlog aufgenommen werden, den definierten Kriterienentsprechen. Ein Arbeitselement ist nur dann „bereit“ für den Sprint, wenn esklare Akzeptanzkriterien, eine nachvollziehbare Beschreibung, dieerforderlichen Ressourcen und alle notwendigen Informationen zur Umsetzungenthält. Dadurch kann das Team den Sprint effizienter und zielgerichteter durchführen, ohne während der Sprintarbeit auf fehlende Informationen oderunklar definierte Anforderungen zu stoßen.

Die Definition of Ready fördert außerdem das kontinuierliche Refinement des Product Backlogs. Während des Backlog Refinements werden alle Einträge im Backlog regelmäßig überprüft, verfeinert und gegebenenfalls aktualisiert, sodass sie jederzeit den Anforderungen der DoR entsprechen. Das stellt sicher, dass das Team stets mit vollständig vorbereiteten und klar definierten Aufgaben arbeitet und keine Zeit mit unklaren oder unvollständigen Elementen verliert.

Welche Alternativen gibt es aufdem Markt?

Neben der klassischen DoR nutzen einige Organisationen alternative oder ergänzende Konzepte:

1. Definition of Ready Maturity Models

Das Definition of Ready Maturity Model hilft Teams dabei, den Reifegrad ihrer Backlog Items (PBIs) zu bewerten und sicherzustellen, dass diese in einem bestimmten Zustand sind, bevor sie weiter bearbeitet werden. Dieses Modell bewertet, wie gut ein Item vorbereitet ist und gibt Aufschluss darüber, welche Kriterien erfüllt sein müssen, um das Arbeitselement als „bereit“ zu betrachten. Es ermöglicht eine kontinuierliche Verbesserung des Prozesses und bietet eine strukturierte Methode zur Messung der Vorbereitungsqualität.

2. Kanban Policies

Im Kanban Framework werden Kanban Policies verwendet, um klare Regeln und Kriterien festzulegen, wann ein Arbeitselement in die nächste Phase des Workflows übergehen kann. Diese Policies definieren beispielsweise, dass ein Item erst dann in die „In Progress“-Spalte verschoben werden darf, wenn bestimmte Voraussetzungen erfüllt sind, wie z.B. eine vollständig definierte User Story oder das Vorhandensein aller notwendigen Ressourcen. Diese Flexibilität ermöglicht es Teams, den Fluss der Arbeit zu steuern und Engpässe zu vermeiden, ohne eine formelle DoR zubenötigen.

3. Workflow States mit Checklisten

In Tools wie Jira, Azure DevOps oder Trello können Workflow States mit integrierten Checklisten genutzt werden, um den Status eines Items zu verfolgen und sicherzustellen, dass alle erforderlichen Schritte vor dem Start erfüllt sind. Diese Checklisten werden direkt im Workflow des Tools eingebunden und ermöglichen eine visuelle Kontrolle darüber, ob ein Item alle Voraussetzungen erfüllt, um in die nächste Phase überzugehen. Diese Methode ist besonders praktisch für Teams, die ihre Prozesse eng mit ihren Tools verbinden und so einen automatisierten, visuellen Überblick behalten möchten.

4. Story Readiness Checklists

Story Readiness Checklists bieten eine leichtgewichtige, teamindividuelle Alternative zur klassischen DoR. Diese Checklisten bestehen aus einer Reihe von einfachen, oft flexiblen Fragen, dievor dem Sprintstart beantwortet werden müssen, z. B. „Sind die Akzeptanzkriterien definiert?“ oder „Sind alle Abhängigkeiten geklärt?“. Sie ermöglichen eine schnelle Überprüfung und Anpassung der Arbeitsvorbereitung und sind besonders hilfreich für Teams, die eine pragmatische, weniger formalisierte Lösung bevorzugen.

Du möchtest mehr über Agilität erfahren? Dann schau mal bei uns vorbei: Hier klicken

Wir bieten Trainings & Workshops in Bereichen wie OKR, Scrum, LEGO® SERIOUS PLAY® und New Leadership an.

Du hast Fragen zu den Trainings oder eine In-house Anfrage?

Melde dich einfach hier: hello@helloagile.de

David Hillmer

13.5.2025