Für reibungslose agile Sprints Definition of Ready als Schlüssel für den agilen Erfolg

Definition of Ready in 3 Schritten einführen

Die Definition of Ready sorgt dafür, dass Aufgaben klar definiert und gut vorbereitet in einen Sprint gelangen. Dieser Beitrag zeigt, wie Sie die DoR in drei Schritten einführen, häufige Fehler vermeiden und so die Effizienz im Sprint steigern.

Management Summary
  • Die Definition of Ready (DoR) stellt sicher, dass alle Anforderungen und Ressourcen für eine Aufgabe bereit sind, bevor diese in einen Sprint aufgenommen wird. Sie verhindert so Verzögerungen und Missverständnisse.
  • Häufige Herausforderungen ohne DoR sind unklare Anforderungen, fehlende Ressourcen und technische Abhängigkeiten, die den Sprint-Prozess negativ beeinflussen können.
  • Ein eindeutig definierter DoR-Prozess schafft einen strukturierten Workflow. Die DoR sollte mindestens alle drei Monate überprüft und ggf. angepasst werden, um mit den Entwicklungen des Teams und des Projekts Schritt zu halten.
  • Die Einführung der DoR erfordert klare, messbare Kriterien und die Einbindung des gesamten Teams, um sicherzustellen, dass alle relevanten Aspekte berücksichtigt werden.
  • Die DoR dient als zentraler Qualitätsfilter, der die Definition of Done in dieser Funktion ergänzt und die Produktivität sowie Effizienz in agilen Teams nachhaltig fördert.
Herunterladen Download PDF
Download EPUB

Für reibungslose agile Sprints Definition of Ready als Schlüssel für den agilen Erfolg

Definition of Ready in 3 Schritten einführen

Die Definition of Ready sorgt dafür, dass Aufgaben klar definiert und gut vorbereitet in einen Sprint gelangen. Dieser Beitrag zeigt, wie Sie die DoR in drei Schritten einführen, häufige Fehler vermeiden und so die Effizienz im Sprint steigern.

Management Summary
  • Die Definition of Ready (DoR) stellt sicher, dass alle Anforderungen und Ressourcen für eine Aufgabe bereit sind, bevor diese in einen Sprint aufgenommen wird. Sie verhindert so Verzögerungen und Missverständnisse.
  • Häufige Herausforderungen ohne DoR sind unklare Anforderungen, fehlende Ressourcen und technische Abhängigkeiten, die den Sprint-Prozess negativ beeinflussen können.
  • Ein eindeutig definierter DoR-Prozess schafft einen strukturierten Workflow. Die DoR sollte mindestens alle drei Monate überprüft und ggf. angepasst werden, um mit den Entwicklungen des Teams und des Projekts Schritt zu halten.
  • Die Einführung der DoR erfordert klare, messbare Kriterien und die Einbindung des gesamten Teams, um sicherzustellen, dass alle relevanten Aspekte berücksichtigt werden.
  • Die DoR dient als zentraler Qualitätsfilter, der die Definition of Done in dieser Funktion ergänzt und die Produktivität sowie Effizienz in agilen Teams nachhaltig fördert.
Wir empfehlen zum Thema Agile
1 Tag
16.05.2025
799,00,-
Strategisches Portfolio-Management: Erfolgreiche Strategieumsetzung in Zeiten des Wandels

Dieses Seminar zeigt Ihnen, wie strategisches Portfolio-Management (SPM) Unternehmensstrategie und -transformation unterstützt. Sie lernen Kerndisziplinen, Nutzen und Methoden des SPM kennen, erhalten praxisorientierte Einblicke und erfahren... Mehr Infos

Klare Prozesse und gut strukturierte Aufgaben spielen sowohl im klassischen als auch im agilen Projektmanagement eine zentrale Rolle. Im agilem Projektmanagement steht die Definition of Done (DoD) oft im Mittelpunkt, die Definition of Ready (DoR) hingegen wird leider häufig vernachlässigt. Dabei bildet die DoR die Grundlage für den Erfolg agiler Sprints, legt sie doch fest, wann eine Aufgabe überhaupt erst bereit ist, um in einen Sprint aufgenommen zu werden.

In diesem Beitrag erfahren Sie, warum die DoR für den agilen Prozess eine enorme Bedeutung hat, welche Herausforderungen auftreten können und wie Sie die DoR effizient in Ihrem Team einführen können.

Was ist die Definition of Ready?

Die DoR ist eine Sammlung von Kriterien, die erfüllt sein müssen, bevor eine Aufgabe oder User Story in einen Sprint aufgenommen werden kann. Sie stellt sicher, dass das Team über alle notwendigen Informationen und Ressourcen verfügt, um die Aufgabe umgehend zu bearbeiten. Im Wesentlichen dient die DoR dabei als ein Qualitätsfilter, der unvorbereitete oder unklare Aufgaben erkennt, bevor sie die Produktivität des Teams beeinträchtigen.

Beispiel: Ein Team arbeitet an einer neuen Funktion für eine App, bei der der Nutzer seine E-Mail-Adresse ändern kann. Vor dem Sprint werden die technischen Anforderungen und Abhängigkeiten geprüft. Nur wenn klar ist, dass die API für die E-Mail-Änderung bereit und getestet ist und alle Akzeptanzkriterien dokumentiert sind, gilt die Aufgabe als "bereit" für den Sprint.

Warum ist die DoR wichtig für den agilen Prozess?

Die DoR ist entscheidend, um sicherzustellen, dass das Team nicht mit unklaren oder unvorbereiteten Aufgaben in einen Sprint startet. Ohne eine klare DoR ist das Risiko groß, dass Aufgaben während des Sprints gestoppt werden oder die Bearbeitung sich verzögert, weil wesentliche Informationen fehlen oder technische Abhängigkeiten ungelöst sind.

Häufige Probleme ohne DoR:

  1. Unklare Anforderungen: Teams starten die Arbeit an Aufgaben und merken später, dass wichtige Details fehlen. Dies führt zu Unterbrechungen und Nachfragen beim Product Owner.
  2. Technische Abhängigkeiten: Aufgaben werden gestartet, ohne dass überprüft wurde, ob alle notwendigen technischen Komponenten vorhanden sind. Dies verursacht Verzögerungen, weil Abhängigkeiten im Sprint gelöst werden müssen.
  3. Fehlende Ressourcen: Das Team beginnt die Arbeit, muss dann aber feststellen, dass Ressourcen (wie Daten, Tools oder Zugänge) fehlen. Diese müssen dann während des Sprints organisiert werden, was Zeit und Energie kostet.

Eine gut definierte DoR hilft Ihnen, solche Probleme zu vermeiden. Sie sorgt dafür, dass alle Voraussetzungen vor dem Start einer Aufgabe erfüllt bzw. geklärt sind.

Unterschiede zwischen Definition of Ready und Definition of Done

Die DoR und die Definition of Done (DoD) ergänzen sich:

  • Definition of Ready legt fest, wann eine Aufgabe bereit ist, um in den Sprint aufgenommen zu werden. Ihr Fokus liegt auf der Vorbereitung der Aufgabe, bevor die eigentliche Bearbeitung beginnt.
  • Definition of Done bestimmt, wann eine Aufgabe vollständig abgeschlossen ist, inklusive Tests, Dokumentation und Akzeptanzprüfung. Sie sichert die Qualität des Ergebnisses am Ende des Arbeitsprozesses.

Kurz gesagt: Die DoR sichert den Startpunkt, während die DoD den Endpunkt einer Aufgabe definiert.

Mit einer Definition of Done stellen Sie sicher, dass im Team ein einheitliches Verständnis davon herrscht, wann ein Feature fertig ist. Erfahren Sie, wie Sie die Definition im Team gemeinsam erstellen und worauf Sie dabei achten sollten.

Weiterlesen
MEHR ZUM THEMA DEFINITION OF DONE

Wichtige Aspekte bei der Einführung der DoR

Die Einführung der DoR erfordert sorgfältige Planung und die Einbindung des gesamten Teams. Dies sind die wichtigsten Aspekte, die Sie bei der Einführung der DoR berücksichtigen sollten:

1. Team-Einbindung

Die DoR sollte immer in Zusammenarbeit mit dem gesamten Team erstellt werden. Jedes Teammitglied bringt unterschiedliche Perspektiven ein – Entwickler:innen, Tester:innen und der Product Owner (PO) haben jeweils eigene Anforderungen und Sichtweisen, die in die DoR einfließen sollten.

Praxisbeispiel:

Ein Team hat Schwierigkeiten, Sprints abzuschließen, weil der PO technische Abhängigkeiten häufig übersieht. Dies führt zu unerwarteten Blockern und Verzögerungen, einem erhöhten Aufwand für Nacharbeiten und KommunikationKommunikationIm Projektmanagement ist der Austausch von Informationen zwischen den Projektbeteiligten ein entscheidender Erfolgsfaktor und Kommunikation ist ein eigenständiger Aufgabenbereich für die Projektleitung., sowie langfristig zum Verlust von Commitments und Motivation. Um dies zu verhindern, initiiert der Scrum MasterScrum MasterScrum Master ist eine der drei Verantwortlichkeiten (bis 2020 Rollen) im agilen Rahmenwerk  ↑Scrum . Der Scrum Master ist dafür verantwortlich, dass die Beteiligten Scrum richtig verstehen und umsetzen. Für den Qualifikationsnachweis als Scrum Master gibt es zwei aufeinander aufbauende Zertifikate, den Professional Scrum Master level 1 (PSM I) und den Professional Scrum Master level 2 (PSM II), die von Scrum.org in einem Online-Test erworben werden können. einen Workshop, um die DoR gemeinsam mit dem PO und dem Entwicklungsteam zu erarbeiten, damit künftig alle Abhängigkeiten von Anfang an berücksichtigt werden können.

2. Klarheit und Einfachheit

Die Kriterien der DoR müssen klar und einfach formuliert sein, um Missverständnisse zu vermeiden. Statt vager Formulierungen wie "ausreichende Informationen liegen vor" sollten Sie auf konkrete und messbare Kriterien setzen, z.B. ob die User Story dem INVEST/SMART-Format folgt oder Akzeptanzkriterien hat und für das Team schätzbar ist.

Setzen Sie kluge Ziele, die alle verstehen! Entwickeln Sie für sich oder zusammen mit Ihrem Team Zielbeschreibungen, die ein wirksames und erfolgsorientiertes Arbeiten ermöglichen! Realisieren und überprüfen Sie Ihre Ziele dann auch SMART!

Weiterlesen
MEHR ZUM THEMA SMART

Beispiel:

"Die E-Mail-API (Application Programming Interface, auf Deutsch etwa "Programmierschnittstelle") ist getestet und funktionsfähig" ist ein klares Kriterium, das leicht überprüft werden kann.

3. Regelmäßige Anpassung

Die Anforderungen an die DoR können sich im Laufe der Zeit ändern. Stellen Sie sicher, dass die DoR regelmäßig überprüft und angepasst wird, um mit den Entwicklungen des Teams und des Projekts Schritt zu halten. Die DoR sollte mindestens alle drei Monate überprüft werden. Die Überprüfung kann z.B. innerhalb der Retrospektiven oder den jeweiligen BacklogBacklogEin Backlog ist eine dynamisch gepflegte Liste von durchzuführenden Arbeitsaufträgen, den Items. Diese können in Form von Anforderungen, User Storys oder Funktionsbeschreibungen vorliegen. Backlogs kommen häufig zum Einsatz bei der Arbeit in agilen Rahmenwerken wie Scrum und Kanban. Refinements vorgenommen werden.

Klassische Stolpersteine bei der DoR

Auch wenn die DoR in der Theorie klar und logisch erscheint, gibt es in der Praxis einige typische Stolpersteine.

1. Zu viele Kriterien

Wenn die DoR zu viele detaillierte Kriterien enthält, kann dies dazu führen, dass Aufgaben unnötig lange in der Vorbereitungsphase "hängen bleiben". Zu viele Hürden machen es dem Team schwer, überhaupt mit der Arbeit zu beginnen.

Lösung: Beschränken Sie sich auf die wesentlichen Kriterien, die unbedingt erfüllt sein müssen, um die Aufgabe ohne Verzögerungen abzuschließen. Das Kriterium "Alle Akzeptanzkriterien sind klar und vollständig dokumentiert." beschreibt, was die User Story erfüllen muss, um als "done" zu gelten. Dies bedeutet, dass alle Teammitglieder diese Akzeptanzkriterien eindeutig verstehen können, und somit keine offenen Fragen mehr bestehen sollten, bevor die Story in den Sprint aufgenommen wird.

Kriterien wie "Alle Eventualitäten und technischen Risiken müssen vorab detailliert dokumentiert und bewertet sein." oder "Alle notwendigen Designs und Mockups müssen in allen Details finalisiert und durch den PO abgenommen sein" könnten dazu führen, dass sich die Aufnahme in den Sprint immer wieder verzögern könnten. Zusätzlich können solche Kriterien die Flexibilität des Teams einschränken, schnell und inkrementell zu arbeiten

2. Unrealistische Anforderungen

Manchmal werden Anforderungen an eine Aufgabe gestellt, die zu umfassend sind, als dass das Team sie innerhalb eines Sprints erfüllen kann. Diese übergroßen Aufgaben bleiben dann oft unvollständig und führen zu Frustration im Team.

Lösung: Teilen Sie große Aufgaben in kleinere, realistisch umsetzbare Einheiten auf, die in einem Sprint abgeschlossen werden können. Beispiel für eine unpassende User Story: "Als Kunde möchte ich in einem Online-Shop meine Bestellung abschließen können, sodass ich den Kaufprozess komplett online durchführen kann." Diese User Story ist für einen Sprint meist zu groß, denn sie umfasst viele Schritte und Anforderungen, wie die Erfassung von Kundendaten, die Validierung der Daten, die Anbindung an Zahlungsdienstleister und die Bestellbestätigung.

Wer Freude an der Arbeit hat, erzielt auch bessere Ergebnisse. Mit einer selbst erarbeiteten Definition of Fun etablieren Sie Maßnahmen dafür. Lesen Sie, wie Sie mit Ihrem Team eine eigene Definition of Fun erarbeiten können.

Weiterlesen
MEHR ZUM THEMA FREUDE STATT FRUST

3. Missverständnisse im Team

Ein weiteres häufiges Problem sind Missverständnisse darüber, was "bereit" genau bedeutet. Wenn das Team und der:die PO unterschiedliche Auffassungen von der DoR haben, entstehen Unklarheiten.

Lösung: Sorgen Sie für ein gemeinsames Verständnis durch regelmäßige Workshops und Diskussionen zur DoR. So wird sichergestellt, dass alle Beteiligten dieselbe Definition haben.

Die DoR effizient nutzen

Um die Definition of Ready effizient zu nutzen, sollten einige fortgeschrittene Strategien berücksichtigt werden. Die nachfolgenden Tipps helfen Ihrem Team, die DoR so zu gestalten, dass sie den Workflow verbessert und Hindernisse vermeidet.

1. Technische Schulden berücksichtigen

Die DoR sollte technische Schulden berücksichtigen, also ungelöste technische Probleme oder veralteten Code. Diese Schulden können den Fortschritt verlangsamen, wenn das Team sie erst während des Sprints erkennt.

Beispiel: Ein Team, das an einer neuen Funktion arbeitet, entdeckt während des Sprints, dass veralteter Code die Implementierung behindert. Mit einer gut dokumentierten DoR wären diese Schulden frühzeitig erkannt und behoben worden. Ein DoR-Kriterium wie "Technische Schulden sind identifiziert und dokumentiert" hätte dazu geführt, dass das Team den veralteten Code bereits vor Sprintbeginn prüft und erkennt, dass Refactoring notwendig ist. So wäre die Blockade im Sprint vermieden und die Implementierung effizienter verlaufen.

2. Checkpoints vor dem Sprint-Planning

Profis setzen häufig Checkpoints ein, um sicherzustellen, dass sämtliche DoR-Kriterien erfüllt sind, bevor eine Aufgabe in den Sprint aufgenommen wird. So wird vermieden, dass unvorbereitete Aufgaben den Sprint blockieren.

Beispiel: Ein Team führt vor jedem Sprint-Planning ein kurzes Review durch, um sicherzustellen, dass alle User Stories "bereit" sind. So werden nur vollständig vorbereitete Aufgaben in den Sprint aufgenommen.

Best Practices für eine erfolgreiche DoR

Um die DoR effektiv zu gestalten, sollten Sie folgende Best Practices beachten.

1. Klarheit vor Flexibilität

Die DoR sollte klare und verständliche Anforderungen enthalten. Vermeiden Sie zu viele komplexe Anforderungen, aber lassen Sie gleichzeitig auch Raum für Flexibilität, für den Fall, dass sich die Rahmenbedingungen ändern sollten.

Beispiel: Eine API muss vor dem Start eines Sprints getestet sein, aber kleine Anpassungen, wie die Verbesserung von Fehlermeldungen, die Änderung von Standardwerten oder die zusätzliche Implementierung von optionalen Parametern können während des Sprints noch vorgenommen werden.

2. Transparenz fördern

Sorgen Sie dafür, dass die DoR für alle Teammitglieder und Stakeholder:innen transparent ist. So entsteht ein gemeinsames Verständnis darüber, welche Kriterien erfüllt sein müssen.

Tipp: Dokumentieren Sie die DoR-Kriterien in einem leicht zugänglichen Wiki wie Confluence oder Task-Management-Tool wie Jira.

3. Regelmäßige Retrospektiven nutzen

Nutzen Sie Retrospektiven, um die DoR quartalsweise zu überprüfen und bei Bedarf anzupassen. So bleibt sie relevant und an die Bedürfnisse des Teams angepasst.

Eine erfolgreiche Definition of Ready basiert auf klar verständlichen und messbaren Kriterien. Das Team sollte von Anfang an in den Prozess der Erstellung dieser einbezogen werden. Überprüfen Sie die DoR gemeinsam in regelmäßigen Abständen und passen Sie sie an. So können Sie mit den Veränderungen im Projekt Schritt halten. Indem Sie diese Best Practices befolgen, wird die DoR zu einem mächtigen Instrument, das den Workflow Ihres Teams verbessert und Hindernisse im agilen Prozess vermeidet.

Ausblick

Die Definition of Ready ist mehr als nur eine Checkliste – sie ist ein Schlüsselelement für den Erfolg agiler Teams. Durch die konsequente Anwendung und regelmäßige Anpassung der DoR können Teams sicherstellen, dass sie gut vorbereitet in jeden Sprint starten und unerwartete Hindernisse minimieren. Wer die DoR ernst nimmt und in die tägliche Praxis integriert, wird langfristig von höherer Effizienz, eindeutig definierten Aufgaben und erfolgreichen Sprints profitieren. (dv)

Für jeden Bedarf die passende Mitgliedschaft

 

Das projektmagazin - unverzichtbares Nachschlagewerk und Inspirationsquelle für alle,
die in Projekten arbeiten. Ihre Vorteile auf einen Blick

Image
Wissensplattform

Zugriff auf die größte deutschsprachige Wissensplattform
für Projektmanagement  (>1.800 Artikeln und Tipps)

Image
Praxisbezogene Beiträge

Praxisbezogene Beiträge
Fachautoren schreiben aus der Praxis für die Praxis.

Image
Tools

Werkzeuge (Tools)
z.B. Checklisten und Vorlagen, Methoden mit Schritt-für-Schritt-Anleitung.

Image
Glossar

Umfangreiches Projektmanagement-Glossar
über 1.000 Fachbegriffen (deutsch/englisch)

Image
Blogbeiträge

Blogbeiträge, Themenspecials, Bücher, Stellenangebote etc.
rund um das Thema Projektmanagement

Alle Kommentare (2)

Eduard
Chernavin

Ein sehr interessanter und hilfreicher Beitrag.
In der Praxis ist es tatsächlich manchmal schwierig, eine Formulierung für DoR zu finden, die wenig Missverständnisse zulässt.
Nehmen wir zum Beispiel die vorgeschlagene Formulierung „Alle Akzeptanzkriterien sind klar und vollständig dokumentiert“. Es kann vorkommen, dass ein relevantes Akzeptanzkriterium zunächst übersehen wurde. Daher kann das „Alle“ selbst irreführend sein. Auch das Wort „klar“ könnte zu Unklarheiten führen. Um dies zu vermeiden, könnte man die DoR etwas anpassen. Hier ein Vorschlag: „Akzeptanzkriterien sind so dokumentiert, dass alle Beteiligten ein gemeinsames Verständnis haben und die Umsetzung überprüfbar ist“.
Die Überprüfung des gemeinsamen Verständnisses lässt sich durch eine kurze Diskussion erreichen. Die Umsetzbarkeit einzelner Akzeptanzkriterien sollte nicht zu einem Kraftakt werden.

Vielen Dank für Ihren Kommentar.
Sie haben recht, dass es vorkommen könnte, dass nicht alle Akzeptanzkriterien bekannt sind. Es kann sogar im Nachhinein vorkommen, dass weitere Akzeptanzkriterien (AC) hinzukommen könnten. Solange die entsprechende User Story noch nicht im Sprint Planning abschließend besprochen und geschätzt worden ist, stellt das aus meiner Sicht heraus kein Problem dar. Wichtig ist jedoch, dass zusätzliche AC nicht so ohne Weiteres und ohne Kenntnis vom Team hinzugefügt werden. Auch sollte es nicht vorkommen, während des laufenden Sprints AC hinzuzufügen. In solchen Fällen sollte sich der Product Owner (PO) mit dem Team über einen entsprechenden Change Request (CR) austauschen, der für den folgenden Sprint eingeplant werden könnte.

Eine Anmerkung zu Ihrem Textvorschlag:
Ich sehe es so wie Sie, dass alle Beteiligten ein gemeinsames Verständnis über die User Story und die jeweiligen Akzeptanzkriterien haben sollten. Solange dies nicht vorherrscht, macht eine Schätzung und Bearbeitung der User Story aus meiner Sicht keinen wirklichen Sinn. Insofern ist das gemeinsame Verständnis der AC eine Art der Grundvoraussetzung. Für die Überprüfbarkeit der Umsetzung sind die Erfüllung der Akzeptanzkriterien geeignete "Metriken".