5 Fehler beim Splitten von User Stories und wie man sie vermeidet

Bevor man eine Iteration startet, müssen die dafür ausgewählten User Stories klein genug sein, um innerhalb dieser Iteration fertiggestellt werden zu können. Aus diesem Grund ist das Aufsplitten von User Stories eine wichtige Fähigkeit von agilen Teams.

Dennoch haben wir alle schon unsere Schwierigkeiten beim Aufsplitten von User Stories gehabt. Viele dieser Schwierigkeiten entstehen durch eine Reihe ganz typischer Fehler. In diesem Artikel erfahren Sie, was die fünf häufigsten Fehler beim Herunterbrechen von User Stories sind und wie man sie vermeiden kann.

Fehler #1: Story Splitting ist die Aufgabe des Product Owners

Ganz oben in der Liste der Probleme beim Herunterbrechen von User Stories ist, dass das Splitten von Stories für die Aufgabe des Product Owners gehalten wird. Wenn ein Product Owner die User Stories ganz alleine aufsplittet, ist es recht wahrscheinlich, dass die neu entstandenen „Sub Stories” nicht besonders sinnvoll aufgeteilt wurden.

Da die meisten Product Owner kaum oder gar keinen technischen Hintergrund haben, teilen sie eine User Story häufig beispielsweise in fünf kleinere Stories auf, von denen eine Story 99% der Arbeit enthält. Eine Story auf diese Weise aufzusplitten ist nicht hilfreich. Ebenso wird ein Product Owner ohne technisches Wissen vielleicht Stories mit Abhängigkeiten schaffen, die das Team daran hindern, sie in einer Iteration fertigzustellen.

Auch wenn das Aufsplitten von Stories nicht als die alleinige Aufgabe des Product Owners angesehen werden sollte, sollte der P.O. aber natürlich auf jeden Fall daran beteiligt sein. Die Verantwortung sollte nicht alleine beim Entwicklungsteam liegen. Um Stories optimal teilen zu können, muss der Product Owner daran beteiligt sein.

Das Story Splitting ist also eine Aufgabe des gesamten Teams. Das bedeutet jedoch nicht, dass jedes Mal das gesamte Team beteiligt sein sollte. Es bedeutet lediglich, dass nicht ein oder zwei Personen aus dem Team jedes Mal dafür verantwortlich sein sollen.

Stattdessen helfen vielleicht zwei Teammitglieder dem Product Owner, ein oder zwei Stories aufzuteilen. Später können dann andere Teammitglieder dem Product Owner bei einer anderen Story helfen.

Meine Empfehlung wäre, dass man das Story Splitting im Daily Scrum bespricht. Der Product Owner erzählt dann zum Beispiel, dass in den nächsten Tagen drei User Stories für den nächsten Sprint heruntergebrochen werden müssen. Einige der Entwickler haben dann vielleicht Zeit, zu helfen, und man kann direkt im Daily Scrum eine Zeit ausmachen, um die Stories zu besprechen.

Fehler #2: Stories anhand technischer Pfade aufteilen

Auch wenn ich den Teams immer sage, dass das Entwicklungsteam beim Aufteilen von User Stories einbezogen werden sollte, kann dies zu einem weiteren Problem führen: Das Aufteilen von User Stories anhand technischer statt funktionaler Fragen.

Sicherlich haben Sie dieses Problem schon selbst kennengelernt. Häufig werden diese Stories folgendermaßen geschrieben:

„Als Programmierer möchte ich…”

Sie beschreiben die Funktionalität dann eher aus der Sicht des Teams statt aus der Sicht des Endnutzers oder der Stakeholder.

Das kann beispielsweise zu folgenden Stories führen:

• Als Nutzer will ich ein Back-End, dass dies und jenes kann.
• Als Nutzer will ich ein Front-End, dass auch dies und jenes kann.
  Eine gute Story sollte die gesamte Technologie umfassen oder zumindest soviel, wie es nötig ist, um ein Feature zu liefern. Stories entlang von technischen Grenzen zu splitten, erzeugt Stories, die dem Nutzer einzeln keinen wirklichen Wert liefern können. Ein Front-End (z.B. ein Interface einer Webseite) bringt dem Nutzer nichts ohne ein entsprechendes Back-End (Mittel-Ebene und/oder Datenbank).

Um diese Falle zu vermeiden, sollten Sie versuchen, die Aufteilung entlang eines Pfades durch die Story vorzunehmen.

Um das zu tun, sollte man sich überlegen, welche Pfade es im Code des Entwicklungsteams gibt. Häufig gibt es einen Pfad, der definiert, was passiert, wenn alles gut geht. Normalerweise gibt es auch einem Pfad für jeden Fehler, der auftreten kann.

Man kann sich auch überlegen, welche Pfade der Nutzer in der zu teilenden Story durchläuft. Nehmen wir als Beispiel-Story den Bezahlvorgang in einem Online-Einkaufskorb, denn das betrifft jede E-Commerce-Seite. Beim Auschecken kann der Käufer eine Versandart wählen, etwa zwischen der Lieferung am nächsten Tag, innerhalb der nächsten 2 Tage oder einer langsameren Versandart.

Da die Auswahl der Versandart den Aufwand für die Story erhöht, sollte man überlegen, diese Funktionalität nicht in die initiale Version einzubinden. In dieser ersten Version würde dann jeder den langsameren Versand bekommen, ohne die Option auf schnellere Zustellung. Nur diesen einen Pfad zu entwickeln, vereinfacht das User Interface (der Nutzer muss nicht mehrere Versand-Optionen zur Auswahl haben). Außerdem reduziert es die Anzahl der Testfälle usw. Entlang eines Pfades eine Aufteilung vorzunehmen, wäre in einem solchen Fall eine gute Option.

Fehler #3: In der Story die Lösung formulieren

Ein weiterer häufiger Fehler ist, die Lösung schon in der Story zu formulieren. Die besten User Stories konzentrieren sich eher darauf, was getan werden soll, und nicht, wie es getan werden soll.

Ich möchte beispielsweise gerade ein Bild in meinem Büro aufhängen. Wenn ich nun jemanden bitten würde, das für mich zu erledigen, könnte ich demjenigen sagen, wie ich es erledigt haben möchte. Ich könnte erklären, dass ich das Bild mit einer ⅜” Flachrundschraube befestigt haben möchte. Wenn ich das tue, habe ich sehr klar festgelegt, wie die Aufgabe erledigt werden soll. Wenn mir die Details also nicht aus irgendeinem Grund besonders wichtig sind, sage ich besser nur, was getan werden soll: „Ich möchte, dass das Bild ungefähr an dieser Stelle an der Wand sicher aufgehängt wird.”

Die Lösung in die Story einzubinden geschieht häufig, wenn die Stories in zu kleine Teile aufgeteilt werden. Je kleiner die Stories werden, umso weniger gibt es dazu zu sagen und es schleichen sich solche Implementierungsdetails ein.

Nehmen wir an, wir würden einen Geldautomaten bauen, der Geld ausgeben soll. Das ist ein typisches Beispiel aus Büchern über Softwareanforderungen. Dieses Beispiel soll klar machen, dass man nicht grundsätzlich davon ausgehen sollte, dass der neue Geldautomat automatisch eine Karte und einen PIN-Code zur Authentifikation benötigt, nur weil das schon immer so war. Vielleicht wollen wir nämlich in diesem Fall einen Iris-Scanner verwenden.

Es ist sinnvoll mit einer einfacheren Story anzufangen wie „Der Nutzer authentifiziert sich”, bei der das „Wie” nicht näher spezifiziert wird. Wenn natürlich diese Story immer weiter heruntergebrochen wird, wird an irgendeinem Punkt jemand sagen müssen, ob ein Iris-Scanner oder ein klassisches Kartenlesegerät mit PIN-Eingabe genutzt werden soll. Sollten Sie also feststellen, dass Ihr Team viele Spezifizierungen über das „Wie” in einer Story hat, prüfen Sie, ob die Stories kleiner sind, als sie sein sollten.

Fehler #4: Ein Spike für jede Story

Das Ziel eines Spikes ist eher neues Wissen als neue Funktionalität. Spikes werden häufig genutzt, um Risiko und Ungewissheit in einer Story zu reduzieren. Wenn die Teammitglieder eine neue Technologie noch nicht kennen oder sich damit unsicher sind, können sie mit einem Spike mehr darüber in Erfahrung bringen.  

Einen Spike aus einer Story herauszubrechen, kann ein guter Ansatz sein. Man reduziert so die Ungewissheit der initialen Story, weshalb sie mit großer Wahrscheinlichkeit auch schneller umzusetzen sein wird. Ein Spike kann dem Product Owner und dem Team aber auch dabei helfen, herauszufinden, wie man eine Story besser aufteilen kann, wenn sie nach dem Spike immer noch zu groß ist. Spikes aus Stories herauszulösen, ist in manchen Fällen eine gute Idee. Die Teams müssen nur aufpassen, sich nicht zu sehr von Spikes abhängig zu machen und nicht bei jeder Story einen Spike zu haben. Das wäre nämlich keine gute Idee.

So sind Spikes am hilfreichsten:

Spikes sind am hilfreichsten, wenn es ein hohes Maß an Ungewissheit in einer Story gibt und sich Product Owner und Team einig sind, dass diese Ungewissheit vor dem Implementieren der Story behoben werden sollte. Verfügt eine Story über ein normales und alltägliches Maß an Ungewissheit, sollte es keinen Spike geben.

Ein gewisses Maß an Ungewissheit gibt es in jeder Story. Werden die Nutzer es mögen, wenn das auf diese Weise gemacht wird? Wird das Design gut funktionieren? Wird das neue Tool so gut funktionieren, wie es uns versprochen wurde? Derartige Fragen kommen in jeder Story auf. Das Ziel ist nicht, die Ungewissheit vollständig zu eliminieren. In fast allen Fällen ist das ohnehin ein Ding der Unmöglichkeit.

Spikes sollten nur dann verwendet werden, wenn die User Story über ein so hohes Maß an Ungewissheit verfügt, dass es nicht ratsam wäre, ohne das Wissen aus dem Spike mit der Story anzufangen.

Teams, die zu häufig Spikes aus den Stories herausarbeiten, haben meist Angst davor, eine falsche Einschätzung abzugeben. Häufig haben die Teams dann die Befürchtung, dass sie bestraft oder zumindest kritisiert werden, wenn sie für eine Story länger brauchen, als sie zuvor geschätzt hatten. Oft geschieht das in Kulturen, in denen man Einschätzungen mit Commitments verwechselt. Um das zu beheben, sollte man entweder bewusst den Einschätzungen weniger Wert beimessen oder daran arbeiten, ein größeres Sicherheitsgefühl zu erzeugen, sodass die Teams keine Angst davor haben müssen, dass die Einschätzungen gegen sie verwendet werden können.

Fehler #5: Alle Regeln müssen von Anfang an umgesetzt werden

Manchmal sind User Stories schwer umzusetzen, weil so viele Regeln beachtet werden müssen. Diese Regeln werden oft Geschäftsregeln genannt, weil sie normalerweise aus dem operativen Geschäft entstanden sind. Manchmal werden sie aber auch durch das System vorgegeben.

Hier ein Beispiel zur Veranschaulichung:

Nehmen wir an, dass Sie in dem Entwicklungsteam einer Bank arbeiten, die Hypothekenkredite vergibt. Ihr Team entwickelt eine App, die die Kunden nutzen können, um eine Hypothek zu beantragen. Vielleicht gibt es in Ihrer Bank die Regel, dass niemand mehr als 10 Millionen Dollar an ausstehenden Krediten haben darf. Diese Regel gilt, egal ob jemand eine große Hypothek aufnehmen möchte oder zusätzlich zu einem 5 Millionen Dollar Kredit noch einen zweiten Kredit in Höhe von 6 Millionen Dollar aufnehmen möchte.

Die App wird diese Regel hoffentlich verwenden, sodass niemand einen Kredit beantragen kann, der insgesamt das zulässige Maximum überschreitet (unabhängig davon, ob dies der erste, zweite oder dritte Kredit dieser Person ist).

Eine solche Regel erhöht den Aufwand für das Fertigstellen der User Story, da die App die bereits existierenden Kredite abfragen, diesen Betrag zu der neu angefragte Kreditsumme hinzuaddieren und schließlich prüfen muss, ob dieser Betrag nicht mehr als 10 Millionen Dollar beträgt.

Wenn diese Regel die Story so groß macht, dass es unwahrscheinlich ist, dass sie innerhalb einer Iteration fertiggestellt werden kann, sollte diese Regel in der ersten Iteration gelockert (oder weggelassen) und in der nächsten Iteration wieder aufgegriffen werden. Und natürlich sollte ein Team kein Produkt releasen, das die Geschäftsregeln verletzt.

Einige Teams machen den Fehler, zu glauben, dass alle Geschäftsregeln von Anfang an umgesetzt werden müssen. Das kann dazu führen, dass Product Owner und Team die User Story auf ungünstige Weise aufsplitten. Wenn Sie das nächste Mal eine Story aufsplitten wollen, suchen Sie Möglichkeiten, die Story nur teilweise zu implementieren, indem Sie anfänglich eine Regel auslassen. Solange Sie nicht vorhaben, das Resultat dieses Sprints offiziell zu releasen, kann das Weglassen einer Regel eine gute Möglichkeit sein, eine Story aufzuteilen.

Fazit: Vermeidung bei Fehlern im User Story Splitting

Die meisten Teams sagen, das Aufteilen von User Stories sei eine ihrer größten Herausforderungen. In diesem Artikel habe ich die fünf häufigsten Fehler von Teams beschrieben und Lösungsvorschläge dafür genannt. Am besten können Sie diese Fehler vermeiden, wenn Sie mehr Übung im Aufteilen von Stories bekommen.

Die Top-3-Methoden, mit denen man so gut wie jede Story splitten kann, habe ich in diesem Artikel erläutert:

• Pfade
• Regeln
• Spikes

Werde ein zertifizierter ScrumMaster oder Certified Product Owner und schau bei unseren agilen Trainings vorbei. Wir bieten auch eine Vielzahl an kostenlosen Informationsveranstaltungen, Deep Dives und Einsteigerkursen!