Einfach erklärt: Was ist die Definition of Ready (DoR)?
Was ist eigentlich die Definition of Ready? Diese Frage stellt sich irgendwann jeder Mitarbeitende, wenn er mit der Projektmethode Scrum in Berührung kommt. Das Scrum-Konzept ist einfach, wenn man es einmal verstanden hat… Bis dorthin benötigt es allerdings die ein oder andere Minute an Weiterbildung und Bereitschaft zu scheitern. In diesem Artikel erfahren Sie alles, was Sie über die Definition of Ready in der Praxis wissen müssen.
Die Definition of Ready (DoR) definiert die Anforderungen, die eine Aufgabe erfüllen muss, bevor sie in den Arbeitsprozess aufgenommen wird. Die DoR sorgt dafür, dass Aufgaben klar und verständlich formuliert sind, die notwendigen Ressourcen verfügbar sind und das Team bereit ist, die Arbeit effizient zu erledigen.
Was ist die Idee hinter Definition of Ready?
In der agilen Softwareentwicklung und in anderen agilen Arbeitsweisen ist die „Definition of Ready“ (DoR) ein Schlüsselkonzept. Sie spielt eine entscheidende Rolle bei der Vorbereitung und Planung von Aufgaben in einem agilen Projekt.
Was genau ist die Definition of Ready (DoR)?
Die Definition of Ready (DoR) ist eine Liste von Kriterien und Anforderungen, die eine Aufgabe erfüllen muss, bevor sie vom Entwicklungsteam übernommen und in den Arbeitsprozess aufgenommen wird. Sie dient dazu sicherzustellen, dass Aufgaben klar, vollständig und bereit für die Umsetzung sind. Die DoR kann als eine Art „Checkliste“ oder „Qualitätsbarometer“ betrachtet werden, um sicherzustellen, dass alle notwendigen Informationen, Ressourcen und Voraussetzungen für die Aufgabe erfüllt sind, bevor die Arbeit beginnt.
Was ist das Ziel und der Sinn einer DoR?
Die Definition of Ready hat mehrere wichtige Ziele und Zwecke.
Klare Kommunikation: Sie fördert die klare Kommunikation im Entwicklungsteam und zwischen den Stakeholdern. Durch die Festlegung von klaren Anforderungen wird vermieden, dass Missverständnisse oder unklare Aufgabenbeschreibungen zu Fehlinterpretationen führen.
Effiziente Planung: Die DoR unterstützt die effiziente Planung, Priorisierung und Umsetzung von Aufgaben. Da die Anforderungen vorher definiert sind, kann das Team besser abschätzen, wie viel Arbeit erforderlich ist und wie lange es dauern wird, die Aufgabe abzuschließen.
Qualitätssicherung: Sie trägt zur Qualitätssicherung bei, da sie sicherstellt, dass die Aufgabe alle notwendigen Informationen, Testkriterien und Akzeptanzkriterien enthält. Dadurch wird vermieden, dass unfertige oder mangelhafte Arbeit in den Arbeitsprozess gelangt.
Transparenz: Die DoR fördert die Transparenz im Projektmanagement. Sie ermöglicht es allen Beteiligten, den Fortschritt und den Status der Aufgaben auf einen Blick zu verstehen.
Reduzierung von Verschwendung: Die DoR trägt dazu bei, die Verschwendung von Zeit und Ressourcen zu reduzieren. Durch die Vorbereitung der Aufgaben werden Verzögerungen und Wartezeiten minimiert.
Beispiel: Wie sieht die Definition of Ready (DoR) in der Praxis aus?
Als ich das erste mal über das Thema Definition of Ready gelesen habe, war ich am meisten über die mangelnde Praxisbeispiele verärgert. Aus diesem Grund finden Sie hier ein ausführlich Beispiel, dass Ihnen ein Verständnis darüber gibt, wie eine Definition of Ready aussehen kann.
User Story: Registrierung für ein Online-Portal
Die User Story muss eine klare und präzise Beschreibung der Registrierungsfunktion enthalten, einschließlich der zu erfassenden Benutzerdaten (z. B. Name, E-Mail-Adresse, Passwort) und des Hauptzwecks der Registrierung (Zugriff auf exklusive Inhalte).
Definition of Ready (DoR) für die User Story:
- Konkrete Aufgabenbeschreibung: Ist durch die User Story erfüllt.
- Akzeptanzkriterien: Die Akzeptanzkriterien sind klar definiert und beinhalten Folgendes:
- Der Benutzer muss eine gültige E-Mail-Adresse eingeben.
- Das Passwort muss mindestens 8 Zeichen lang sein und mindestens einen Großbuchstaben, eine Zahl und ein Sonderzeichen enthalten.
- Nach erfolgreicher Registrierung erhält der Benutzer eine Bestätigungsmail.
- Fehlermeldungen sind präzise und benutzerfreundlich.
- Die Seite sollte in weniger als 3 Sekunden geladen sein.
- Abhängigkeiten und Voraussetzungen: Bevor mit der Umsetzung der User Story begonnen wird, müssen folgende Abhängigkeiten erfüllt sein:
- Die Datenbank für Benutzerdaten ist eingerichtet.
- Das System verfügt über eine E-Mail-Versandfunktion.
- Geschätzter Aufwand: Das Entwicklungsteam hat die User Story geschätzt und ist sich einig, dass die Umsetzung etwa 5 Arbeitstage in Anspruch nehmen wird.
- Priorisierung: Die User Story hat eine hohe Priorität, da sie eine grundlegende Funktion für das Online-Portal darstellt und von hoher Bedeutung für die Benutzererfahrung ist.
Was gehört in eine Definition of Ready?
Eine gute und wirkungsvolle Definition of Ready besteht aus mehreren Teilen.
- Konkrete Aufgabenbeschreibung
- Akzeptanzkriterien
- Abhängigkeiten und Voraussetzungen
- Geschätzter Aufwand
- Priorisierung
- Zuständigkeiten
Konkrete Aufgabenbeschreibung
Eine der grundlegenden Anforderungen an die Definition of Ready ist eine klare und präzise Aufgabenbeschreibung. Die Aufgabenbeschreibung sollte alle relevanten Informationen enthalten, die notwendig sind, um die Aufgabe zu verstehen und umzusetzen. Dazu gehören:
Ziel und Zweck: Warum wird diese Aufgabe durchgeführt? Welches Problem soll gelöst oder welches Feature soll implementiert werden?
Anforderungen: Welche spezifischen Anforderungen müssen erfüllt werden? Dies kann technische Spezifikationen, Designanforderungen oder funktionale Anforderungen umfassen.
Beispiele und Use Cases: Gibt es Beispiele oder konkrete Use Cases, die die Aufgabe illustrieren? Dies kann dazu beitragen, Missverständnisse zu vermeiden.
Eine präzise Aufgabenbeschreibung ist entscheidend, um sicherzustellen, dass alle Teammitglieder ein einheitliches Verständnis davon haben, was zu tun ist, und dass die Aufgabe die gewünschten Ergebnisse liefert. Meist wird hier das Prinzip der User Story verwendet.
Akzeptanzkriterien
Die Definition of Ready muss klare und messbare Akzeptanzkriterien enthalten. Diese Kriterien legen fest, wann die Aufgabe als abgeschlossen angesehen wird. Akzeptanzkriterien helfen, den Fertigstellungsgrad der Arbeit zu definieren und Missverständnisse zu vermeiden.
Beispiele für Akzeptanzkriterien:
- Erfüllt die Aufgabe die festgelegten technischen Standards?
- Werden bestimmte Performanceziele erreicht?
- Sind alle relevanten Tests erfolgreich bestanden?
- Wurden eventuelle Abhängigkeiten zu anderen Aufgaben erfüllt?
- Ist die Benutzeroberfläche benutzerfreundlich und erfüllt sie die gestellten Anforderungen?
Die Akzeptanzkriterien dienen als klare Messgröße für die Qualität und den Abschluss der Arbeit und sind für das gesamte Team von entscheidender Bedeutung.
Abhängigkeiten und Voraussetzungen
In vielen Fällen hängen Aufgaben voneinander ab, und es können Voraussetzungen erfüllt sein müssen, bevor eine Aufgabe begonnen werden kann. Die Definition of Ready sollte daher auch Abhängigkeiten und Voraussetzungen klar identifizieren.
Dies umfasst:
Technische Abhängigkeiten: Gibt es andere Aufgaben, die vor dieser erledigt werden müssen? Gibt es bestimmte Technologien oder Ressourcen, die zur Verfügung stehen müssen?
Externe Abhängigkeiten: Gibt es Abhängigkeiten von externen Teams oder Dritten, die berücksichtigt werden müssen?
Voraussetzungen: Welche Bedingungen müssen erfüllt sein, damit die Aufgabe beginnen kann? Dies können beispielsweise spezifische Daten, Informationen oder Freigaben sein.
Durch die klare Identifizierung von Abhängigkeiten und Voraussetzungen in der DoR wird vermieden, dass das Team mit der Umsetzung beginnt, ohne die notwendigen Vorbereitungen getroffen zu haben. Dies trägt zur Effizienz und zur Vermeidung von Verzögerungen bei.
Geschätzter Aufwand
Eine effektive DoR sollte auch eine grobe Schätzung des Aufwands für die Aufgabe enthalten. Dies hilft dem Team, den Zeitaufwand und die Ressourcen besser zu planen. Die Schätzung kann auf verschiedenen Schätzmethoden basieren, wie beispielsweise Story Points oder Arbeitsstunden.
Eine realistische Aufwandschätzung ist wichtig, um zu vermeiden, dass Aufgaben übermäßig aufgebläht oder unterbewertet werden, was zu Planungsproblemen führen kann.
Priorisierung
Die Priorisierung von Aufgaben ist ein weiterer wichtiger Aspekt der DoR. Sie hilft, sicherzustellen, dass die dringendsten und wichtigsten Aufgaben zuerst angegangen werden. In der Definition of Ready wird daher klar festgelegt, welche Priorität die Aufgabe hat. Dies kann durch die Zuweisung von Prioritätsstufen, wie beispielsweise „hoch“, „mittel“ oder „niedrig“, erfolgen.
Die Priorisierung kann auf verschiedenen Faktoren basieren, wie beispielsweise Geschäftswert, Kundenbedürfnisse oder strategische Ziele. Die Priorisierung selbst nimmt wie gewohnt der Product Owner vor.
Zuständigkeiten
Die Definition of Ready sollte auch die Zuständigkeiten klar festlegen. Wer ist für die Umsetzung der Aufgabe verantwortlich? Wer ist für die Qualitätssicherung zuständig? Gibt es spezielle Zuständigkeiten für das Projektmanagement oder die Koordination? Die Klärung dieser Zuständigkeiten hilft, die Verantwortlichkeiten im Team klar zu definieren und Missverständnisse zu vermeiden.
Wie erstelle ich eine Definition of Ready?
Wer ist für die Definition of Ready verantwortlich?
In agilen Entwicklungsteams und insbesondere im Scrum-Framework ist die Verantwortung für die Definition of Ready (DoR) eine gemeinsame Aufgabe, die das gesamte Team betrifft.
Die DoR ist von entscheidender Bedeutung, um sicherzustellen, dass Aufgaben, User Stories oder Features vor ihrer Umsetzung klar definiert und vorbereitet sind. Zu Beginn schreibt der Product Owner die DoR. Dabei holt er sich hauptsächlich die Unterstützung vom Scrum Master, damit das Entwicklungsteam die Anforderungen versteht.
Hier sind die Hauptbeteiligten und deren Verantwortlichkeiten in Bezug auf die Definition of Ready:
Das Entwicklungsteam: Das Entwicklungsteam, das aus Entwicklern, Designern, Testern und anderen relevanten Fachleuten besteht, trägt eine wichtige Verantwortung für die Erstellung und Umsetzung der Definition of Ready. Genau diese Teammitglieder müssen sicherstellen, dass sie die DoR verstehen und dass sie alle erforderlichen Informationen, Anforderungen und Voraussetzungen erhalten haben.
Der Product Owner: Der Product Owner spielt eine Schlüsselrolle bei der Festlegung der Anforderungen und Prioritäten im Backlog. Als Hüter des Product Backlogs ist der Product Owner Hauptverantwortlich für die DoR.
Der Scrum Master: Der Scrum Master unterstützt das Team bei der Umsetzung agiler Prinzipien und Best Practices. Obwohl der Scrum Master nicht direkt für die Definition of Ready verantwortlich ist, kann er eine beratende Rolle bei der Erstellung und Pflege der DoR spielen. Er kann dazu beitragen, sicherzustellen, dass das Team die Bedeutung der DoR versteht und dass die Prozesse zur Erstellung und Aktualisierung der DoR effektiv sind.
Wer schreibt die Akzeptanzkriterien?
Die Akzeptanzkriterien werden in der Regel in einer kooperativen Anstrengung zwischen dem Entwicklungsteam und dem Product Owner erstellt. Die Akzeptanzkriterien definieren, wann eine User Story oder eine Aufgabe als abgeschlossen angesehen wird, und sie stellen sicher, dass die erwarteten Ergebnisse klar definiert sind. Hier ist, wie dieser Prozess in der Praxis funktioniert:
Produktinhaber (Product Owner): Der Product Owner ist dafür verantwortlich, die Anforderungen und Prioritäten des Produkts zu vertreten. In Zusammenarbeit mit den Stakeholdern hat der Product Owner eine klare Vorstellung davon, wie die Funktionalität oder das Feature am Ende aussehen sollte. Basierend auf dieser Vorstellung und den geschäftlichen Anforderungen arbeitet der Product Owner eng mit dem Entwicklungsteam zusammen, um die Akzeptanzkriterien zu definieren.
Entwicklungsteam: Das Entwicklungsteam spielt eine entscheidende Rolle bei der Definition der Akzeptanzkriterien, da es das technische Fachwissen hat, um sicherzustellen, dass die Kriterien realisierbar sind. Das Team fragt nach Klarstellungen und prüft, ob die Kriterien aus technischer Sicht sinnvoll und erfüllbar sind. Es bringt auch seine Erfahrung ein, um sicherzustellen, dass nichts übersehen wird.
Was ist der Unterschied zwischen Definition of Ready (DoR) und Definition of Done (DoD)?
Es ist wichtig, zwischen der Definition of Ready (DoR) und der Definition of Done (DoD) zu unterscheiden, obwohl beide Konzepte eng miteinander verbunden sind:
- DoR (Definition of Ready): Die DoR legt fest, was erfüllt sein muss, damit eine Aufgabe in den Arbeitsprozess aufgenommen werden kann. Sie definiert die Voraussetzungen, die erfüllt sein müssen, bevor die Arbeit beginnen kann. Dies kann beispielsweise die Verfügbarkeit von Spezifikationen, Ressourcen oder Abhängigkeiten einschließen.
- DoD (Definition of Done): Im Gegensatz dazu legt die DoD fest, wann eine Aufgabe oder ein Feature als abgeschlossen betrachtet wird. Sie enthält die Kriterien, die erfüllt sein müssen, damit die Arbeit als fertig angesehen wird. Dies können Tests, Code-Reviews und andere Qualitätsstandards sein.
In der Regel arbeiten die beiden Konzepte zusammen, um sicherzustellen, dass die Arbeit sowohl vor der Aufnahme in den Arbeitsprozess (DoR) als auch am Ende der Umsetzung (DoD) den Anforderungen entspricht
