How to split a User Story

Bild: Wikimedia Commons/Evan Amos - CC0 1.0

Das Kleinschneiden von Anforderungen in User Stories die innerhalb eines Sprints umgesetzt werden können kann sehr erklärbedürftig sein. Selbst erfahrene Product Owner kommen immer wieder an eine Stelle an der sie Schwierigkeiten bekommen. Für die von mir gecoachten POs habe ich irgendwann begonnen eine Übersicht zu erstellen nach welchen Kriterien man das Messer ansetzen kann. Sie ist sicher noch nicht vollständig, hat aber einigen Teams weiterhelfen können.

Nach MVP-Kriterien
Vor allem dort sinnvoll wo schnelle vorzeigbare Ergebnisse nötig sind. Die Story sollte die kleinstmögliche nutzbare Funktionalität ergeben, selbst wenn sie noch "aufgehübscht" werden muss. Das passiert dann in späteren Stories.

Nach Arbeitsschritten
Der Klassiker. Ich möchte mich einloggen. Ich möchte eine personalisierte Willkommensseite sehen. Ich möchte eine neue Seite anlegen, etc. Jeder Schritt kann eine eigene User Story sein.

Nach Happy-/Unhappy Path
Darauf kommen erstaunlich wenige. Happy Path: Ich möchte mein Geburtsdatum eingeben können. Unhappy Path: Ich möchte eine Fehlermeldung angezeigt bekommen wenn ich in dieses Feld Buchstaben eingebe. Das kann man sehr gut separat umsetzen.

Nach GUI-Elementen
Im oberen Seitendrittel möchte ich meinen Benutzernamen und mein Profilbild sehen. Im mittleren Seitendrittel möchte ich Statusmeldungen eingeben und sehen können. Im unteren Seitendrittel möchte ich eine Liste meiner älteren Statusmeldungen sehen.

Nach Benutzer-Rollen
Zu Beginn gibt es bei diesem Vorgehen nur eine Rolle: den Administrator, der alles sehen und machen kann. Mit den weiteren Rollen werden nach und nach Beschränkungen eingeführt: Redakteur, Auditor, Gast, etc.

Nach Datei-/Daten-Typen
Macht z.B. Sinn wenn verschiedene Dateitypen importierbar und lesbar sein müssen: Erst CSV, dann XLSX, dann Word, dann PDF, dann PPT.

Nach Datenquellen/Schnittstellen
Wenn verschiedene andere Systeme angeschlossen werden müssen, z.B. die der Fabrik, der Marketing-Abteilung, der Tochtergesellschaft und des Lieferanten.

Nach Performance-Bedürfnissen
Schon etwas technischer. Zu Beginn kann man etwa eine Abfrage über die gesamte (noch kleine) Datenbank laufen lassen, später mit Verschlagwortung oder mehr Rechenleistung die Verarbeitung größerer Datenmengen sicherstellen.

Nach "Low hanging Fruits"
Wenn Teile der Anforderungen komplex oder unklar sind kann man sich auf die anderen konzentrieren. Dadurch gewinnt man die Zeit um die schwierigeren Bereiche zu analysieren und zu verstehen (siehe unten: Spike).

Nach Testszenarien
Auch hierauf kommt nicht jeder. Wenn Anforderungen einen hohen Testaufwand mit sich bringen kann man auch den reduzieren indem man kleinere Stories schneidet. Möglichkeiten wären etwa der Login-Status oder Datumskonstellationen.

Nach Endgeräten
Ich erinnere mich an ein Projekt in dem die Anwendung immer zuerst für das iPad des Projektleiters optimiert wurde. Je nach Gerät/Betriebssystem (Apple, Android, Windows, Kindle, Tolino) können andere Anpassungen nötig sein.

Nach Browsern
Ähnlich wie der letzte Ansatz. Eine klassische Reihenfolge wäre Safari, Chrome, Firefox, Edge, IE10, IE9, IE8, IE7. Masochisten können auch bis auf den IE6 runtergehen.

Der Sonderfall: Spike
Eine Forschungsaufgabe um schlecht geschriebene und/oder dokumentierte Software zu verstehen. Sollte nur sparsam und timeboxed eingesetzt werden, da es sonst schnell ausufern kann.

Wie oben gesagt: es gibt bestimmt noch viele weitere Möglichkeiten. Ein Großteil dürfte aber durch diese Liste abgedeckt sein.