Jeder Product Owner und jedes Team stehen immer wieder vor der Frage, wie größere Features in einzelne Anforderungen unterteilt werden müssen, oder ob man das überhaupt tun sollte. Dabei ergeben sich gelegentlich höchst eigenartige Auswüchse, wenn z.B. eine einzelne Userstory zum gesamten Inhalt eines Sprints wird, oder man so viele kleine Anforderungen bastelt, dass jeder kleine Button seine eigene Karte auf einer bunt tapezierten Wand bekommt, wie wir Sprint Backlog nennen.
Wandeln wir ein größeres Feature in eine einzelne Userstory um, kommen wir nicht um einen umfangreichen Taskbreakdown herum. Bevor wir den allerdings gemacht haben, ist es sehr schwer, den Umfang und den Aufwand zu schätzen. Grundsätzlich gilt doch sowieso: je größer und komplexer eine Anforderung ist, desto schwieriger wird es für das Team mit einigermaßen akzeptabler Sicherheit irgendeine Aussage zum Umfang und der Schwierigkeit treffen zu können.
Wir bewegen uns also bei umfangreichen Anforderungen immer mit einer größeren Unsicherheit. Nun kann ich argumentieren, dass ich bei vielen kleinen Anforderungen mit vielen kleinen Unsicherheiten leben muss, die sich ebenfalls zu einer größeren aufaddieren. Dennoch sind selbstverständlich einzelne kleinere Probleme leichter zu lösen und einzuordnen als ein großes. Glauben Sie mir: Sie tun sich keinen Gefallen, wenn Sie versuchen, zu große Einheiten zu betrachten. Zu leicht übersieht man ein Detail, dass uns am Ende äußerst schmerzhaft in den Hintern beißt oder uns auf die Füße fällt.
Auf der anderen Seite muss ich mir bei zu kleinen Anforderungen immer die Frage stellen, ab wann ich einen Mehrwert für einen Anwender generiere. Versuche ich, die Platzierung eines einzelnen Buttons in einer Userstory auszudrücken, werde ich es sehr schwer haben, den Wunsch des Kunden auszudrücken. Der einzelne Button bringt ihm herzlich wenig, wenn damit keine Aktion verbunden ist, und die Aktion selbst bringt ihm vielleicht auch nichts, wenn sie aus dem Zusammenhang gerissen wird und allein für sich betrachtet auch keinen echten Nutzwert ergibt.
Wir befinden uns also ständig zwischen zwei Extremen: auf der einen Seite die zu hohe Komplexität, die eine Gesamtsicht erschwert, auf der anderen Seite die übertriebene Einfachheit, die ein einzelnes Element seines Sinns beraubt. Ein ganzes Feature lässt sich wunderbar in einer Userstory ausdrücken, bringt aber schnell sehr viel Komplexität mit sich, so dass der Grundsatz »wenn es sich in einer Userstory ausdrücken lässt, ist es eine passende Anforderung« nicht immer gilt, obwohl wir hier natürlich einen ersten guten Anhaltspunkt haben.
Auf den ganzen Schindluder und die Klimmzüge, die man machen kann, um wirklich alles in die Form einer Userstory zu quetschen, gehe ich an dieser Stelle lieber nicht ein. Wenn man sich bemühen muss, eine Userstory aus einer Anforderung zu schnitzen, die als solche bereits existiert, nur um der Form der Userstory zu genügen, dann macht man eh Irgendetwas grundsätzlich falsch.
Durch das Stichwort »Userstory« kommt aber der zweite Aspekt neben der Komplexität hinzu, der uns auf den richtigen Weg bringt: Nutzen. Jede Anforderung in unserem Sprintbacklog sollte einen Nutzen für den Anwender (oder auch für das Unternehmen oder den Entwickler z.B. bei Infrastrukturaufgaben) haben.
Ich schließe daraus folgende Frage: was ist der kleinstmögliche Nutzen, den ich als Team dem Anwender zur Verfügung stellen kann? Dennoch bleibt auch hier die Tatsache bestehen, dass oftmals ein einigermaßen komplexes Feature nur als Ganzes einen Mehrwert für den Anwender bringt, also sollten wir uns Gedanken über weitere mögliche Schnittmuster für Anforderungen machen. Das gesamte Feature kann dann vielleicht (wenn es klein genug ist) ein Sprintziel sein. Spätestens hier stellen wir uns ja die Frage nach dem Nutzen, den wir einem Anwender geben können.
Wir finden weitere Hilfen und Anhaltspunkte, wenn wir uns die Implementierung als solches betrachten. In komplexeren Anforderungen ist es sehr häufig möglich, einen simplen technischen Durchstich zu machen, der die Funktionalität auf einfache und nicht finale Weise darstellt. Das Ergebnis kann in so einem Fall »Hello World« sein. Erst weitere Anforderungen komplettieren das Bild und kleiden es aus, bis es schließlich einen Stand erreicht hat, den wir unseren Anwender präsentieren können.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
In so einem Fall würde man viele Frontend-Arbeiten zunächst ausklammern und sich vollkommen auf das darunterliegende Datenmodell und die ersten absolut notwendigen Teile der Business-Logik konzentrieren. Wenn Teil der eigentlichen Userstory ist, dass ein Anwender eine Eingabe machen kann (wir wollen also irgendein Formular verarbeiten), könnten wir das Formular selbst ausklammern und vorerst fix gesetzte Daten übergeben, weil wir uns im ersten Schritt ausschließlich um die reine Verarbeitung der Daten kümmern. Die hübsche Eingabeseite ist eine weitere Anforderung. Die Validierung ggf. eine dritte usw. bis wir uns Schritt für Schritt das gesamte Feature aufgebaut haben.
Mit diesem Vorgehen verabschieden wir uns von dem Grundsatz, dass jede Anforderung für sich genommen bereits einen Mehrwert für den Anwender liefern soll. Ich persönlich habe damit jedoch überhaupt kein Problem, weil ich der Meinung bin, dass es schlicht und ergreifend nicht möglich ist, dies immer und unter allen Umständen durchzuhalten. Obwohl wir wissen, dass wir das nie erreichen werden, arbeiten wir aber dennoch darauf hin, weil unser Ziel unverändert ist, dass wir in möglichst kleinen Iterationen Mehrwert für unsere Anwender generieren wollen.
Nehmen wir also gottgegeben hin, dass wir jedes Feature sowieso in mehrere Anforderungen zerlegen, dann neigt man sehr schnell dazu, immer größere Features zu verplanen und sich damit immer länger zurückzuziehen. Ein solches Vorgehen benötigt also eine große Portion Disziplin und die immer wieder gestellte Frage: »Wann haben wir die kleinstmögliche Verbesserung erreicht, die wir unseren Kunden anbieten können?«
Das Zerschneiden von Stories in kleinere Einheiten setzt voraus, dass wir sowohl ein sehr klares Bild von der Anforderungsseite als auch eine gute Vorstellung von der Implementierung haben sollten, weil wir sonst sehr schnell in eine sehr schwammige Planung fallen. Aber sollten wir das nicht sowieso, wenn eine Anforderung ins Sprintbacklog übernommen werden soll?
Der Planungsaufwand bei kleineren Stories ist unbestreitbar leicht höher. Wir müssen vielleicht eine zusätzliche Refinement-Runde mit dem Team drehen. Das Feature ist klar ausgearbeitet, wir haben eine gute Vorstellung von der Art und Weise der Implementierung und würden nun, anstatt 13 Punkte einzupreisen, uns noch einmal darauf verständigen, wie wir die große Anforderung sinnvoll unterteilen. Auch das kostet Zeit, auch das kostet Aufwand. Ich meine dennoch, dass die Vorteile kleinerer Einheiten diesen Mehraufwand im Vorfeld rechtfertigen. Wir eliminieren mehr Fragezeichen, kommen früher in eine Verprobung und entwickeln tatsächlich ein wenig schneller, weil wir vielen Ballast vorerst unangetastet lassen und uns in vielen Fällen sogar dafür entscheiden, dass es die Vollausbaustufe garnicht braucht, weil wir schon früher mit einer kleineren Version die Wünsche des Anwenders abgedeckt haben.
Anforderungen in kleinere Einheiten zu zerschneiden, hilft uns also auch dabei, fokussierter vorzugehen und Dinge, die nicht zwingend notwendig sind, auch einmal nicht zu tun.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
