Gute User-Storys schreiben – alles rund um User-Storys

„Denke wie ein Kunde„

Um gute User-Storys zu schreiben, ist das wahrscheinlich die wichtigste Aussage: „Denke wie ein Kunde“. Denn der Kunde (Stakeholder) bestimmt den Wert einer zu entwickelnden Lösung. Beginnend mit den gröberen Kundenzielen werden diese zu detaillierten Anforderungen in Form von User-Storys verfeinert; es wird also vom Groben zum Detail vorgegangen. Agile Vorgehen (wie z. B. Scrum) nutzen dazu Feedbackschleifen bzw. Iterationen, die das Verständnis der Kundenanforderungen kontinuierlich erweitern und detaillieren. Agile Business-Analyse stellt dabei sicher, dass sich die „Stimme des Kunden“ (Voice of the Customer) in der erstellten Lösung widerspiegelt.

Dein Werkzeugkoffer

Hierzu werden verschiedene Techniken eingesetzt, die wir uns im Folgenden anschauen:

• Eine grundlegende Technik ist die User-Story, hoffentlich gut geschrieben.
• Story-Dekomposition stellt den roten Faden von den Kunden-/Projektzielen zu den User Stories sicher.
• Story Elaboration detailliert User Stories und ergänzt sie durch Akzeptanzkriterien.
• Story Mapping stellt User Stories in einer grafischen Übersicht dar.

User-Story

User-Storys beschreiben Bedürfnisse der Kunden/Stakeholder und sind dabei kurz genug, um z.B. auf eine DIN-A6-Karteikarte oder einen Klebezettel zu passen. Häufig wird folgende Struktur genutzt:

• WER: Rolle oder Persona
• WAS: eine Aktion, Verhalten oder Funktionalität
• WARUM: Nutzen oder Business Value, der entsteht, wenn die User-Story umgesetzt wurde.

Beispiel: Als User (WER) will ich das Dokument speichern können (WAS), damit meine Eingaben und Änderungen am Dokument nicht verloren gehen (WARUM).

Da User-Storys nicht den Anspruch auf vollständige Beschreibung jedes Details erheben, ist Kommunikation und Konversation wichtig (siehe Story Elaboration weiter unten). Dadurch soll sichergestellt werden, dass die beschriebene Funktionalität besser verstanden und verfeinert wird. Und erst dadurch wird eine User-Story richtig gut.

Vorteile, die User-Storys bieten:

• für die Stakeholder einfach zu verstehen,
• innerhalb kurzer Zeit zu erlernen,
• durch verschiedene Erhebungstechniken zu ermitteln (z.B. Workshops, Interviews),
• Grundlage für weitere Dekomposition und Verfeinerung (insbesondere durch Story Elaboration).

Nachteile der User-Storys:

• zur Aufwandsschätzung und Planung sind möglicherweise Ergänzungen notwendig (z.B. Datenmodelle, Zustandsdiagramme, Prototypen),
• große Storys (Epics) sollten erst in kleinere User-Storys „zerlegt“ werden (vgl. Story-Dekomposition).

Story-Dekomposition

Story-Dekomposition stellt sicher, dass die Anforderungen in einem adäquaten Detaillierungsgrad beschrieben werden, und dass die Anforderungen sich aus den Zielen ableiten. Dabei wird von der Breite in die Tiefe vorgegangen, um die Anforderungen nach und nach zu verfeinern (eine feinere Granularität zu erreichen); typischerweise werden vier Stufen beschritten:

1. Ausgangspunkt bilden die zu erreichenden Kundenziele.
2. Diese werden in Komponenten bzw. Features mit wertvollen Funktionalitäten zerlegt (oft bilden umgesetzte Komponenten/Features die Grundlage, ein Release zu veröffentlichen).
3. Die Komponenten werden in User-Storys aufgeteilt: Sollte die ursprüngliche User-Story zu groß oder nicht ausreichend verstanden sein, um weiter damit arbeiten zu können (oder um den entsprechenden Entwicklungsaufwand zu schätzen), handelt es sich wahrscheinlich um ein Epic. Dieses sollte in kleinere User-Storys zerlegt werden. Beinhaltet beispielsweise ein Epic einen ganzen Geschäftsprozess, sollte es in mehrere User-Storys verfeinert werden.
4. Die User-Storys werden um Akzeptanzkriterien ergänzt, d.h. unter welchen Bedingungen ist die User-Story richtig umgesetzt. Akzeptanzkriterien dienen zum einen dem besseren Verständnis, welcher Wert durch die Umsetzung der User-Story geschaffen wird, zum anderen helfen sie die umgesetzte Funktionalität zu testen (vgl. unten Story Elaboration).

Vorteile der Story-Dekomposition sind:

• sich nicht in den Details der User Stories zu „verlaufen“ und dabei den Überblick zu verlieren („den Wald vor lauter Bäumen nicht mehr sehen“),
• gewünschte oder umgesetzte Funktionalitäten lassen sich auf die gegebenen Ziele zurückführen (Traceability).

Nachteil der Story-Dekomposition ist die Versuchung, sich zu früh in den Details zu verlieren. Agile Vorgehen setzen auf Iterationen; so sollte auch die Story-Dekomposition iterativ betrieben werden: erst die Unternehmens- oder Systemziele definieren und daraus die Komponenten/MMFs ableiten, in weiteren Iterationen diese durch Epics und User-Storys nach und nach verfeinern.

Story Elaboration

Die Technik Story Elaboration wird auf der dritten und vierten Stufe der Story-Dekomposition genutzt, um User-Storys zu detaillieren, durch Akzeptanzkriterien zu ergänzen und sie damit gut zu formulieren. Als Ergebnisse sollen ein gemeinsames Verständnis der Inhalte der User-Story entstehen (wann kann die User-Story als fertig umgesetzt angesehen werden). Dazu werden z.B.

• detaillierte Anforderungen für die jeweilige User-Story erarbeitet,
• Beispiele und Szenarien entworfen (bei denen die Kundensicht eingenommen wird),
• ergänzende Informationen modelliert (beispielsweise durch ein Datenflussmodell),
• Akzeptanzkriterien für das Testen beschrieben; von mir gerne im Format Triple A mit Anfang, Aktion, Ausgang formuliert: aus welcher Anfangssituation wird durch welche Aktion (umgesetzte Anforderung) welcher Ausgang (Ergebnis) erzielt.

Weil hier Kommunikation und Konversation wichtig sind, kommen Personen mit Business-Analyse-Skills zum Einsatz. Der Business-Analyst nutzt zur Story Elaboration z.B. einen Workshop mit den Programmierern, dem Vertreter des Kunden/Fachbereichs (der den Nutzen aus der User-Story erhält) und den Testern, um o.g. Ergebnisse zu erreichen.

Vorteil der Story Elaboration ist, dass unnötige Anforderungsermittlung (und möglicherweise Dokumentation) vermieden wird. Dies wird dadurch erreicht, dass nur aktuelle Anforderungen näher betrachtet werden, die vor der Umsetzung stehen; und nicht solche Anforderungen, die erst später umgesetzt werden sollen (und sich bis dahin möglicherweise ändern oder ganz entfallen).

Nachteile der Story Elaboration: Das just-in-time und just-enough sind schwierig zu finden (eine zu frühe Story Elaboration liefert gegebenenfalls Informationen, die veralten; eine zu späte Story Elaboration kann zu Verzögerungen führen). Außerdem kann es schwierig sein, den richtigen Detaillierungsgrad der Anforderungen für die Umsetzung und das Testen zu finden.

Story Mapping

Eine Story Map stellt User-Storys in einer grafischen Übersicht dar. Horizontal wird die Sequenz der User-Aktivitäten dargestellt, sogenannte Features oder Big-Storys (Beispiel aus unserem Business-Analyse-Seminar, vgl. Grafik: am System anmelden, Daten eingeben, Eingabe speichern, Auswertung drucken). Vertikal werden die Details aufgeführt; unterteilt in Epics (oder Small-Storys) und diese zerlegt in User-Storys (z.B. Login, zerlegt in Login Neukunde, Login Altkunde und Password lost).

Sinnvollerweise startet man mit der Horizontalen (d.h. von der Breite), und detailliert erst dann in die Vertikale (d.h. in die Tiefe).

Vorteil der Technik Story Mapping ist, den Überblick über die User-Storys zu behalten und diese im Kontext betrachten zu können.

Während Story Maps eine Sequenz (in der Horizontalen) aufzeigen, stellen sie nicht unbedingt die Abhängigkeiten zwischen den Anforderungen dar. Ein weiterer Nachteil des Story Mappings: bei sehr großen Produkten/Projekten werden mehrere Story Maps benötigt; dadurch leidet die Übersichtlichkeit.

Im nächsten Blog-Artikel der Reihe wenden wir uns dem dritten der sieben Prinzipien zu: Bestimme das Wertvolle (entwickle dadurch eine Lösung, die wertvoll und positiv bewertet ist).

EDIT

Näher und aktueller beantworten wir die Frage(n) in unseren Business Analyse Weiterbildungen, insbesondere im Modul zur agilen Business-Analyse.
Mehr zum Nachlesen findet sich hier im Blog, im Business-Analyst-Blog und im Fachbuch „Business-Analyse – Systematisches Anforderungsmanagement für nutzerorientierte Lösungen“.

In mehreren Blog-Artikeln betrachten wir, wo und wie Business Analysten in agilen Vorgehensmodellen (z.B. Scrum) zum Einsatz kommen, welche Aufgaben und Aktivitäten sie dabei ausüben. Den Auftakt machte eine Übersicht zum Thema. Nach und nach schauen wir uns die 7 Prinzipien an für erfolgreiche agile Business Analyse:

Drei Prinzipien beschreiben das Was? und Warum?

1. Sieh auf das Ganze (auf Personen, Prozessen und Technologie); mit den Techniken Personas und Value Stream Mapping (Wertstromanalyse).
2. In diesem Blog-Artikel: Denke wie ein Kunde (und höre auf die Stimme des Kunden mit seinen Werten und Erwartungen).
3. Bestimme das Wertvolle (entwickle dadurch eine Lösung, die wertvoll und positiv bewertet ist); mit den Techniken Management des Backlogs, Kano-Analyse, Priorisierung mit MoSCoW.

Vier Prinzipien für das Wie? und Wann?

4. Nutze reale Beispiele (um echte Kundenbedürfnisse zu ermitteln und zu validieren); mit der Technik Behaviour Driven Development.
5. Verstehe, was machbar ist (und unterstütze dadurch die Entwickler in ihrer Umsetzung der Anforderungen); mit den Techniken Schätzung und Planungsworkshop.
6. Fördere Zusammenarbeit und kontinuierliche Verbesserung; mit den Techniken Collaborative Games und Retrospektive.
7. Vermeide Verschwendung (und erkenne diese rechtzeitig).

Du möchtest keine Blogartikel rund um das Thema Business-Analyse verpassen? Dann abonniere unseren ibo-Newsletter!