Was ist die Definition of Ready (DOR) in Scrum? Leitfaden 2024

Wichtige Erkenntnisse: Was ist die Definition of Ready (DoR)?

Obwohl die Definition von „bereit“ nicht Teil des offiziellen Scrum-Frameworks ist, ist es bei neuen Scrum-Teams beliebt, User-Story-Checklisten zu erstellen, die sicherstellen, dass eine Aufgabe zur Bearbeitung bereit ist. Glücklicherweise machen es einige der besten Projektmanagement-Softwareprogramme, wie Jira mit seinem soliden kostenlosen Plan, jetzt einfach, die Definition von „bereit“ in Ihren Arbeitsablauf zu integrieren.

Wenn Sie mehr über die Definition von „bereit“, die Vor- und Nachteile des Prozesses und einige Tipps erfahren möchten, die Ihnen und Ihrem Team bei der Umsetzung bei Ihrem nächsten Sprint-Planungsmeeting helfen, sind Sie hier richtig. Im Folgenden behandeln wir alles oben Erwähnte und mehr.

Was ist die Definition von „bereit“? Die Grundlagen

Die Definition of Ready (DoR) ist ein Satz von Kriterien (oder eine Arbeitsvereinbarung), auf die sich ein Produktbesitzer (PO) und Entwickler einigen, um sicherzustellen, dass Produktfunktionen oder -aufgaben für die Bearbeitung in einem bevorstehenden Sprint bereit sind.

Wenn sie verwendet werden, sollten Checklisten zur Definition von „Bereit“ für jede Story oder Funktion in einem Produkt-Backlog implementiert werden. Eine gute Definition von „Bereit“ kann Teams dabei helfen, klare, prägnante Stories zu erstellen, die sofort nach Beginn des Sprints umsetzbar sind. Vor dem Start eines Sprints sollte jede User Story Folgendes erklären:

• Wer die Endbenutzer sein werden — Erklären Sie, warum der Kunde das Produkt verwenden wird, was es tun soll und was für seine Funktion erforderlich ist.
• Was sind die Akzeptanzkriterien? — Wie wird die Funktion am Ende des Sprints getestet? Welche Metriken werden verwendet, um sicherzustellen, dass die Funktion wie vorgesehen funktioniert? Für jede User Story sollten klare Akzeptanzkriterien definiert werden.
• Wie lange die Fertigstellung dauern sollte — Das Feature sollte entweder anhand der Zeit oder anhand von Story Points schätzbar (messbar) sein. POs müssen sicherstellen, dass jede Story in einem Sprint abgeschlossen werden kann.
• Der Mehrwert, den die Funktion bietet – Das Team sollte in der Lage sein, den Mehrwert der Funktion für den Endbenutzer zu erklären.
• Ob die Aufgabe frei von Abhängigkeiten ist — Jede Aufgabe sollte frei von externen Abhängigkeiten sein, damit sie rechtzeitig und ohne Verzögerungen durch andere Aufgaben abgeschlossen werden kann.

Definition von „Bereit“ – Beispiel

Jetzt ist es an der Zeit, einen kurzen Blick darauf zu werfen, wie die Definition von „bereit“ für eine User Story in Ihrem Sprint-Backlog aussehen könnte. Denken Sie daran, dass jede User Story ihre eigenen, klar definierten Kriterien haben muss, mit Informationen, die den Teams helfen, zu wissen, was erwartet wird. Unten finden Sie eine Beispiel-DoR-Checkliste für eine Funktion, die für eine Software verwendet werden könnte.

• Gibt es eine gut definierte, klare und prägnante User Story?
• Erklärt die User Story den Wertvorschlag (wie die Software dadurch verbessert wird)?
• Wurden alle Abhängigkeiten ermittelt und abgeschlossen?
• Hat das Entwicklerteam die Artefakte zur Benutzererfahrung (Scheinfunktionsentwürfe) akzeptiert?
• Steht der Mitarbeiter fest, der an der Story arbeiten wird?
• Gibt es definierte, messbare Akzeptanzkriterien (Messgrößen zum Testen)?

Möglicherweise stellen Sie fest, dass die Definition von „Ready for Stories“ in Ihrem Projekt weniger oder mehr Elemente enthält als in der obigen Checkliste, und das ist in Ordnung. Jede User Story ist einzigartig und muss unterschiedliche Kriterien erfüllen.

Was ist die INVEST-Methode in DoR?

Eine gute Möglichkeit für Teams, die bestmöglichen User Stories zu schreiben, ist die Verwendung des INVEST-Entwicklungsprozesses (Independent, Negotiable, Valuable, Estimable, Small, Testable) während der Sprintplanung. Im Folgenden erläutern wir, wofür das Akronym INVEST steht.

Unabhängig

Alle Aufgaben im Backlog müssen völlig unabhängig sein und dürfen nicht von anderen Aufgaben abhängen. Dadurch wird sichergestellt, dass jede User Story abgeschlossen werden kann, ohne dass eine andere Aufgabe sie aufhält. Die Idee besteht darin, sicherzustellen, dass das Projekt auch dann fortgeführt werden kann, wenn ein anderes Team seine Arbeit nicht abschließt.

Verhandelbar

Alle Definitionen fertiger User Stories sollten flexibel und nicht starr sein. Dadurch wird sichergestellt, dass Elemente der Story spontan geändert werden können, wenn ein Stakeholder oder Kunde dies verlangt.

Wertvoll

Wenn das agile Team, das die User Story schreibt, keine Aussage zum Wert einer Funktion machen kann, sollte es diskutieren, ob die Funktion notwendig ist.

Schätzenswert

Jedes Feature muss umsetzbar sein und Entwickler müssen in der Lage sein, die User Story in einem Sprint fertigzustellen. Der Arbeitsaufwand einer User Story sollte anhand von Zeit oder Story Points berechnet werden.

Klein

User Stories sollten kurz, verständlich und einfach zu planen sein. Das Erstellen leicht verständlicher Aufgaben reduziert Stress und Burnout und erhöht die Effizienz des Teams.

Testbar

Beim Schreiben einer User Story sollte der PO darauf achten, dass Abschlusskriterien oder Leistungskriterien (messbare Aktionen) enthalten sind. Durch die Einbeziehung der Metriken können Features am Ende des Sprints anhand vordefinierter Kriterien getestet werden.

Vorteile der Definition von „Bereit“ für Ihr Unternehmen

Es dürfte niemanden überraschen, dass Agile- und Scrum-Teams von der Definition of Ready (DoR) profitieren. Im Folgenden werden wir kurz auf einige der größten Vorteile der DoR eingehen.

Verbessert die Zusammenarbeit

Das Erstellen einer Checkliste mit Definitionen für Backlog-Elemente im Team fördert die Kommunikation und Zusammenarbeit und führt zu einem gemeinsamen Verständnis der Erwartungen. Zusammenarbeit kann Stress und Verwirrung reduzieren und Vertrauen und Moral stärken, was auch dafür sorgt, dass sich das Team weiterentwickelt.

Risikominimierung

Durch die Erstellung fertiger Checklisten lässt sich das Auftreten von Fehlern und Problemen drastisch reduzieren. Das Team kann potenzielle Probleme identifizieren und einen Notfallplan erstellen, um auftretende Probleme zu lösen.

Verbessert die Teameffizienz und Arbeitsqualität

Mit einer Checkliste für Produkt-Backlog-Elemente wird das Scrum-Team effizienter, da es weiß, was jede User Story zum Abschließen benötigt. DoRs können auch die Qualität der Arbeit verbessern, da die Teams wissen, was erwartet wird, was zu einer besseren Planung führen kann.

Team-Empowerment

Indem Sie ein Team gemeinsam an der Definition von „Bereit“ arbeiten lassen, fördern Sie eine Atmosphäre der Teamverantwortung. Dies kann die Akzeptanz erhöhen und jedem Teammitglied ein Gefühl der Kontrolle vermitteln.

Herausforderungen der Definition von „Bereit“

Obwohl die Definition fertiger Checklisten Teams dabei helfen kann, die Anforderungen von User Stories zu verstehen und qualitativ hochwertigere Arbeit zu produzieren, können DoRs auch einige Probleme verursachen. Im Folgenden erläutern wir, worauf Sie achten müssen.

DoRs können Teams davon abhalten, agil zu sein

Lesen Sie unseren Leitfaden „Was ist Agile?“ und Sie werden erfahren, dass Agilisten von den Dokumentenstapeln wegkommen wollen, die bei traditionellen Projektmanagementmethoden wie Waterfall verwendet werden. Wenn Teams nicht aufpassen, kann ihre Agilität sinken, da sie mit mehreren Checklisten und Aufgaben jonglieren müssen, die sie erst abschließen können, wenn der vorherige Checklistenpunkt abgeschlossen ist.

DoRs können zu Verzögerungen führen

Wenn Sie sich zu sehr auf die Erstellung einer perfekten User Story konzentrieren, kann es passieren, dass eine Funktion nicht in einen Sprint aufgenommen wird, was zu Verzögerungen führen kann. Denken Sie daran, dass eine User Story, wenn sie noch nicht zu 100 % fertig ist, trotzdem in einen Sprint aufgenommen werden kann, da die User Story angepasst werden kann, während das Team daran arbeitet.

Missverständnisse über DoR-Verantwortlichkeiten können zu Konflikten führen

Es ist wichtig, dass das Entwicklungsteam versteht, dass es eine entscheidende Rolle bei der Definition des fertigen Prozesses spielt und dass die Verantwortung nicht ausschließlich beim Produktbesitzer liegt. Ohne eine angemessene Kommunikation der Rollen und Erwartungen können Konflikte und andere Scrum-Antimuster auftreten.

Tipps zur DoR-Erstellung

Das Erstellen von Definition-of-Ready-Checklisten kann entmutigend sein, insbesondere für neue Teams, aber keine Sorge – wenn Sie unserem Leitfaden folgen und die folgenden Tipps verwenden, werden Sie im Handumdrehen hilfreiche DoRs erstellen.

• Seien Sie klar und präzise: Seien Sie beim Erstellen eines DoR so klar und präzise wie möglich. Vermeiden Sie komplizierte Begriffe, verzichten Sie auf Füllwörter und haben Sie immer den Endbenutzer im Hinterkopf.
• Finden Sie den Wert: Wenn das Team beim Schreiben der User Story den Wert einer Funktion für die Endbenutzer nicht erkennen kann, sollte es sich fragen, ob die Funktion notwendig ist.
• DoRs sollten immer sichtbar sein: Nachdem DoRs erstellt wurden, machen Sie sie sichtbar, damit das einer Aufgabe zugewiesene Mitglied häufig auf die Checkliste verweisen kann.
• Machen Sie DoRs flexibel: DoRs sollten lebendige Dokumente sein, die sich bei Bedarf an Probleme und Änderungsanforderungen anpassen lassen. Stellen Sie sicher, dass das Team weiß, dass DoRs nicht starr sind.
• Halten Sie die Geschichten klein: Achten Sie beim Definieren einer User Story darauf, dass sie klein ist und das Team abschätzen kann, wie lange es dauern wird, sie fertigzustellen. Alle Stories sollten in einem Sprint umsetzbar sein.
• Zusammenarbeiten: Die Erstellung des DoR liegt nicht allein in der Verantwortung des Produktbesitzers. Bringen Sie den PO und das Entwicklungsteam zusammen, um offen zu kommunizieren und zusammenzuarbeiten.

Definition von „Bereit“ im agilen Projektmanagement

Die agile Definition von „bereit“ und die Scrum-Definition von „bereit“ sind identisch. Unabhängig davon, ob Sie ein DoR für Elemente in einem Sprint-Backlog oder Aufgabenkarten auf einem Kanban-Board erstellen, sind die in unserem Leitfaden behandelten Regeln und Richtlinien dieselben.

Was ist die beste Projektmanagement-Software für DoR?

Mit Jira können Benutzer Definitionen fertiger Checklisten in User-Story-Karten erstellen.

Wenn Sie denken, dass das Erstellen von DoR-Checklisten kompliziert und zeitaufwändig klingt, haben Sie keine Angst. Dank Software ist die Definition fertiger Checklisten einfacher als je zuvor. Unser Expertenteam ist der Ansicht, dass Jira, das ganz oben auf unserer Liste der besten Scrum-Software steht, die ideale Plattform zum Erstellen digitaler DoR-Checklisten und zum Verwalten von Scrum-Projekten im Allgemeinen ist.

Die Backlog-Management-Tools von Jira sind robust und einfach zu verwenden.

Wir finden, dass Jira dank seiner Benutzeroberfläche, den Tools zur Verwaltung des Produkt-Backlogs und den Drag-and-Drop-Kanban-Boards einfach zu verwenden ist. Benutzer können schnell Definitionen fertiger Checklisten in Story Cards erstellen, die dann das zugewiesene Teammitglied sehen kann. Jira bietet einen robusten kostenlosen Plan und auch erschwingliche kostenpflichtige Tarife. Weitere Informationen finden Sie in unserem Jira-Test.

Abschließende Gedanken

Wir hoffen, dass unser Leitfaden zur Definition von „bereit“ Ihnen geholfen hat, die Definition von „bereit“ zu verstehen. DoR-Checklisten können Teams dabei helfen, Funktionen für Sprints vorzubereiten und zu qualitativ hochwertigeren Ergebnissen, gesteigerter Effizienz und einem verbesserten Team-Buy-in führen. Solange Sie die Fallstricke kennen, gibt es keinen Grund, DoRs nicht in Scrum-Projekten und agiler Entwicklung zu verwenden.

Fanden Sie unseren Leitfaden hilfreich? Verwendet Ihr Team DoR-Checklisten? Haben Sie Tipps, die wir hier nicht behandelt haben und die Sie gerne weitergeben möchten? Welche Projektmanagement-Software verwenden Sie? Lassen Sie es uns im Kommentarbereich wissen und wie immer vielen Dank fürs Lesen.

FAQ: Die Definition von „Ready“ (DoR)

• Wie definieren Sie „bereit“?

  Die Definition of Ready (DoR) bedeutet, dass sich ein Scrum-Team auf Kriterien für User Stories in einem Produkt-Backlog geeinigt hat, die diese für die Bearbeitung im nächsten Sprint bereit machen.

• Definition von „Bereit“ vs. Definition von „Erledigt“: Was ist der Unterschied?

  Die Definition of Done (DoD) ist eine Reihe allgemeiner Kriterien, die Aufgaben erfüllen müssen, um als abgeschlossen oder erledigt zu gelten. Die Definition of Ready (DoR) bezieht sich auf bestimmte User Stories und darauf, was erforderlich ist, um die Aufgabe für die Bearbeitung in einem bevorstehenden Sprint bereit zu machen.

• Welche Vorteile bietet die Definition of Ready?

  Zu den Vorteilen der Definition vorgefertigter Checklisten gehören eine verbesserte Teameffizienz, eine verbesserte Zusammenarbeit, Teamverantwortung, qualitativ hochwertigere Ergebnisse und Risikominimierung.

Alle anzeigen

Treffen Sie die Experten

Erfahren Sie mehr über unser Redaktionsteam und unseren Rechercheprozess.