Ausrede DoR – Definition of Ready

Immer wieder werden User Stories nicht zur Entwicklung vom Team angenommen, da sie angeblich nicht konform zur sogenannten Definition of Ready sind.

In Pocket speichern vorlesen Druckansicht 2 Kommentare lesen
Lesezeit: 2 Min.
Von
  • Jutta Eckstein

Seit einiger Zeit hat sich speziell bei Scrum-Projekten durchgesetzt, eine Definition of Ready (DoR) zu vereinbaren, die vorgibt, in welchem Zustand User Stories sein müssen, bevor die Entwicklung diese zur Sprintplanung und damit auch zur Umsetzung übernimmt. Im Klartext geht es bei der DoR darum, wie eine User Story spezifiziert zu sein hat, bevor sie vom Entwicklungsteam angenommen wird.

Meines Erachtens widerspricht dies dem Grundgedanken der Agilität. Mittels der DoR wird versucht, sich auf Formalien zurückzuziehen, statt sich über enge Zusammenarbeit und Dialog gemeinsam den Inhalt zu erarbeiten. Ursprünglich waren User Stories lediglich ein Merker, das heißt ein Satz oder Stichwort, der das Versprechen darstellte, gemeinsam über ein Thema zu reden:

A user story is nothing more than an agreement that the customer and developers will talk together about a feature. (Beck & Fowler in Planning Extreme Programming, S.64)

Sprich, User Stories sollten in keiner Weise eine Spezifikation beinhalten. Der Fokus sollte stattdessen darauf liegen, dass das Thema grundsätzlich nicht unter den Tisch fällt und die Stories sollten, wie erwähnt, eine Zusage für die Zusammenarbeit von Kunden (oder Fachexperten) und Entwicklern darstellen. Folglich ist die User Story als Merker das Mittel, um das folgende Agile Prinzip aus dem Manifest umzusetzen:

Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.

Damit wird auch deutlich, dass der Ruf nach einer DoR in der Hauptsache ein Manöver ist, das von der mangelnden Zusammenarbeit zwischen Fachexperten und Entwicklern ablenkt. ()