Definition of Ready – Weder agil noch Dokumentation?

Nachdem die letzten Beiträge sich hauptsächlich mit der Produktdokumentation beschäftigt haben, möchte ich nun eine Methodik zur Projektdokumentation vorstellen. Die „Defintion of Ready“ findet immer mehr Zuspruch in Scrum, obwohl sie in der Kritik steht, dass sie gegen agile Prinzipien verstößt. 

Die Defintion of Ready (DoR) beinhaltet Kriterien, die bspw. eine User Story erfüllen muss, um von dem Entwicklungsteam im anstehenden Sprint bearbeitet werden zu können. Darunter fallen je Unternehmenskontext unterschiedliche Aspekte wie z.B.:

  • Abhängigkeiten zu anderen Teams oder Abteilungen sind geklärt
  • Akzeptanzkriterien stehen fest
  • Nutzen der Story ist verstanden
  • Stakeholder sind bekannt
  • Klarheit, wie der Erfolg der Umsetzung gemessen werden kann

Man könnte diese Liste als Quality Gate zwischen Product Owner und dem Entwicklungsteam verstehen. Erst wenn die Stories „ready“ sind, können sie vom Team angemessen bearbeitet werden. Dieser Aspekt lässt viele Agilisten aufhorchen. Ein User Story ist eigentlich dafür gedacht mit maximal zwei Sätze eine Grundlage für den Austausch zwischen den Fachexperten und den Entwicklern zu sein. Das gesprochene Wort ist das agile Medium, während die DoR wieder Tür und Tor für breite Anforderungsdokumente und Konzepte zu öffnen scheint.

Aber auch eine DoR kann agil sein, wenn man sie agil einsetzt. Es ist ein Unterschied, ob der Productowner alleine für die Erfüllung und Ausarbeitung der DoR zuständig ist oder ob sie vom Team gemeinsam für das Refinement verwendet wird. Das Refinement steht zwar ebenfalls nicht explizit im Scrum Guide, ist aber als fester Bestandteil von Scrum anerkannt. Die beiden Scrum-Schöpfer Ken Schwaber und Jeff Sutherland empfehlen, etwa zehn Prozent der Zeit für die Vorbereitung der kommenden Sprints zu investieren.

Mit dem Refinement anhand einer DoR ist nicht gemeint, dass alles schriftlich festgehalten wird. Die Liste dient als Gedankenstütze und wird abgehakt, wenn man darüber geredet hat und Einigkeit besteht, wie man als Team mit diesem Punkt im anstehenden Sprint umgehen möchte. Es widerspricht also keineswegs dem Grundgedanken der User Story, sondern erweitert diese, um einige Agendapunkte im Gespräch zwischen Team und Fachexperten. Je eingespielter das Team über die Zeit ist, desto mehr Punkte können von der DoR in die Definition of Done übernommen werden.

Spätestens wenn die Story im Sprint „done“ ist, kann das Dokument gelöscht bzw. entsorgt werden. Projektdokumentation ist Wegwerfdokumentation. Wir legen daher zu jeder Story eine Confluence-Seite an, auf der die DoR abgehakt wird und relevante Artefakte, wie eine Projektskizze oder Designentscheidungen festgehalten werden. Nach dem Sprint wird diese Seite einfach wieder gelöscht, denn alles relevante ist in die Produkt- bzw. Systemdokumentation geflossen.

Referenzen