Eine »Definition of Done« findet sich inzwischen in den meisten Teams, anders sieht es jedoch mit der »Definition of Ready« aus, an der sich orientiert, wann eine Anforderung gut genug ausgearbeitet und formuliert ist, um in den Sprint übernommen zu werden. Wie steht es in Ihrem Team?
Zunächst einmal möchte ich über meine Definition der Definition of Ready sprechen, damit wir von der selben Sache reden. In der Literatur finde ich diese sowohl als Checkliste, wann eine Anforderung in den Sprint übernommen werden kann, als auch wann eine Anforderung in das Backlog übernommen werden kann.
Zu dieser Frage habe ich eine ganz eindeutige Meinung: In das Backlog kann und sollte ich auch die etwas weiter entfernten Dinge, die noch nicht konkret ausgearbeitet sind, übernehmen. Je näher sie rücken, desto detaillierter werden sie. In einen Sprint kann ich nur Anforderungen nehmen, von denen ich sehr genau weiß, was damit gemeint ist. Alles andere wäre fahrlässig. Da ich im Prinzip alles ins Backlog schieben kann (auch ein einzelnes Wort als Merker auf einer Karte, das für ein ganzes Epic steht), benötige ich nur eine Definition, wann eine Anforderung gut genug für den Sprint ist. Für mich bezieht sich die Definition of ready also ganz eindeutig auf die Frage, wann ich eine Story/Karte/Anforderung in meinen Sprint ziehen kann.
Ähnlich der Definition of Ready soll die DoD uns dabei helfen, Dinge bewerten zu können. Bei einer Definition of Done habe ich im Prinzip eine Checkliste, auf der ich alle Punkte abhaken kann. Habe ich das getan, gilt eine Anforderung als umgesetzt. Die Definition of Ready setzt früher an, indem Sie mir eine Chekliste gibt, ab wann eine Anforderung zur Umsetzung bereit ist.
Die DoD sollte grundsätzliche Dinge beinhalten, die in jedem Team gelten sollten, z.B. »ist durch den Owner abgenommen« und »ist getestet«. Darüber hinaus hat sie aber im allgemeinen auch spezifischere Punkte, die sich auf das Unternehmen, das Team und die Art des Vorgehens beziehen. So können sich darauf auch Punkte finden wie »ist in den Master gemerged« oder »Code Review«.
Eine DoR befasst sich dagegen nicht mit einem konkreten Stück Software, sondern mit der Vorstufe davon. Daher ist der Bewertungsraum ein anderer, der – wie man meinen sollte – für alle Teams in allen Unternehmen ähnlich sein sollte. Und das ist auch tatsächlich der Fall. Wenn Sie sich mit dieser Thematik beschäftigen, werden Sie sehr schnell auf INVEST stoßen, ein Acronym für Independent, Negotiable, Valuable, Estimable, Small, Testable.
Eine kurze Übersicht
Independent: Ihre Anfoderungen innerhalb eines Sprints sollten voneinander unabhängig sein, so dass man sie parallel bearbeiten kann. Auch wenn wir immer darum bemüht sind, wird es uns dennoch nicht immer gelingen. Jeder Entwickler weiß, dass es sich manchmal schon aus technischen Gründen nicht vermeiden lässt, in Abhängigkeiten zu laufen. Wir brauchen eben manchmal Dies, um dann Jenes tun zu können.
Für uns ist jedoch wichtig, dass wir beim Storyschnitt diese Frage bewusst machen und diese Abhängigkeiten vermeiden, wenn es uns möglich ist. Wenn wir feststellen, dass wir sehr häufig in diese »Erst das Eine dann das Andere« Schleife kommen, dann sollten wir einen Schritt zurückgehen und unser Vorgehen genau beleuchten.
Negotiable: Mit diesem Punkt habe ich ein Problem. Sobald eine Anforderung im Sprint ist, sollte sie nur noch in Ausnahmefällen verhandelbar sein. Es kann zwar durchaus sein, dass neue Erkenntnisse, die man plötzlich erhält, dazu führen, dass einzelne Anforderungen unwichtig werden und aus dem Sprint entfernt werden, doch in der Regel sollte das Planning für einen Sprint Bestand haben.
Dieser Punkt bezieht sich auf eine Anforderung im Backlog. So lange sie noch nicht im Sprint ist, steht sie stets auf dem Prüfstand, ob ich sie überhaupt umsetzen will, wann ich sie umsetzen will, in welcher Form ich sie umsetzen will. Diese Fragen sind beim Sprintstart jedoch bereits beantwortet.
Valuable: Jede Anforderung im Sprint sollte einen Wert haben. Darüber werden wir uns sicherlich nicht streiten. Zu knapp ist mir aber die Aussage gefasst, dass jede Anforderung einen Wert für den Anwender haben sollte. Notwendige Refactorings im Code interessieren unsere Anwender herzlich wenig, dennoch stellen sie einen gewissen Wert dar. In diesem Fall nutzt es jedoch nicht unseren Kunden sondern uns selbst.
Hier finden wir eine große Schwierigkeit, da wir immer bewerten müssen. Haben unsere Kunden Wünsche geäußert oder haben sie ganz klare Bedürfnisse, ist diese Bewertung leicht. Schaffen wir jedoch »nur« etwas für uns selbst (und nichts Anderes ist ein Refactoring), dann müssen wir uns immer wieder die Frage stellen, wie wichtig diese eine Sache jetzt ist. Ist sie Selbstzweck oder hat sie einen harten Untergrund, weil die Weiterentwicklung auf der vermurksten Codebasis unfassbar fehleranfällig ist? Wie lange könnten wir noch mit diesem Zustand leben?
Unsere Kunden sind auch nicht immer unsere Kunden. Manchmal sind es auch andere Personen im eigenen Unternehmen. Z.B. kann es sein, dass wir eine Funktionalität bauen müssen, mit der ein Supporter Zugriff auf bestimmte Daten erhält. In diesem Fall wird die Supportabteilung in unserem eigenen Unternehmen zu unserem Kunden.
Estimable: Eine Anforderung sollte schätzbar sein. Das scheint eine klare und eindeutige Sache zu sein, doch dahinter verbirgt sich die Regel, dass eine Story/Anforderung so konkret ausgearbeitet und besprochen sein sollte, dass jeder Entwickler eine sehr gute Vorstellung vom Umfang und Schwierigkeit hat. Schätzen können wir nur dann, wenn wir schon eine ganz gute Idee davon haben, wie wir etwas umsetzen können. Dazu müssen wir sehr genau wissen, was wir umsetzen wollen. Dieser Punkt besagt also, dass eine Anforderung »geschärft« sein muss.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Small: Wir alle wissen, dass eine einzelne Story nicht größer als ein Sprint sein kann, aber das Ziel ist nicht eine Story gleich ein Sprint. Unser Ziel liegt darin, dass wir mehrere Stories in einem Sprint bearbeiten, die gemeinsam einen Nutzen für den Anwender ergeben.
Der Vorteil möglichst kleiner Anforderungen/Stories (ich nutze lieber den Begriff »Anforderung« als Story, weil nicht immer alles eine User Story sein muss) ist, dass ich sie leichter handeln kann. Je kleiner eine Anforderung ist, desto klarer kann ich sie fassen und ausarbeiten, desto leichter kann ich sie schätzen, desto genauer kann ich sie planen. Es liegt also im Interesse jedes Teams und jedes Product Owners, die Anforderungen so klein wie möglich zu schneiden.
Ich waren jedoch davor, dabei übers Ziel hinaus zu schießen. Wenn Sie aus jedem noch so kleinen Detail eine eigene Anforderung machen, dann erzeugen Sie sehr schnell einen gewaltigen Overhead. Die Kunst liegt im sinnvollen Schneiden von Stories, nicht darin, sie möglichst klein zu machen. Zu diesem Thema allein kann man ganze Bücher schreiben. Ich denke, dass ich in naher Zukunft ein paar Gedanken dazu niederschreiben werde.
Testable: Auch dieser Punkt zwingt uns dazu, den Storyschnitt an sich zu bedenken. Eine Sache ist nur dann testbar, wenn sie eindeutig ist. Ich kann dann sagen, sie funktioniert oder sie funktioniert nicht. Dies ist mir jedoch nicht möglich, wenn ich die Anforderung nicht eindeutig genug gemacht habe. Dann könnte ich in die Situation kommen, dass ich sagen muss, dass mein Ergebnis eine Sache kann, eine andere jedoch nicht. War diese nun Teil der Anforderung oder nicht?
Testen kann ich nur dann Dinge, wenn mir das gewünschte Ergebnis bekannt ist, ansonsten wüsste ich nicht, was ich worauf testen sollte. Bei der Ausarbeitung der Anforderung ist dies also ein ganz wichtiger Punkt.
Wenn wir uns also INVEST genauer betrachten, stellen wir fest, dass es nicht mehr als eine gute Sammlung von Anhaltspunkten und Hinweisen ist, als konkrete Definition of Ready halte ich es jedoch nicht für geeignet. Der Punkt »Negotiable« passt einfach nicht, und die anderen sind zum Teil nicht eindeutig genug. Dennoch ist es ein guter Ausgangspunkt.
Wir könnten also folgendermaßen beginnen: Voneinander unabhängige Anforderungen sind unser Ziel. Wenn sie es nicht sind, müssen wir begründen können, warum sie es nicht sind. Jede einzelne Anforderung sollte darauf überprüft werden können.
Jede Anforderung sollte eine Verbesserung darstellen. Diese kann für unsere Kunden gelten, für andere Personen im Unternehmen, oder für uns selbst. Wir stellen uns also bei jeder Karte in unserem Sprint-Backlog die Frage: Wem hilft das auf welche Weise?
Jede Anforderung in unserem Sprint Backlog ist geschätzt. Schätzen können wir nur, was wir genau verstehen und was klar genug umrissen ist. Dieser Punkt umfasst auch »Testable«, da ich nur das testen kann, was eindeutig beschrieben ist.
»Klein« schlägt ebenfalls in diese Kerbe. Je größer eine Sache ist, desto schwerer wird es, sie eindeutig und umfassend zu beschreiben.
Bitte verstehen Sie dies nicht als vollständige Definition of Ready, die Sie 1:1 kopieren könnten. Den Anspruch erhebe ich nicht. Mein Ziel an dieser Stelle ist es nur, bei Ihnen das Bewusstsein zu schärfen, wie eine solche DoR Ihnen helfen kann, und wie diese Ihnen beim Erstellen guter Anforderungen helfen kann.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
