Wie man User Stories richtig portioniert
Das Slicing von User Stories in kleine, überschaubare Portionen ist essenziell, wenn man einen guten Product Backlog aufrechterhalten will. Was sich in der Theorie logisch, aber als schwierig umsetzbar anhört, ist keine grosse Hexerei. Alles, was man braucht, ist ein wenig Gehirnschmalz und ein paar Techniken, um loszulegen.
Gerade in agilen Frameworks sind User Stories ein beliebtes Mittel, um Software-Anforderungen zu erkennen, umzusetzen und festzuhalten.
Das User Story Slicing – also das Trennen von Funktionen mit hohem Mehrwert von denen mit geringerem Mehrwert – hilft dabei, einzelne Funktionalitäten von Software zu priorisieren und die Umsetzung besser zu planen. Mit diesen Tipps stellen Product Owner sicher, dass das Slicing von User Stories auch wirklich gelingt:
Müde Augen ade: So helfen kurze Codezeilen
HR-Digitalisierung auf den Menschen ausgerichtet
Von Mythen umwoben
Ein Blick hinter die bbv-Kulissen
Die Sprache zeigt, wo getrennt werden kann
Eine sehr grobe, aber wirkungsvolle Methode, um User Stories zu portionieren, ist die Aufsplittung der Sprache. Dazu sollte einfach jedes «und» und «Komma» der Story als Trennzaun gesehen werden, der zwischen den verschiedenen Anforderungen steht. Inhaltlich führt dies zwar nicht unbedingt zu schönen User Stories, dafür geht es schnell und führt zu keinen grossen Diskussionen. Das Schreiben von Stories – als iterativer Prozess – wird durch diese Methode rasch in Gang gesetzt, selbst wenn es einige unbrauchbare «Sackgassen-Stories» gibt.
Die Sprache zeigt aber auch, wenn die User Stories zu komplex werden: Die bewusste Verkettung der Sätze mit «und dann» klingt zwar schnell monoton, verdeutlicht aber auch, dass sehr viel zusammengefasst wird. Wenn man schon früh in der Entwicklung an diesem Punkt landet, könnte das ein Hinweis darauf sein, dass man versucht, ein Feature vorzeitig zu optimieren und Iterationen zu überspringen.
Stakeholder involvieren
Steht das Wort «User» oder «Nutzer» zur Beschreibung eines Akteurs in den User Stories, sollten alle Alarmglocken läuten. Es ist oftmals ein Indiz dafür, dass der Endbenutzer noch nicht klar definiert ist. Eine einigermassen detaillierte Analyse der Stakeholder-Anforderungen ist ein Muss. Stakeholder-Maps oder Steckbriefe der einzelnen Teilnehmer sind gute Werkzeuge für eine solche Analyse.
Werden Stakeholder involviert, kann grundsätzlich davon ausgegangen werden, dass die Stories genau auf diese zugeschnitten sind. Aber Achtung: Oft stimmen die Anwendungsfälle der verschiedenen Stakeholdergruppen nicht perfekt überein. Vielleicht sind Aussehen und das Gefühl des Endprodukts zwar für alle gleich, aber oft wollen verschiedene Gruppen dasselbe erreichen und trotzdem unterschiedliche Ergebnisse erzielen.
«Was ist das Problem?» in den Mittelpunkt stellen
Die Frage «Was wollen die Stakeholder erreichen?», führt in gewissen Fällen leider zu keinem Resultat. Hier hilft es, im Detail zu beschreiben, was das Problem des Akteurs ist und wie er vorgeht, um es zu lösen. Dies ist eine gute Basis, um die User Story richtig zu splitten.
Aufteilung nach dem «Warum?» in kleinen Schritten
Die Antwort auf die Frage «Warum wollen die Beteiligten das Erreichen?» bringt gute Ergebnisse, ist aber oft schwierig. Meistens bedeutet dies, das Ziel der Stakeholder zu ergründen und neu zu definieren.
Besonders bei Funktionalitäten, die in vielen Anwendungen üblich sind, gibt es immer wieder die Tendenz, alles auf einmal und viel zu gross zu planen. Die Aufteilung der beschriebenen Aktion in kleinere Schritte wird den Aufwand merklich reduzieren. Achtung: Oftmals ist es nicht förderlich, die Diskussion bei demjenigen Problem anzusetzen, das die Beteiligten mit dem Produkt zu lösen versuchen.
Absichtlich Fehler einplanen
Der richtige Umgang mit Ausnahmen und Fehlverhalten ist notwendig. Doch um die Stories nicht unverhältnismässig aufzublasen und die Komplexität der Implementierung zu reduzieren, ist die Aufsplittung in Fehler und Stories ratsam.
Erst die Erstellung individueller Stories für den Umgang mit Fehlschlägen zeigt auf, wie viele der Fälle eine tatsächliche Behandlung erfordern. Eine gute Überwachung der Hürden in der Produktion hilft weiter bei der Priorisierung.
Slicing als Training
Glücklicherweise ist das Slicing von User Stories eine Fähigkeit, die man sich recht einfach aneignen kann. Stellen Sie sich ruhig öfters die Frage, ob man die Story auch anders hätte unterteilen können, und versuchen Sie, ein Muster zu erkennen. Wie viel Slicing ist genug? Kleiner ist oftmals besser und die meisten Teams finden in der Regel eine für sie komfortable Storygrösse.
Wenn bei User Stories eine Schätzung gefragt ist, ist es ratsam, zuerst zu schneiden und die Schätzung später abzugeben, um nicht bei Erreichen einer magischen Zahl einfach aufzuhören. Ich habe beobachtet, dass Teams, die gut im Slicen sind, es oft einfacher finden, den Schätzaufwand komplett wegzulassen. Für Teams mit langen Zykluszeiten ist radikales Slicing eines der ersten Dinge, die vor allem optimiert werden müssen.
Der Autor
Dominik Berner
Dominik Berner war Senior Software-Ingenieur bei bbv. Dank seines Know-hows im MedTech-Bereich kennt er die Wachstumsgrenzen von Start-ups und Kleinunternehmen, aber auch die Verhältnisse in Grossfirmen. Als Agilist betrachtet Berner Softwareentwicklung als Teamsport, der eine starke Unternehmenskultur erfordert.
