Definition-of-Ready-Retrospektive

Prüft, ob eure Stories vor dem Sprintstart wirklich bereit sind.

Probieren Sie diese Retrospektive live aus

Unsere aktuelle DoR

Wie sieht unsere Definition of Ready heute aus?

Wir sagen, eine Story ist bereit, wenn sie Akzeptanzkriterien hat, aber ich glaube nicht, dass wir uns einig sind, wie „gute“ Akzeptanzkriterien aussehen.
Unsere DoR umfasst: User Story geschrieben, Akzeptanzkriterien definiert, Story geschätzt und Abhängigkeiten identifiziert.
Ehrlich gesagt bin ich mir nicht sicher, ob wir überhaupt eine formale DoR haben. Wir ziehen einfach, was oben im Backlog steht.
Wenn es funktioniert

Was läuft gut, wenn Stories unsere Definition of Ready erfüllen?

Wenn Stories richtig geschnitten sind und klare Akzeptanzkriterien haben, geht das Sprint Planning viel schneller. Wir sind in unter einer Stunde fertig.
Mir fällt auf, dass wir viel weniger Blocker mitten im Sprint haben, wenn Abhängigkeiten schon im Refinement benannt werden.
Das Team traut sich eher, sich auf Stories festzulegen, wenn wir alle vor dem Sprintstart Fragen stellen konnten.
Wenn es hakt

Welche Probleme entstehen, wenn Stories nicht wirklich bereit sind?

Letzten Sprint haben wir eine Story ohne Akzeptanzkriterien reingenommen, und daraus wurde ein dreitägiges Hin und Her mit dem PO.
Stories ohne klaren Scope werden von verschiedenen Entwicklern unterschiedlich „fertig“ gemacht, und dann findet die QA Inkonsistenzen.
Wir entdecken mitten im Sprint ständig Abhängigkeiten, die uns tagelang blockieren. Das sollte im Refinement auffallen.
Unsere DoR verbessern

Was sollten wir ändern, um unsere Definition of Ready zu stärken?

Wir sollten unserer Jira-Ticketvorlage eine Checkliste hinzufügen, damit nichts übersehen wird, bevor eine Story als bereit markiert wird.
Ich fände gut, wenn wir vereinbaren, dass keine Story in einen Sprint kommt, ohne dass es mindestens eine Refinement-Session mit dem ganzen Team gab.
Wir brauchen eine klare Regel: Hat eine Story 48 Stunden vor dem Planning keine Akzeptanzkriterien, wird sie nicht eingeplant.

Was ist eine Definition-of-Ready-Retrospektive?

Ein Sprint läuft besser, wenn die Arbeit darin schon vor dem Planning bereit war. Eine Definition of Ready (DoR) ist die Liste eures Teams mit Einstiegskriterien, die ein Backlog-Item erfüllen muss, bevor es in einen Sprint gezogen wird, etwa Akzeptanzkriterien, eine Schätzung und bekannte Abhängigkeiten. Die Definition-of-Ready-Retrospektive prüft, ob diese Liste ihren Zweck erfüllt. Das Board hat vier Spalten. In „Unsere aktuelle DoR“ haltet ihr fest, wie die Kriterien heute tatsächlich aussehen, und oft zeigt sich, dass das jeder anders sieht. „Wenn es funktioniert“ sammelt Beispiele, in denen bereite Stories reibungslos liefen. „Wenn es hakt“ behandelt, was passiert ist, als nicht bereite Arbeit in einen Sprint gelangt ist. In „Unsere DoR verbessern“ einigt ihr euch auf Änderungen. Nutzt sie, wenn das Planning immer wieder zu lange dauert, Stories mitten im Sprint ins Stocken geraten oder seit Monaten niemand mehr auf eure DoR geschaut hat. Sie eignet sich für Scrum- und Kanban-Teams gleichermaßen. In TeamRetro können alle Ideen anonym einbringen, sodass Probleme beim Refinement auch dann zur Sprache kommen, wenn sie unangenehm anzusprechen sind.

Format der Definition-of-Ready-Retrospektive

Unsere aktuelle DoR

Wie sieht unsere Definition of Ready heute aus?

Bittet alle, aufzuschreiben, was ihrer Meinung nach die aktuellen Kriterien sind. Viele Teams haben eine informelle oder nirgends festgehaltene DoR, und die Unterschiede zwischen den Antworten zeigen euch, wo ihr ansetzen solltet.

Wenn es funktioniert

Was läuft gut, wenn Stories unsere Definition of Ready erfüllen?

Sucht nach konkreten Sprints oder Stories, bei denen die Bereitschaft einen Unterschied gemacht hat, etwa ein kurzes Planning oder eine Story, die ohne Hinterherlaufen fertig wurde. Solche Beispiele zeigen dem Team, warum es sich lohnt, die DoR zu pflegen.

Wenn es hakt

Welche Probleme entstehen, wenn Stories nicht wirklich bereit sind?

Diese Spalte ist meist die aufschlussreichste. Fragt nach konkreten Stories, die ohne erfüllte DoR in einen Sprint gekommen sind, und was danach passiert ist. Achtet auf Muster: Tauchen immer wieder dieselben Lücken auf oder trifft es immer dieselbe Art von Stories?

Unsere DoR verbessern

Was sollten wir ändern, um unsere Definition of Ready zu stärken?

Einigt euch auf konkrete Änderungen, zum Beispiel Kriterien ergänzen oder streichen, das Refinement anders gestalten oder euer Tooling anpassen. Ziel ist, mit 1–3 Änderungen rauszugehen, die ihr im nächsten Sprint ausprobiert.

Wann sollte diese Retrospektive durchgeführt werden?

  • Euer Team stößt immer wieder auf Blocker mitten im Sprint, Scope Creep oder Stories, die im Sprint nicht fertig werden. Das heißt oft, dass die Arbeit beim Planning nicht bereit war.
  • Das Sprint Planning dauert zu lange oder wirkt chaotisch, weil das Backlog nicht verfeinert war, bevor sich das Team festlegt.
  • Ihr nehmt neue Teammitglieder auf und wollt festhalten, was „bereit“ für euer Team bedeutet.
  • Euer Team hat eine Definition of Ready, hat sie aber länger nicht überprüft, und sie passt vielleicht nicht mehr zu eurer heutigen Arbeitsweise.
  • Nach einem schwierigen Sprint, in dem unklare Anforderungen oder fehlende Informationen zu Verzögerungen oder Nacharbeit geführt haben.

Vorschläge für Fragen zum Icebreaker

  • Wenn euer Backlog eine Küche wäre: Wäre es eine gut sortierte, aufgeräumte Speisekammer oder ein chaotischer Kühlschrank voller undefinierbarer Reste, und warum?
  • Was würdest du gern schon zu Beginn einer Aufgabe wissen, erfährst es aber gefühlt immer erst auf halber Strecke?

Möchten Sie eine Aufwärmübung, bei der Ihr Team aktiv mitmacht, und nicht nur laut Antworten gibt? Kostenlose Icebreakers durchsuchen →

Ideen und Tipps für Ihre Retrospektive

  • Teilt eure aktuelle DoR vor der Session, damit alle mit echten Beispielen kommen.
  • Sprecht über Lücken im Prozess, nicht über individuelle Fehler, damit alle ohne Schuldzuweisung schildern können, was schiefgelaufen ist.
  • Setzt für jede Spalte eine Timebox. DoR-Diskussionen werden schnell zum Refinement einzelner Stories, also haltet die Retro bei den Kriterien selbst.
  • Einigt euch pro Session auf 1–3 Änderungen. Eine DoR, die alles abdecken will, wird zu lang, um sich daran zu halten.
  • Bezieht das ganze Team ein, nicht nur Scrum Master oder Product Owner. Entwicklung, QA und Design spüren nicht bereite Stories jeweils auf ihre eigene Weise.
  • Prüft in der nächsten Retrospektive, ob die Änderungen Planning und Umsetzung erleichtert haben.

Häufig gestellte Fragen

Was ist eine Definition-of-Ready-Retrospektive?
Eine Retrospektive, in der ihr die Einstiegskriterien eures Teams für Backlog-Items überprüft. Das Board behandelt eure aktuelle DoR, was funktioniert, wenn Stories sie erfüllen, was hakt, wenn nicht, und was ihr ändern wollt.
Was ist der Unterschied zwischen Definition of Ready und Definition of Done?
Die Definition of Ready legt die Einstiegskriterien fest, die ein Backlog-Item erfüllen muss, bevor es in einen Sprint kommt. Die Definition of Done legt die Abschlusskriterien fest, ab wann Arbeit fertig ist. Diese Retrospektive befasst sich mit der ersten.
Wie oft sollte ein Team eine Definition-of-Ready-Retrospektive durchführen?
Führt sie nach einem schwierigen Sprint mit unklaren Anforderungen durch, wenn neue Leute dazukommen, oder alle paar Monate, um zu prüfen, ob eure DoR noch zur Arbeitsweise des Teams passt.
Ist die Definition of Ready Teil von Scrum?
Nein. Der Scrum Guide definiert eine Definition of Done, aber keine Definition of Ready, die viele Scrum-Teams für sich ergänzen. Haltet sie schlank, damit sie nicht zur Hürde wird, die sinnvolle Arbeit blockiert.
Wie lange dauert eine Definition-of-Ready-Retrospektive?
Für die meisten Teams etwa 45 bis 60 Minuten. Bleibt in der Diskussion bei den Kriterien selbst, sonst wird daraus eine Refinement-Session.

Verwandte Vorlagen

Muttertags-Reflexion

Dankt gemeinsam den Müttern und Bezugspersonen, die euer Team geprägt haben.

Retrospektive „Wanderung zum Wasserfall“

Auf den Anstieg zurückblicken, dann den nächsten Pfad planen.

Cyber-Security-Ops-Retrospektive

Vorfälle, Kontrollen und Lücken gemeinsam im Security-Team auswerten.

Sprint-Klinik-Retrospektive

Die Probleme eures Sprints diagnostizieren und die passenden Lösungen verordnen

Sind Sie bereit, diese Retrospektive durchzuführen?Probieren Sie diese Retrospektive live aus