User Story Splitting
Was ist User Story Splitting?
Als User Story Splitting bezeichnet man das Aufteilen zu großer User Stories. So teilen wir eine zu große User Story in kleinere Stories auf, die für sich aber selbst noch Mehrwert für den Nutzer schaffen. Durch effektives Splitting sind wir in der Lage, früher Mehrwert für den Nutzer zu leeren und aus diesen minimalen Ergebnissen zu lernen.
Weitere Infos zum
Story Splitting
Warum splitten wir User Stories?
Worauf richten wir das Splitten von User Stories aus? Wenn sich die Motivation User Stories zu splitten darauf reduziert, dass das Scrum so vorgibt oder der Scrum Guide es so definiert, dann fehlt oft eine gute Orientierung für vernünftiges Splitting. Regeln ohne die Idee oder das Big Picture dahinter zu verstehen, hat noch nie zu etwas Gutem geführt. Damit wir User Stories sinnvoll splitten, benötigen wir ein gutes Verständnis der inkrementellen Entwicklung, die Scrum zugrundeliegen.
Mehr dazu in der Podcast-Folge Oft missverstanden, inkrementelle Entwicklung in Scrum.
Durch das Splitting von User Stories wollen wir schon früher erste vereinfachte Lösungen schaffen, damit wir:
- schneller ans Endziel kommen und schon früh einen Wert schaffen aus den Teillösungen
- aus den integrierten ganzheitlichen Lösungen lernen und früh Unsicherheiten ausräumen.
Gutes Splitting stellt genau diese zwei Aspekte in den Fokus und versucht den Umfang vorgeschalteter Analysen zu reduzieren. Wir liefern nicht einfach nur, dass was am Anfang gewünscht wurde, sondern lernen aus den Inkrementen, was wirklich gebraucht wird, um das Endziel zu erreichen.
Klicken Sie auf den unteren Button, um den Inhalt von play.libsyn.com zu laden.
Herausforderungen im Splitting von User Stories
Wir sind so stark analytisch vorgeprägt, dass uns dieses ergebnisoffene Lernen aus Inkrementen am Anfang meist fremd ist. Üblicherweise wird somit die Ausrichtung des User Story Splittings aus diesem Grund oft verfälscht und
- es werden umfassende Lösungen “Pixel-genau” vordefiniert, was oft falsche Annahmen manifestiert und das Lernen aus Inkrementen verzögert
- oft wird darauf bestanden, die technischen Voraussetzungen vorher aufzubauen, nur um im Nachklang zu lernen, wo wir am Bedarf vorbei entwickeln
- es werden oft Fachbereiche total überfordert, genau zu beschreiben, was sie wollen und so wird verhindert, dass wir gemeinsam aus Inkrementen lernen können, was wirklich gebraucht wird.
- leider werden heutzutage auch gute Ansätze, wie UX, Design Thinking, Design Sprints eher zur Festschreibung oberflächlich pseudo-validierter Annahmen missbraucht.
Welche Ressourcen für das User Story Splitting gibt es?
Hier eine Übersicht von weiterführenden Artikeln und Ansätzen, die ich für lesenswert halte:
- Patterns for Splitting User Stories
- Splitting User Stories: the Hamburger Method
- How You’ll Probably Learn to Split Features
Oft ist der Einfluss von alten Arbeitsweisen zu stark und deswegen verpuffen die hier beschriebenen Ansätze und wir sind zurück bei der oben beschriebenen traurigen Realität und seinen Herausforderungen.
Wie motiviere ich ein sinnvolles Splitting der User Stories?
Ausgangspunkt für sinnvolle Splittings sind für mich üblicherweise größere Items mit denen auch das Umfeld etwas anfangen kann.
Frühes Schätzen schafft das notwendige Verständnis
Oft ist das Verständnis dieser größeren Items unterschiedlich und hat das Potential, uns in unserem gemeinsamen Verständnis zu verwirren. Aus diesem Grund, hat es sich für mich bewährt, an dieser Stelle, diese groben Items schon früh mit den Entwicklern zu schätzen. Das kanalisiert die wichtigsten Fragen zur Klärung, ohne das wir uns in den Details verlieren. Es erzeugt aber auch ein Bewusstsein für Risiken, Unbekannten und Unsicherheiten bei den Entwicklern, die an dieser Stelle sehr intensiv in dieser frühen Schätzung artikuliert werden. Wenn du mehr wissen möchtest, worauf es meiner Meinung nach bei solchen Schätzungen ankommt, dann hör doch mal in die Folge zu Agile Estimation rein.
Vor dem Splitten schon den Kontext für gutes Splitting schaffen
Die meisten Entwickler würden sich an dieser Stelle eine Analyse der Anforderung wünschen. Also ein herunter brechen dieser Anforderung in kleinere vermeintlich beherrschbare Teilelemente, um für diesen Kontext erstmal eine technische Basis zu schaffen. Das Problem ist nur, dass in den meisten Fällen genau dieses Vorgehen der Grund ist, warum Probleme erst spät erkannt werden und wir Lösungen in eine völlig falsche Richtung entwickeln.
Deswegen möchte ich gern bei den Entwicklern ein Bewusstsein für diese Problemstellung erzeugen. Dies mache ich meist in folgendem Dialog:
Ich: “Wie oft habt ihr solche Lösungen, wie diese schon entwickelt?”
Erfahrener Entwickler: “Wir sind Experten und haben schon Einiges in diesem Bereich gemacht!”
Ich: “Ok, und wie oft habt ihr die Lösung ohne Stress am Ende abgeliefert und zudem zur vollen Zufriedenheit von Nutzern und Stakeholdern?”
Entwickler: “Ralf, wir dachten du bist Praktiker?! Natürlich gehören hier Probleme dazu und die Zeit vor der Auslieferung ist normalerweise sehr stressig und Missverständnisse von den Auftraggebern sind auch eher die Regel!”
Ich: “Verstehe! Dann lasst uns doch hier einmal gemeinsam etwas aufstellen, um möglichst früh zu lernen, wo wir noch etwas bewegen bzw. verbessern können.”
Erst in der Breite, Perspektiven und Optionen sammeln
Aufbauend zu dem Problembewusstsein, lasse ich das Scrum Team Folgendes zusammentragen:
- Was sind die größten Unsicherheiten, Unbekannten und Risiken bei dieser User Story?
- Wo liegt der größte Aufwand, in der Entwicklung der Lösung für diese User Story?
Aus diesem Kontext lassen sich dann gemeinsam Ideen zum Splitting sammeln.
Zudem sinnvolle Splittings entwickeln
Ausgehend von der groben User Story, den Aufwandstreibern (die wir in den Splittings möglichst rausnehmen wollen) und den Risiken (auf die wir die ersten Stories zum lernen ausrichten wollen) können wir jetzt aufbauend Ideen zur Vereinfachung sammeln. Idealerweise fragmentieren diese nicht die User Story in technische Komponenten oder isolierte Funktionalitäten, sondern geben eher ein ganzheitliches Bild des ganzen Systems.
In dieser Podcast-Folge erzähle ich dazu einige meiner eigenen Stories, mit denen ich aus meiner Erfahrung heraus, die Suche nach passenden Splitting-Ideen motiviert habe.
Aus der Fülle an Ideen zur Vereinfachung, können wir jetzt gemeinsam die richtigen Splittings finden und suggestive die User Stories splitten. Bis diese ausreichend klein für den kommenden Sprint sind. Aufbauend aus dem gemeinsamen Splitting der User Stories entsteht ein klarer Fokus, wie wir aus den einzelnen Sprints lernen und gemeinsam das Produkt ausgestalten.
Fazit
Wenn alle im Team verstehen, warum wir User Stories splitten, dann ist es leicht grobe Themen in kleinere Teile runter zu brechen. Hilfsmittel, wie die großartigen Splitting-Patterns von Richard Lawrence helfen, wenn Teams anfänglich nicht solch ein Verständnis mitbringen.
