Ein Produkt in kurzen Zeitintervallen Schritt für Schritt zu entwickeln, hat zwei entscheidende Vorteile: Aktuelle Aufgaben lassen sich besser managen und Anpassungen können leichter umgesetzt werden. Soweit, so agile. Allerdings besteht die Gefahr, als Team das „Big Picture“ aus dem Auge zu verlieren. Um das zu verhindern, hilft User Story Mapping. Damit bleibt nicht nur das übergeordnete Ziel klar, die Visualisierung schafft auch schon zum Projektstart ein gemeinsames Verständnis für die finale Produktidee.
Was ist User Story Mapping?
User Story Mapping ist eine Visualisierungsmethode, die oft in der Softwareentwicklung eingesetzt wird. Mithilfe dieser „Landkarte“ lassen sich Zusammenhänge darstellen, die beim Arbeiten mit eindimensionalen Backlogs leicht übersehen werden.
Das Mapping dient dabei der zeitlichen und inhaltlichen Planung, Pflege und Priorisierung von Produktfeatures und User Storys – also Nutzergeschichten, die die Anforderungen an einzelne Produktfunktionen aus der Nutzersicht beschreiben: Wie wünschen sich Anwender eine Software oder Kunden einen Liefergegenstand? Entwickler und Tester zerlegen dann eine Story in viele einzelne Aufgaben.
Warum User Story Mapping so hilfreich ist?
User Story Mapping hilft dabei, das Projektziel im Auge zu behalten, herauszufinden, was zuerst entwickelt werden sollte, zu priorisieren, iteratives Vorgehen zu fördern und den Projektfortschritt zu visualisieren.
In verschiedenen Situationen kann diese Darstellungsform zum Einsatz kommen: bei einem strukturierten Vorgespräch zur Auftragsklärung, bei der Einarbeitung von neuem Personal hinsichtlich Kunden und Produkte – aber vor allem zu Beginn eines Sprint Plannings, um einen gemeinsamen Blick auf den aktuellen Stand des Projektes zu werfen. Mit steigender Anzahl von Einträgen werden Backlogs nämlich schnell unübersichtlich und hier kann User Story Mapping helfen,ein bestehendes Backlog zu strukturieren und zu priorisieren.
Arten und Aufbau einer User Story Map
Je nach Anwendungsfall sieht eine Map ganz unterschiedlich aus. Aber alle Arten von Maps haben einen ähnlichen Grundaufbau: Im Gegensatz zu einem flachen Product Backlog bietet eine User Story Map eine zweidimensionale Karte. Ob Items von oben nach unten, oder von links nach rechts angeordnet werden, ist für die Anwendung unwesentlich. Wichtig ist, dass Abstraktionsebenen gefunden werden, mit denen die Beteiligten Anforderungen besser identifizieren und vorhandene Zusammenhänge leichter verstehen können.
Eine User Story Map besteht meistens aus den folgenden Elementen:
- Aktivitäten: Eine Beschreibung der wichtigsten Aktivitäten des Nutzers in Form von Epics – gemeint sind die Anforderung an eine neue Software oder einem Produkt auf einer hohen Abstraktionsebene.
- Backbone: Hier beschreibt jede Karte einzelne Aktivitäten des Nutzers in chronologischer Reihenfolge. Wichtig ist, dass das „Backbone“ nur einen groben Überblick gibt, indem es eine Möglichkeit beschreibt, wie ein bestimmter Anwender handeln würde. Einfachheit ist dabei Trumpf.
- Body: Der untere Teil enthält die User Stories, also Tätigkeiten, die dem Nutzer dabei helfen sollen, das Ziel zu erreichen. Die Karten entsprechen also einer detaillierten Form der Aktivitäten aus dem Backbone.
Sobald alle wichtigen User Stories identifiziert wurden, werden die daraus resultierenden Anforderungen priorisiert und auf mehrere Releases verteilt. Das Team definiert die absoluten Basisanforderungen an das Produkt, damit es sich nutzen lässt – das Minimum Viable Product (MVP).Je höher eine User Story angeordnet wird, desto wichtiger ist sie.
In späteren Releases werden nach und nach Funktionalitäten ergänzt, die den Umgang komfortabler gestalten. Im Idealfall ergeben sich aus dem frühzeitigen Einsatz des Produkts nämlich im Idealfall schon Erkenntnisse, die die vorab geplanten Anforderungen überflüssig machen. Damit können Entwicklungsteams wertvolle Zeit sparen, die Wartungsaufwände niedrig halten und die Nutzerzufriedenheit steigern.
Klingt alles noch etwas abstrakt? Dann schauen wir uns mal an einem konkreten Beispiel an, wie eine User Story Map aussehen könnte. Unser „Produkt“ hat einen ziemlich alltagstauglichen Bezug und zwei zentrale Aktivitäten: Start in den Tag & Fertig für die Arbeit.
Im Backbone stehen alle wichtigen Stationen in chronologischer Reihenfolge – aufstehen, fertigmachen, frühstücken, losgehen. In unserem Beispiel umfassen die User Stories im Body zum Beispiel Wecker ausstellen, Duschen, Zähneputzen, Anziehen, Kaffee/Tee kochen, Tisch decken, Müsli zubereiten. User Stories konkretisieren also die User Journey noch einmal.
Jetzt wollen wir unser MVP definieren und dabei kann uns folgende Fragestellung helfen: „Ich habe verschlafen und nur noch zehn Minuten Zeit. Was sind die wichtigsten Aktivitäten, die ich erledigen muss, bevor ich aus dem Haus gehe?“
Die im MVP aufgelisteten User Stories ermöglichen die reibungslose Zielerreichung „Start in den Tag& fertig für die Arbeit“. Diese Phase ist außerdem wichtig, um alternative Aufgaben zu identifizieren, die mit weniger Aufwand trotzdem zum Ziel führen – zum Beispiel Kaugummi kauen statt Zähneputzen.
Was die Vorteile & Nachteile von User Story Mapping sind...
Die Vorteile dieser Visualisierungsmethode in der Übersicht:
- Übersichtliche Darstellung des Big Picture: Der Gesamtzusammenhang des Backlogs wird erkennbar.
- Das Projektteam bekommt ein gemeinsames Verständnis von der grundlegenden
Produktidee und der weiteren Planung. - Entscheidungen können besser getroffen und Priorisierungen vorgenommen werden
- Funktionsbereiche lassen sich leichter diskutieren und managen
- Erlaubt die Visualisierung von dimensionaler Planung sowie von den Möglichkeiten des Projekts oder Produkts
- Teams laufen nicht Gefahr, wichtige Anforderungen über eine lange Projektlaufzeit zu vergessen.
- Gutes Instrument, um miteinander ins Gespräch zu kommen.
- Schnellere Integration neuer Mitarbeiter, da sie leicht ein Verständnis für das Produkt bekommen.
Doch auch die Nachteile und Anforderungen sollten beachtet werden:
- Fehlende Kundeninteraktion oder fehlendes Kundenfeedback führen schnell zu
Spekulationen. Die Methode ersetzt nicht den Austausch mit dem Kunden, sondern
erleichtert diesen und veranschaulicht die Ergebnisse. - Ein tiefes Verständnis aller technisch und fachlich produktrelevanten Aspekte ist zwingend notwendig. Das kann bei einer komplexen Produktentwicklung nur im Team erreicht werden.
- User Story Mapping liefert kein finales Ergebnis, auch Wiederholungen, kritische Prüfungen und Veränderungen sollten mit eingeplant werden.
- Auch wenn User Story Maps eine Reihenfolge aufzeigen, stellen sie nicht unbedingt die Abhängigkeiten zwischen den Anforderungen dar.
- Bei sehr großen Projekten werden mehrere Maps benötigt – das führt zu einer geringeren Übersichtlichkeit.
Tipps für den erfolgreichen Start:
Wer diese Visualisierungsform nutzen möchte, kann sich anhand einfacher Schritte den einzelnen User Stories nähern:
- Stellen Sie eine Gruppe zusammen, die das Produkt und die Interessen der Zielgruppe genau versteht.
- Erfassen Sie die Hauptaufgaben der Nutzer des Projekts oder der Anwendung.
- Jede Person in der Gruppe schreibt jetzt für sich eine Nutzeraufgabe auf ein Post-it.
- Bitten Sie das Team, die Post-it’s in Eigenarbeit zu gruppieren. Hier sind sie: die wichtigsten User Stories.
- Mit einem andersfarbigen Post-it wird nun jede Gruppe benannt und ein Name für die Oberkategorie gesucht.
- Arrangieren Sie die Gruppen von links nach rechts in der Reihenfolge, in der ein Nutzer typischerweise die Aufgaben ausführen würde.
- Wenn der Rahmen der Map feststeht, können detailliertere User Stories unterhalb jeder User Aufgabe hinzugefügt werden.
- Schließlich werden alle User Stories in Sprints aufgeteilt und der erste Sprint besprochen.
Wichtig ist immer, die User Story Map nicht als statisches Konstrukt zu sehen. Sie wird im Laufe der Zeit immer wieder angepasst werden, deshalb sind Statusmarker für Notizen sehr hilfreich (zum Beispiel mit „To-do“, „Done“, „Vorläufig“, „Erfordert Überprüfung“, „Zu entfernen“).
Jede Benutzergeschichte, die im Backlog oder in der Story Map existiert, ist nur eine Annahme, die auf Marktforschung, Geschäftsanalyse und Benutzerinterviews basiert. Machen Sie die Geschichten testbar. Eine der Möglichkeiten, um zu überprüfen, ob die Annahmen auch wirklich zutreffen, ist die Durchführung von User Tests, die echte Benutzer einbeziehen.
Mein Fazit zu User Story Mapping
Mithilfe von User Story Mapping können Teams schon in ein oder zwei Workshop-Tagen eine Übersicht entwickeln, mit dem sich ein Projekt oder ein Produkt starten lässt. Die Stärke der Visualisierungsmethode liegt in dem gemeinsamen Verständnis für das Produkt und den Kunden bei allen Teammitgliedern. Das ist im gesamten Projektverlauf wichtig, um nicht in eine falsche Richtung zu entwickeln. User Story Mapping ist also ein exzellentes Werkzeug für agile Teams – sie können die Lösung klar umreißen und sich trotzdem auf die Produktentwicklung konzentrieren.
