Ein Elefant zum Frühstück – Wie geht User Story Slicing?

Was halten Sie von einem Elefanten-Carpaccio? Richtig, Sie verstehen mich schon richtig: Carpaccio – also sehr dünn geschnittene Scheiben – aus Elefantenfleisch. Sicherlich hört sich das abwegig und auch ein bisschen… brutal an. Aber genau das hat Alistair Cockburn, ein agiles Urgestein, erfunden. Zum Glück nur als ein Konzept, um große Features in kleine “Scheiben” von User Stories zu zerteilen. Wenn Sie weiter Beruhigung brauchen, dann können Sie sich auch eine leckere Schwarzwälder Kirschtorte vorstellen, die Sie in Stücke schneiden. Beide Bilder haben eines gemeinsam: Sie wollen das User Story Slicing darstellen. Ich möchte heute erläutern, wie das am besten funktioniert und was der Elefant bzw. der Kuchen damit genau zu tun hat.

Was ist eine User Story?

Durch das User Story Slicing trennen Sie Funktionen mit hohem Mehrwert von denen mit geringerem Mehrwert, sodass Sie diese priorisieren und die Umsetzung planen können. Bevor Sie aber damit beginnen können, muss klar sein, was als Ergebnis Ihrer Arbeit herauskommen soll.

Eine User Story ist eine kurze Beschreibung einer gewünschten Systemfunktion, die folgender Formulierungsregel folgt:

Als (Rolle) möchte ich (Funktionalität), um (Nutzen) zu erhalten.

Neben diesem Schema muss sie spezielle Eigenschaften erfüllen, damit sie als echte User Story gilt. Nach Bill Wake sollte sie dem INVEST-Prinzip folgen [1]:

• Independant (unabhängig): User Story kann für sich allein Mehrwert schaffen.
• Negotiable (verhandelbar): Wie genau die User Story realisiert wird, ist nicht festgelegt.
• Valuable (wertvoll): User Story schafft Mehrwert für Stakeholder.
• Estimable (schätzbar): User Story ist so detailliert, dass sich der Aufwand durch Entwickler schätzen lässt.
• Small / Sized appropriately (klein/angemessen groß): User Story lässt sich innerhalb einer definierten Zeitspanne umsetzen.
• Testable (testbar): Umsetzung der User Story kann geprüft werden.

Auch der Elefant selbst – also das große Feature – muss diese Eigenschaften besitzen. Deshalb lässt sich das Attribut klein auch als angemessen groß interpretieren. Die Eigenschaften spielen weiterhin eine Rolle, um eine User Story von einem Task zu unterscheiden. Ein Task entspricht einem Arbeitsschritt für die Realisierung der Story, muss aber nicht die INVEST-Kriterien erfüllen. Oder um es mit den Worten von Mike Cohn, einem weiteren agilen Urgestein, auszudrücken:

“[…] stories contain multiple types of work (e.g. programming, testing, database design, user interface design, analysis, etc.) while tasks are restricted to a single type of work.” [2]

Warum diese Unterscheidung wichtig ist, sehen Sie gleich.

Ein ganzes Tortenstück oder doch nur die Schicht Sahne oben drauf?

Mit diesem Ziel vor Augen, komme ich zur nächsten Frage: Wie “zerschneidet” man das Feature in kleine User Stories? Stellen Sie sich nun wieder die Schwarzwälder Kirschtorte vor. Wie würde diese schmecken, wenn ich Ihnen nur die obere Sahneschicht anböte? Oder eine Schicht des Bodens? Höchstwahrscheinlich sieht ein gelungenes Kaffeekränzchen anders aus. Anstatt horizontal durch die Torte zu schneiden, ist doch ein vertikaler Schnitt, um Tortenstücke mit allen Schichten zu erhalten, sinnvoller und leckerer. Das trifft auch auf das Slicen von User Stories zu.

Die verschiedenen Schichten eines Kuchens entsprechen in der Software-Entwicklung beispielsweise der Daten-, Logik- und Präsentationsschicht. Eine User Story könnte nun wie folgt lauten:

“Als Online-Shop-Kunde möchte ich ein Formular haben, um meine Login-Daten einzugeben.”

Basierend auf dieser Formulierung entwickeln Sie das Formular, man kann Nutzernamen und Passwort wunderbar eingeben und – nichts passiert. Das Backend, also die Speicherung der Daten in eine Datenbank, sowie eine Rückmeldung für den oder die Nutzerin fehlt. Sie haben einen horizontalen Schnitt durch die Torte gemacht und können dadurch Ihren Gästen bzw. Stakeholdern nur Sahne anbieten. Die werden sich bestimmt freuen.

Nach diesem Prinzip müssten Sie jetzt weitere Stories für die technischen Schritte anlegen. Keine dieser Stories schafft jedoch für sich allein einen Mehrwert. Deshalb müsste man an dieser Stelle von Tasks sprechen (das hat ein versierter User-Story-Schreiber natürlich sofort erkannt).

Besser ist es daher, einen vertikalen Schnitt durch die funktionalen Schichten zu machen. Eine User Story lautet dann beispielsweise:

“Als Online-Shop-Kunde möchte ich mich auf der Website anmelden, um wiederkehrende Bestellprozesse schnell durchführen zu können.”

Hier schaffen Sie nun tatsächlich Nutzen aus der Sicht der Rolle und Stakeholder können sich das Ergebnis „schmecken lassen“.

Strategien für das User Story Slicen

Das INVEST-Prinzip bildet eine erste Richtlinie für das vertikale User Story Slicing. In der Praxis steht man vor der Herausforderung, die Theorie richtig anzuwenden. Richard Lawrence [3] und Lasse Koskela [4] haben daher Muster bzw. Strategien für das Verfeinern einer User Story basierend auf ihren praktischen Erfahrungen zusammengestellt mit der Aussage, dass oftmals eine Kombination für das Slicen notwendig ist.

Eine der Strategien ist das Verfeinern nach Workflow. Stellen Sie sich beispielsweise vor, dass Sie ein Buch aus einer Bibliothek ausleihen wollen. Folgende Grafik veranschaulicht den Workflow:

Ein Workflow, der in User Stories zerlegt werden soll

Im ersten Schritt müssen Sie den Nutzen in dem Workflow identifizieren. Zumeist befindet er sich ganz am Ende oder in der Nähe davon. In diesem Beispiel ist der Nutzen, das Buch mit nach Hause nehmen zu können.

Als nächstes wenden Sie sich dem Anfang des Workflows zu. Welcher Vorgang ist dort mindestens notwendig, um den Workflow zu starten? (Hier: Ausweis vorlegen). Mit Beantwortung dieser Frage haben Sie nun einen Start- sowie Endpunkt für die erste User Story. Um diese zu vervollständigen, brauchen Sie noch Schritte dazwischen. Hier orientieren Sie sich daran, welche Vorgänge mindestens notwendig sind, um zum Endpunkt, d. h. dem Nutzen, zu gelangen:

Brauchen Sie unbedingt den Beleg, um das Buch mitnehmen zu können? Nein, das ist ein zusätzlicher Mehrwert, den Sie für die erste User Story vernachlässigen können. Er lässt sich in den weiteren User Story Slices berücksichtigen. So entstehen insgesamt zwei User Stories. Sie können noch zusätzliche Vorgänge im Workflow darstellen, sodass sich weitere User Stories daraus ergeben (z. B. Ausgeliehene Bücher einsehen oder Ausleihen abbrechen).

Neben dem User Story Slicing nach Workflow gibt es u. a.:

• Slicing nach Aufwand (Welche Funktion benötigt am meisten Aufwand zur Umsetzung? User Stories nach Aufwänden zerschneiden.)
• Slicing nach einfach oder komplex (Wie sieht die einfachste Variante einer Funktion aus? Die komplexen Varianten in andere User Stories auslagern.)
• Slicing nach Operationen (Welche Vorgänge umfasst die User Story? Anstatt etwas zu “verwalten”, wollen Anwender etwas “erstellen”, “lesen”, “aktualisieren” oder “löschen”, wodurch sich mehrere User Stories ergeben.)
• Slicing nach Rollen (Aus welchen Perspektiven lässt sich die User Story formulieren? User Stories aus diesen Perspektiven formulieren.)

Das Elephant Carpaccio

Das Elephant Carpaccio entspricht einer Übung bzw. einem Workshop, in dem Sie das User Story Slicing praktisch erlernen und anwenden. Ursprünglich von Alistair Cockburn vorgestellt, hat Henrik Kniberg eine angepasste Version entwickelt [5], die ich Ihnen kurz vorstellen möchte.

In 90 bis 120 Minuten entwickeln Sie in einer Gruppe von bis zu 30 Leuten einen Mini-Taschenrechner für den Einzelhandel, der u. a. den Gesamtpreis der Waren ausgeben soll. Kniberg fordert in dieser Übung, mindestens 10 bis 20 User Story Slices zu erzielen. Jedes Slice muss eine Benutzeroberfläche sowie Eingaben und Ausgaben vorweisen. Die Gruppe teilt sich in Teams und stellt Backlogs zusammen, wobei jeder Slice natürlich dem INVEST-Prinzip entsprechen muss. Zudem priorisieren sie die Slices auf einer Mehrwert-Kurve. In dieser Übung gehört es dazu, die Funktionen tatsächlich zu programmieren, sodass am Ende ein funktionsfähiges Ergebnis vorliegt. Wer mehr darüber erfahren möchte, kann hier nachlesen (auf Englisch).

Das Konzept Use Case 2.0

Die Idee des vertikalen Slicens finden Sie auch bei Use Cases.  Ivar Jacobson et al. haben 2014 das sogenannte Use Case 2.0-Konzept vorgestellt, in dem Sie Use Cases in dünne Scheiben – sogenannte Use Case Slices – zerlegen [6]. Jeder Use Case wird durch einen Basic Flow beschrieben, der einen Start- und Endpunkt vorweist. Um Abweichungen vom Normalfall darzustellen, definieren Sie Alternative Flows. Die Planung erfolgt anschließend mit Use Case Slices. Auch bei Use Case Slices gilt: Jeder Slice liefert ein Stück Software und Mehrwert für die Stakeholder.

Wie Sie mit einem Tool das Use Case 2.0-Konzept anwenden können, erfahren Sie im folgenden Video:

Fazit

Obwohl die Idee von User Stories bereits seit einigen Jahren bekannt ist, ist das User Story Slicing noch immer ein heiß diskutiertes Thema. Denn die Formulierung von nutzenbringenden User Stories stellt in der Praxis eine Herausforderung dar. Das INVEST-Prinzip und das vertikale Schneiden durch die Funktionen bietet Ihnen eine solide Grundlage, um User Stories zu definieren. Weitere Strategien aus der Praxis haben Sie heute ebenfalls kennen gelernt. Damit Sie das Vorgehen erlernen und verinnerlichen, bieten sich Übungen wie das Elephant Carpaccio an. Probieren Sie es doch einmal aus und schreiben Sie uns Ihre Erfahrungsberichte!

Die Ergebnisse Ihrer harten Slicing-Arbeit halten Sie am besten mit dem passenden Tool wie objectiF RPM fest, mit dem Sie gleich die Planungsarbeit für Releases und Sprints anschließen können. Und wenn Sie einmal eine Schwarzwälder Kirschtorte zu viel haben, dann können Sie uns diese gern vorbeibringen. Wir zerschneiden sie fachgerecht in einzelne Stücke für alle Kolleginnen und Kollegen :)

Hinweise:

[1]: Wake, Bill (August 2003): INVEST in Good Stories, and SMART Tasks. Abgerufen unter: https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

[2]: Cohn, Mike (Februar 2015): The Difference Between a Story and a Task. Abgerufen unter: https://www.mountaingoatsoftware.com/blog/the-difference-between-a-story-and-a-task

[3]: Lawrence, Richard (Oktober 2009): Patterns for Splitting User Stories. Abgerufen unter: https://agileforall.com/patterns-for-splitting-user-stories/

[4]: Koskela, Lasse (Juni 2013): Ways to Split User Stories: Abgerufen unter: https://web.archive.org/web/20120909082905/http://lassekoskela.com:80/thoughts/7/ways-to-split-user-stories/

[5]: Kniberg, Henrik (Juli 2013): Elephant Carpaccio facilitation guide. Abgerufen unter: https://blog.crisp.se/2013/07/25/henrikkniberg/elephant-carpaccio-facilitation-guide

[6]: Jacobson, I./Spence, I./Kerr, B. (Januar 2016): Use-Case 2.0: The Hub of Software. Abgerufen unter: https://www.ivarjacobson.com/sites/default/files/field_iji_file/article/use-case_2.0_final_rev3.pdf