Warum die Definition of Ready in hochperformanten agilen Teams sehr kurz ist

Was ist die Definition of Ready?

In der Definition of Ready wird festgehalten, wann ein Product Backlog Item (z.B. User Story) soweit ausgearbeitet ist, dass es in den Sprint "darf".

 

Was ist die Idee?

Die Definition of Done (DoD) ist ein etabliertes Scrum-Konzept: Das Scrum-Team definiert über die DoD, wann alle Arbeiten an einem Product Backlog Items (z.B. User Story) fertig gestellt sind, so dass keine Nacharbeiten mehr notwendig sind. Dies ist in der Regel auch das Kriterium, dass diese Items im Sprint Review demonstriert werden dürfen.

Das Konzept der Definition of Ready (DoR) ist nicht ganz so verbreitet ist wie die DoD. Die DoR definiert, wann ein Product Backlog Item (z.B. User Story) soweit ausgearbeitet ist, dass es in den Sprint "darf". Über die DoR soll sichergestellt werden, dass Product Backlog Items ausreichend vorbereitet in den Sprint kommen und während der Entwicklung nicht ständig der Arbeitsfluss unterbrochen werden muss, weil Dinge unklar sind, die das Team nicht selbst klären kann.

Die Gefahr

Mitunter wird die Definition of Ready allerdings auf eine Art und Weise verwendet, die aus agiler Sicht ungünstig ist. Dann wird ein überregulierter Prozess zwischen Product Owner und Entwicklungsteam etabliert, wo stattdessen eng kooperiert werden sollte.

Dieser Effekt tritt schnell ein, wenn man versucht, Zusammenarbeitsprobleme zwischen Product Owner und Entwicklungsteam durch Erweiterung der Definition of Ready zu lösen. Vielleicht ist der Product Owner im Sprint Review unzufrieden mit dem Produktinkrement und die Ursache ist mangelndes Verständnis des Entwicklungsteams zu einer User Story. Dann mag das Entwicklungsteam versucht sein, dem Product Owner über die Definition of Ready mehr Vorgaben für die Formulierung von User Stories zu machen. Im schlimmsten Fall wird die Definition of Ready eine sehr lange Checkliste für den Product Owner und das Entwicklungsteam weigert sich, mit dem Product Owner über eine User Story zu sprechen, solange die Checkliste nicht abgehakt ist ­– am Besten noch mit Unterschrift des Vorgesetzten des Product Owners.

Dieser Art des Umgangs mit der Definition of Ready passt weder zu Scrum noch zu Agilität.

Das Agile Manifest hat ein paar Dinge über das Verhältnis zwischen Product Owner und Entwicklungsteam zu sagen:

  • “Individuals and interactions over processes and tools”
  • “Business people and developers must work together daily throughout the project.”
  • “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
  • “The best architectures, requirements, and designs emerge from self-organizing teams.”

Ein besserer Umgang mit der Definition of Ready

Die Definition of Ready sollte schlank sein und wenig Vereinbarungen enthalten. Die Vereinbarungen sollten auf die Zusammenarbeit fokussieren und nicht auf Artefakte:

  • "Gemeinsames Verständnis der User Story im Refinement hergestellt" ist wirksamer als "Anforderung liegt in User Story-Satzform vor".
  • "Akzeptanzkriterien wurden gemeinsam im Refinement vereinbart" ist wirksamer als "mind. 5 Akzeptanzkriterien vorhanden".

Schließlich sind die Artefakte (z.B. User Stories) zu diesem Zeitpunkt im Prozess nur Mittel zum Zweck. Sie sollen dazu dienen, ein gutes gemeinsames Verständnis herzustellen. Folglich sollte die Definition of Ready auf gemeinsames Verständis fokussieren.

Entwicklung der Definition of Ready

Die Definition of Ready ist keine statische Vereinbarung. Team und Product Owner lernen gemeinsam, wie die DoR effektiver gestaltet werden kann. Änderungen der DoR werden meist über Retrospektiven initiiert.

Faktisch entwickeln sich Definition of Ready und Definition of Done umgekehrt zueinander: Das Team wird mit der Zeit immer fähiger. Dadurch kann es zum Sprintende mehr zusichern - die Definition of Done wird umfangreicher. Gleichzeitig braucht das Team immer wieder Vorarbeiten von Anderen vor dem Sprint - die Definition of Ready wird immer schlanker.

Hier ist unser Kollege Markus zu sehen.

Über den Autor

Markus Gärtner

Markus arbeitet seit 2010 als Organizational Design Consultant, Certified Scrum Trainer (CST) und Agile Coach für it-agile. Markus präsentiert regelmäßig auf agilen Konferenzen und widmet sich dem Schreiben über agile Softwareentwicklung, Software Craftsmanship und Software Testen, vornehmlich in einem agilen Umfeld. 

Veröffentlichungen (u. a.)

E-Mail:Twitter:LinkedIn:

Mehr von Markus Gärtner

Unser it-agile Lagerraum

Möchten Sie mehr erfahren?

Tauschen Sie sich mit unseren Expert:innen aus und lassen sich zu Schulungen, Coaching oder Wissensthemen beraten.

 

+ 49 40 4135 848-0    info@it-agile.de    Online Termin buchen

Agile Coaching von it-agile

Kennen Sie eigentlich schon it-agile?

Die Expert:innen zu agiler Arbeit und agilen Methoden

Kund:innen wollen begeistert werden. Mit innovativen Produkten, durch Schnelligkeit, Transparenz und auch Verlässlichkeit. Unsere erfahrenen Agile Coaches sorgen gemeinsam mit Ihren Teams und Führungskräften dafür, auch in komplexer Umgebung Ihre Ziele nicht aus dem Auge zu verlieren und implementieren die richtigen agilen Methoden für nachhaltige Veränderung.

  • Wir integrieren Pragmatismus mit Idealismus
  • Wir befähigen Sie nachhaltig ohne Abhängigkeit von uns
  • Wir erzeugen Kundenfokus mit wirkungsvoller Agilität
agile review Magazin

agile review

Unser Kundenmagazin 

In unserem Magazin stellen wir Artikel rund um agiles Arbeiten für Sie zusammen. Das Spektrum reicht von methodischen Themen wie Scrum und Kanban über Agile Leadership bis hin zu technischen Aspekten wie agilem Testen und flexiblen Architekturen.

  • Als Abo oder Einzelausgabe erhältlich
  • Digital oder Print
  • Einzelne Artikel sofort digital verfügbar

Wissens- und Lesenswertes

Das könnte Sie zu Agiler Arbeit auch interessieren

Agile Teams

Ein Haufen abhängiger agiler Teams ergibt noch kein agiles Unternehmen. Die übergreifenden Themen führen zu extremen Overhead, schlechter Vorhersagbarkeit und langsamer Time-To-Market. Diese Probleme…

Agile Teams

Wir hören immer mal wieder, dass Entwickler:innen Scrum hassen - wegen der vielen Meetings. Was steckt dahinter?

Agile Entwicklung

DORA (DevOps Research and Assessment) ist ein wissenschaftliches Studienprogramm, das unser Kollege Andreas Havenstein zur Weiterentwicklung von Teams angewandt hat.

it-agile Newsletter

Sichern Sie sich regelmäßige Neuigkeiten, Inspiration und Tipps zu agiler Arbeit, Konferenzen, aktuelle und neue Termine für unsere Schulungen sowie vieles mehr.


* Benötigte Angaben