Agile Business Analyse: alles rund um User Stories

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 (Grundlage ist die Agile Extension). Nach und nach erläutern wir die dort beschriebenen 7 Prinzipien 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?

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

 

Zweites der sieben Prinzipien: Denke wie ein Kunde

Der Kunde bestimmt den Wert der zu entwickelnden Lösung. Beginnend mit den gröberen Kundenzielen werden diese zu detaillierten Anforderungen verfeinert (Vorgehen vom Groben zum Detail). Agile Vorgehen nutzen dazu Feedbackschleifen bzw. Iterationen, die das Verständnis der Kundenanforderungen kontinuierlich erweitern und detaillieren. Agile Analyse stellt dabei sicher, dass sich die „Stimme des Kunden“ (Voice of the Customer) in der erstellten Lösung widerspiegelt.

Hierzu werden verschiedene Techniken eingesetzt:

  • Eine grundlegende Technik ist die User Story.
  • Story Decomposition 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 Stories werden nicht nur in der hier besprochenen Agile Extension sondern auch im BABOK selbst als Business-Analyse-Technik genannt. (In einem anderen Blog-Artikel wurden User Stories bereits skizziert und ich hatte einen Kommentar ergänzt.)
User Stories 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 Stories 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.

Vorteile, die User Stories 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 Stories: zur Aufwandsschätzung und Planung sind möglicherweise Ergänzungen notwendig (z.B. Datenmodelle, Zustandsdiagramme, Prototypen), große Stories (Epics) sollten erst in kleinere User Stories „zerlegt“ werden (vgl. Story Decomposition).

 

Story Decomposition

Story Decomposition 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:

  • Ausgangspunkt bilden die zu erreichenden Kundenziele.
  • Diese werden in Komponenten („minimally marketable feature sets“ oder MMFs) mit wertvollen Funktionalitäten zerlegt (oft bilden umgesetzte Komponenten/MMFs die Grundlage, ein Release zu veröffentlichen).
  • Die Komponenten werden in User Stories aufgeteilt. Sollte es sich bei der User Story um ein Epic handeln (d.h. zu groß oder nicht ausreichend verstanden, um weiter damit arbeiten zu können bzw. um den entsprechenden Entwicklungsaufwand zu schätzen), wird das Epic in kleinere User Stories zerlegt. Ein Epic sollte z.B. weiter verfeinert werden, wenn es einen ganzen Geschäftsprozess beinhaltet.
  • Die User Stories 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 Decomposition 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 Decomposition ist die Versuchung, sich zu früh in den Details zu verlieren. Agile Vorgehen setzen auf Iterationen; so sollte auch die Story Decomposition iterativ betrieben werden: erst die Unternehmens- oder Systemziele definieren und daraus die Komponenten/MMFs ableiten, in weiteren Iterationen diese durch Epics und User Stories nach und nach verfeinern.

 

Story Elaboration

Die Technik Story Elaboration wird auf der dritten und vierten Stufe der Story Decomposition genutzt, um User Stories zu detaillieren und durch Akzeptanzkriterien zu ergänzen; idealerweise just-in-time und just-enough. 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 Stories in einer grafischen Übersicht dar. Horizontal wird die Sequenz der User Aktivitäten dargestellt; von mir gerne als Big Story beschrieben (Beispiel aus unserem Business-Analyse-Seminar, vgl. Grafik: am System anmelden, Daten eingeben, Eingabe speichern, Auswertung drucken). Vertikal werden die Details aufgeführt; von mir gerne unterteilt in Small Stories und diese zerlegt in User Stories (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 Stories 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).

 

9 Kommentare

  1. Hallo Axel,

    zum letzten Punkt „Story Mapping“ gibt ein interessantes Tool das dem Product Owner die Arbeit stark erleichtert. Agile StoryMap ist ein JIRA plug in, das sich recht gut in den Development Livecycle integrieren lässt, da es eine Verknüpfung zu den Tasks, also den konkreten Arbeitspaketen mitbringt. Zu finden auf dem Atlassian Marketplace: bauer-information-technology.com

    Gruß,
    Florian

    1. Guten Tag Florian,

      normalerweise arbeite ich mit Pinnwand und Karten. Das klingt vielleicht erst mal „old-fashioned“. Allerdings bietet mir dies Flexibilität; ist quasi überall einsetzbar und ohne Schulung zu erlernen 😉
      Ein Tool eröffnet natürlich andere Möglichkeiten und hat vollkommen seine Berechtigung.

      Viele Grüße
      Axel Naumann

  2. It’s nearly impossible to find knowledgeable people on this subject, however,
    you sound like you know what you’re talking about! Thanks

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.