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.
An Amazon-Kindle übertragen
Melden Sie sich bei Ihrem Amazon Konto an und folgen Sie den Anweisungen, um Ihre Datei hochzuladen und auf Ihr Kindle-Gerät zu übertragen. Unter diesem Link können Sie Ihre Amazon-Geräte und Dateien verwalten. Feedback oder Fragen?
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.
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.
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.
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:
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.
Die DoR und die Definition of Done (DoD) ergänzen sich:
Kurz gesagt: Die DoR sichert den Startpunkt, während die DoD den Endpunkt einer Aufgabe definiert.
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:
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.
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.
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.
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.
Auch wenn die DoR in der Theorie klar und logisch erscheint, gibt es in der Praxis einige typische Stolpersteine.
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
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.
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.
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.
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.
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.
Um die DoR effektiv zu gestalten, sollten Sie folgende Best Practices beachten.
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.
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.
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.
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)
