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.
Als Mitglied erhalten Sie die wichtigsten Thesen des Beitrags zusammengefasst im Management Summary!
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.
Als Mitglied erhalten Sie die wichtigsten Thesen des Beitrags zusammengefasst im Management Summary!
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.
Erster Monat kostenlos,
dann 24,99 € pro Monat
Know-how von über 1.000 Profis
Methoden für alle Aufgaben
Websessions mit Top-Expert:innen
Formulierungsbeispiel
29.11.2024
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.
AQ: Formulierungsbeispile
30.11.2024
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".