•  
  •  
  •  
  •  
  •  
Slicing

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.

22.07.2020Text: bbv0 Kommentare
Slicing
  •  
  •  
  •  
  •  

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:

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.

Dieser Artikel erschien bereits in ähnlicher Form und auf Englisch auf dem persönlichen Blog von Dominik Berner.

Der Autor

Dominik Berner

Dominik Berner ist Software-Ingenieur bei bbv. Dank seines Know-hows im MedTech-Bereich kennt er die Wachstumsgrenzen von Startups und Kleinunternehmen, aber auch die Verhältnisse in Grossfirmen. Als Agilist betrachtet Berner Softwareentwicklung als Teamsport, der eine starke Unternehmenskultur erfordert.

Unser Wissen im Abo

Testing und DevOps

TestOps – die Chance für Tester von heute

Agile Software Development
DevOps-Praxis

Wie die Pipelines clean bleiben

Agile Software Development
Flexibilität von Softwarearchitekturen

Softwarearchitektur in der agilen Welt

Agile Software Development

Artikel kommentieren

Die E-Mail-Adresse wird nicht publiziert. Notwendige Felder sind mit einem * versehen.

Attention!

Sorry, so far we got only content in German for this section.

Attention!

Sorry, so far we got only content in German for this section.