SPIDR – Mit 5 einfachen Techniken zur perfekt geschnittenen User Story

Vor einiger Zeit habe ich eine interessante und hilfreiche Methode entdeckt, mit welcher sich User Stories einfacher und effektiver schneiden, also in leichtgewichtigere Stories unterteilen, lassen. 

Agile Trainer und Mitgründer der Scrum Alliance Mike Cohn stellte fest, dass “almost every story can be split with one of five techniques”. Diese fünf Techniken fasst er unter dem Akronym SPIDR zusammen.

Zunächst einmal gibt es zwei Arten von User Stories, die sich fundamental voneinander unterscheiden:

• User Stories, die von Grund auf extrem groß sind und sich nicht zerteilen lassen, aber auch extrem selten vorkommen
• und zusammengesetzte User Stories, die viele kleinere Stories beinhalten und somit gesplittet werden können.
  
  
  

Zusammengesetzte User Stories teilen

Die Anforderung an eine User Story ist laut dem INVEST-Prinzip, dass sie “klein” genug sein bzw. die richtige Größe besitzen muss. Eine User Story sollte so klein sein, dass 6-10 von diesen Stories in einem Sprint erledigt werden können. Dies hängt natürlich immer auch von der Velocity des Entwicklungsteams ab. Um diese Ziel prinzipiell erreichen zu können, muss eine große Story entsprechend geschnitten werden.

Nun gibt es mehrere Techniken und Hilfsmittel, mit denen sich solche zusammengesetzten User Stories zerteilen lassen. Beispielsweise stellt Richard Lawrence ein umfassendes Poster vor, welches den Betrachter durch einen Prozess leitet, der beim User Story splitten unterstützen soll. Im Folgenden möchte ich euch jedoch gerne die simple und schnelle Methode “SPIDR” von Mike Cohn vorstellen. Mit dieser Methode fasst er 5 Techniken zusammen, mit denen sich fast jede solcher User Stories aufteilen lassen.

Spikes

Spike ist ein Begriff, der in der agilen Softwareentwicklung verwendet wird. Spikes sind kleine, prototypische Implementationen einer Funktionalität, die typischerweise zur Evaluation und Machbarkeit neuer Technologien verwendet werden.

Diese Methode beinhaltet, dass Untersuchungen angestellt werden und Wissen aufgebaut wird. Sie sollte verwendet werden, wenn die anderen SPIDR-Methoden zu keinem guten Ergebnis geführt haben. Mit Hilfe dieses neu gewonnenen Wissens lassen sich manche Stories anschließend besser verstehen und unter Umständen einfacher aufteilen. Diese Methode ist jedoch relativ abstrakt und aus diesem Grund schwerer anwendbar, als die nachfolgenden.

Path

Wenn es in einer User Story mehrere mögliche Alternativpfade gibt, dann besteht die Option, für einige dieser Pfade eine separate User Story zu verfassen. Es ist nicht zwingend notwendig für jeden einzelnen Pfad eine Story zu verfassen, lediglich dort, wo es Sinn macht. Nehmen wir als Beispiel eine User Story, die besagt, dass der Nutzer die Möglichkeit haben möchte, seine Einkäufe in einem Online-Shop zu bezahlen. Hierbei gibt es nun zwei denkbare Pfade: zum einen die Zahlung mit einer Kreditkarte und zum anderen die Bezahlung mit Paypal. Die Zahlung mit Kreditkarte lässt sich theoretisch weiter unterteilen, hier sollte jedoch abgewogen werden, ob es noch Sinn macht für jeden Kreditkartentyp eine eigene Story zu verfassen. Die übergeordnete Aufgabe, seine Einkäufe bezahlen zu können, lässt sich jedoch wunderbar in die zwei genannten Alternativen unterteilen. Somit werden die neu entstandenen Stories kleiner und auch besser schätzbar.

Interface

Interfaces sind in diesem Zusammenhang z.B. unterschiedliche Geräte oder Gerättypen  – wie Smartphones, die mit iOS oder mit Android betrieben werden. Auch in Hinblick auf diese Unterschiedlichkeit lassen sich User Stories splitten. Bleiben wir bei dem Beispiel des unterschiedlichen Betriebssystems: So gibt es in einem Projekt vielleicht User Stories, die sich ausschließlich auf den Gebrauch von Android-Geräten beziehen oder aber andere Stories, die sich auf Web Browser fokussieren. Um zu vermeiden, dass Stories zu groß und umfassend werden, sollte man sich die Frage stellen, für welche Geräte bzw. Interfaces man entwickeln möchte. Es kann z.B. vorkommen, dass das erste Entwicklungsergebnis sich lediglich auf iOS-Geräte beziehen soll, weil dort die größere Zielgruppe vermutet wird.

Data

Eine weitere Technik, um User Stories zu splitten, bezieht sich darauf, dass sich die initialen Stories lediglich auf einen Teilbereich der relevanten Daten beziehen. Nehmen wir das Beispiel einer Webseite über eine bestimmte Stadt, die Touristen anlocken soll. Wenn es sich z.B. um eine Stadt handelt, die für ihre Museen bekannt ist, dann könnte die erste Story die Darstellung der verschiedenen Museen umfassen. Eine nächste Story könnte verschiedene Touristen-Touren durch die Stadt beinhalten und eine weitere Story sich mit weiteren Outdoor Aktivitäten beschäftigen.

Rules

Geschäftsregeln oder technologische Standards können ein weiterer Splitting-Faktor sein. Nehmen wir das Beispiel eines Online-Kaufs von Kino-Tickets. Oft gibt es Beschränkungen, die z.B. auf geschäftlichen Vorgaben des jeweiligen Kinos beruhen: Pro E-Mail-Adresse können maximal fünf Tickets online gekauft werden.

Denkbar wäre bei so einer Story jedoch, dass das Entwicklungsteam diese Einschränkung zunächst weggelassen hätte und jeder Besucher so viele Tickets hätte kaufen können, wie er will. In einem zweiten Iterationsschritt hätte die Beschränkung dann hinzugefügt werden können. Solch eine inkrementelle Auslieferung führt dazu, dass initiale Stories nicht sofort komplett umgesetzt werden, sondern in mehreren kleineren Schritten ausgeliefert werden. Manchmal macht es Sinn technische Vorgaben oder Business-Regeln zu vernachlässigen, wenn man so schneller zu einem vorzeigbaren Ergebnis kommt, welches den Nutzer bzw. Kunden zufriedenstellt. Die vernachlässigten Stories können dann zu einem späteren Zeitpunkt nachgeholt werden.

Kleine User Stories erleichtern die Umsetzung

User Story Splitting ist nicht immer einfach, viele Einsteiger neigen dazu, ihre Stories sehr umfassend und viel zu groß zu lassen. Doch wenn es in das Refinement mit dem Entwicklungsteam und letztendlich an die Umsetzung der Stories geht, wird schnell klar, dass deutlich kleinere Stories her müssen. Eine Story sollte “estimatable” und “small” sein. Dies erreicht ihr, wenn ihr wisst, wie man eine große Story passend aufteilen kann. Und auch hier gilt genau das gleiche wie für das Schreiben von User Stories: Übung macht den Meister.

Ihr wollt wissen, welche Anforderung sonst noch an eine gute User Story gestellt werden? Das erfahrt Ihr in meinen Blogpost "Was sind (gute) User Stories?".