Im letzten Beitrag  ließ ich Sie mit der Fragestellung nach dem konkreten WANN und WARUM der Schneidung von User Stories alleine. Wir identifizierten vier Schneidungsaspekte: Daten, Prozess, nicht-funktionale Aspekte und technische Aspekte. Wobei wir die Schneidung nach technischen Aspekten als nicht sehr sinnvoll erachteten und diesen Schneidungsaspekt deshalb in der folgenden Betrachtung außen vor lassen.

Die Geschichte endet wie folgt.

Die Fragen: „WANN schneide ich nach einem bestimmten Schneidungsaspekt?“ und „WARUM schneide ich nach einem bestimmten Schneidungsaspekt?“  fordern die Betrachtung unterschiedlicher Randbedingungen innerhalb derer man sich konkret bewegt und/oder die Betrachtung unterschiedlicher Ziele, die man grundsätzlich verfolgt bzw. die man mit den lieferbaren Inkrementen/Produkten der Sprints erreichen will. Welcher Schneidungsaspekt eingesetzt wird ist also abhängig von den zu Grunde liegenden Randbedingungen und Zielen. Soll möglichst zügig ein Kundennutzen erzeugt werden, so bieten sich die Schneidungsaspekte Daten oder Prozess an, da beide Fachlichkeit zerlegen. Ist es notwendig zunächst die wichtigsten Architekturaspekte zu betrachten, um eine tragfähige Architektur zu entwickeln, so sollte als erstes nach nicht-funktionalen Aspekten geschnitten werden.

Auch hierzu konnten wir also weitere und neue Erkenntnisse gewinnen. Eine Frage jedoch blieb noch offen. Dazu zunächst nochmals die Darstellung der aktuellen Situation: Ausgangspunkt: Eine User Story ist derart umfassend, dass sie nicht komplett in einen Sprint passt. Folge: User Stories müssen in kleinere Teile zerlegt werden. Die Frage, wie wir User Stories zerschneiden können, haben wir mit den vier identifizierten Schneidungsaspekten beantwortet und wir wissen, dass der eingesetzte Schneidungsaspekt von den Zielen und Randbedingungen abhängig ist. Die angesprochene noch offene Frage lautet:

„WIE OFT muss eine User Story zerschnitten werden?“

Hintergrund sind wiederum die festgelegten Sprints. Ein Sprint kann mit nur einer bis hin zu einer größeren Menge von User Stories bzw. Teilen von User Stories beplant werden. Bei der Sprintplanung kommen somit zwei grundlegende Ansätze zur Geltung:

Minimalansatz
Beim Minimalansatz wird die Story zuerst auf den absolut kleinsten, noch in irgendeiner Weise einen Kundennutzen enthaltenen Teil, gekürzt. Würden wir unser Beispiel auf diese Weise schneiden wollen, würden wir genau einen möglichen Partner anhand genau eines Merkmals suchen können und als Sucherergebnis automatisch sein Profil zu sehen bekommen.

Wir haben die Story auf das Minimum eingeschränkt und sie so auf ein leicht und schnell zu entwickelndes Maß gekürzt und dabei den Kundennutzen erhalten (der zugegeben noch nicht besonders hoch ist – jedoch vorhanden). Bietet der Sprint nun noch Zeit um weitere Aspekte umzusetzen folgt eine Risikoanalyse der bisher weggelassenen Aspekte, anhand die für den Projekterfolg kritischsten Teile priorisiert werden. Nun kann die User Story sukzessive um die für den Kunden wichtigsten fehlenden Teile erweitert werden, bis der Sprint vollständig gefüllt werden kann.
Das Prinzip: Wir bewegen uns vom allerkleinsten Teil einer User Story zu einem größeren Umfang, indem weitere Teile hinzugefügt werden.

Eine weitere Möglichkeit um einen Sprint zu füllen bietet sich, indem man weitere per Minimalansatz geschnittene User Stories umsetzt. Auf diese Weise kann relativ schnell eine breite Palette an Funktionalität umgesetzt und in den folgenden Iterationen immer weiter verbessert und ausgebaut werden.

Reduktionsansatz
Beim Reduktionsansatz, werden alle Teilaspekte einer User Story in einem ersten Schritt anhand einer Risikoanalyse priorisiert und dann nach und nach, die für den Sprint am wenigsten Kundenakzeptanz generierenden Teile weggelassen, bis die User Story den gewünschten Umfang erreicht hat.

Gehen wir in unserem Beispiel davon aus, dass das Design der Eingabemaske und die Darstellung der Suchergebnisse am niedrigsten priorisiert wurden, würden diese Teile demnach in einem ersten Sprint nur rudimentär umgesetzt werden. Die restlichen Teile der User Story bleiben erhalten und werden vollständig umgesetzt. Anhand dieses Ansatzes kann gesichert werden, dass für den Projekterfolg elementare User Stories bereits in frühen Iterationen in der nötigen Tiefe umgesetzt werden und keine Zeit für „Goldrandlösungen“ verschwendet wird.
Das Prinzip: Von einer kompletten User Story ausgehen und einzelne Teile wegnehmen.

Dies sollte die letzte für uns zu untersuchende Frage sein. Und somit endet hiermit auch diese kleine (User-) Geschichte. Sie sind gerne eingeladen die vorgestellten Gedanken weiterzuentwickeln, auszuprobieren, etc.

Interesse am Thema „RE & Scrum“? Treten Sie unverbindlich mit uns in Kontakt unter: +49 (0)911 40 9000 oder heureka@sophist.de.