Die Story Map – ein System entlang der Nutzerreise bauen

Als Produktverantwortlicher, Systemarchitekt oder Projektleiter bzw. deren Berater bist Du mit folgenden Fragen konfrontiert:

• Wer sind die Nutzer eines technischen Systems und wie gestaltet sich ihre Interaktionsreise?
• Was sind die wichtigsten Funktionen und Eigenschaften eines neuen Produkts und wann stehen diese zur Verfügung?
• Wie gelingt es uns bereits ab Projektstart ein abgestimmtes Überblicksbild eines Systems mit seinen Fähigkeiten und Eigenschaften zu entwickeln?

Unterstützung findest Du in der Story Map und dem Verfahrens des Story Mappings.

---

Ergebnis: Fähigkeiten und Eigenschaften eines Systems entlang der Nutzerreise entwickelt

Teilnehmer: mind. 1 (besser: im Team)

Dauer: mind. 60 Minuten (für Initialfassung, je nach Systemumfang und Teilnehmerzahl)

Utensilien: Flipchart/Whiteboard/Metaplan-Wand, Klebekarten & Stifte oder Notebook & Office Software

Zweck

Mit Hilfe einer Story Map entwickelst, analysierst und dokumentierst Du die auf ein System bezogene Nutzerreise (auch User Workflow). Die Karte kommuniziert visuell, was das System für wen in welchem Interaktionsschritt leisten soll. Das System kann dabei eine Software, eine App, ein Produkt, ein Service oder eine andere Art von Wertangebot sein.

Die Story Map hilft Dir…

• in der Entwicklung neuer Systeme bei der Strukturierung und Priorisierung eines Anforderungskataloges,
• im Rahmen der Einarbeitung von neuen Kollegen bzgl. der Reise des Nutzer entlang des Systems sowie
• bei der Weiterentwicklung und Optimierung eines bestehenden Systems.

Sprichwörtlich erzählt Du mit der Story Map die Geschichte eines Nutzers und seinen Aktivitäten, die er durchläuft um ein spezifisches Ziel zu erreichen. Das kann die heutige Geschichte sein, die Ist-Story Map, mit all ihren Schmerzen, Stolpersteinen und Hindernissen. Oder eine zukünftige Geschichte, die Soll-Story Map, mit allen Vorteilen, Belohnungen und Mehrwerten. Story Mapping hilft, den Überblick zu behalten.

Synonyme für die Story Map sind User Story Map oder der deutsche Begriff Geschichtskarte.

---

Aufbau

Story Map – „In welchen Aktivitäten unterstützt ein System den Nutzer?“

Eine Story Map besteht aus einer Vorlage auf der Du, die Kundenmitarbeiter und Deine Kollegen Karten mit kurzen & prägnanten Inhalten verortest. Eine gute Map besitzt einen aussagekräftigen Titel, der den Namen des Systems enthält. Außerdem findest Du in der Fußzeile das Datum der letzten Änderung sowie die Autoren.

Dabei gliedert sich der One Pager in vier Ebenen: Nutzer, Nutzeraktivitäten, Nutzeraufgaben und Nutzergeschichten. Gerne kannst Du die Elemente der vier Ebenen umbenennen. Aus Nutzergeschichten werden dann Nutzerfunktionen, aus Nutzeraufgaben die Funktionsbündel und aus Nutzeraktivitäten schließlich die Kernfunktionen. Die Hauptsache ist, jeder versteht, was gemeint ist.

Ebene 1: Nutzer (engl. Users) – „Wer verwendet das System?“

Die erste Ebene umfasst die Nutzer eines Systems. Häufig sind das die unterschiedlichen Anwendergruppen. Aber auch das Betriebs- und Wartungspersonal oder das Reparaturteam ist möglich.

Hefte die Nutzernamen als Karte ganz oben links auf die Story Map. Alternativ positionierst Du die Nutzerkarten über solchen Aktivitäten, die diese Nutzer am häufigsten ausführen. Achtung: Auch ein Nachbarsystem kann ein Nutzer sein.

Ebene 2: Nutzeraktivitäten (engl. User activities) – „Wozu benötigt der Nutzer das System?“

Die zweite Ebene gruppiert die nutzerübergreifenden Aufgaben zu Aktivitäten. Jede Aktivität zahlt auf ein klares Nutzerziel ein.

Aktivitäten sind als kurze Sätze mit einem prägnanten Verb am Ende formuliert.

Ebene 3: Nutzeraufgaben (engl. User tasks) – „Was tut der Nutzer mit dem System?“

Die dritte Ebene beinhaltet die verschiedenen von einem Nutzer absolvierten Tätigkeiten, um Teilziele des Gesamtziels zu erreichen. Auf der Story Map sind Nutzeraufgaben von links nach rechts in einem geschichtserzählenden Stil angeordnet.

Nutzeraufgaben sind ebenfalls als kurze Sätze im imperativ formuliert.

Ebene 4: Nutzergeschichte (engl. User Story) – „Welche Eigenschaft oder Fähigkeit benötigt der Nutzer vom System?“

Schließlich beinhaltet die vierte Ebene die ein jeder Nutzeraufgabe zugeordneten detaillierten Nutzergeschichten. Eine Nutzergeschichte beschreibt dabei eine Eigenschaft oder Fähigkeit eines Systems.

In der Map sortierst Du die zu einer Nutzeraufgabe zugehörigen Nutzergeschichten in absteigender Priorität von oben nach unten. An der Spitze der vertikal absteigenden Reihe stehen die fachlich wichtigsten, ganz unten die fachlich unwichtigsten Geschichten.

Beachte, dass sich User Stories auch inhaltlich überlappen können. Beschreibt beispielsweise oben in der Reihe eine User Story die manuelle Umsetzung einer Schnittstelle („Abtippen Excel-Daten in System“), kann eine weiter unten liegende Story den Job automatisieren („Synchrone Schnittstelle zum Vorsystem XY“).

---

Anwendung

Eine Story Map erstellst Du mittels Story Mapping. Dies funktioniert am besten im Team. Trefft Euch dazu stehend vor einem breiten Whiteboard oder einer Metaplan-Wand und beginnt gemeinsam die Interaktionsreise eines Nutzers mit einem existierenden oder neuen System zu entwickeln.

1. Nutzer und System definieren

Fixiere zunächst das System und dessen Nutzer. Eine hilfreich Techniken hierfür ist beispielsweise der System Footprint. Mit ihm definierst Du die Vision und den Scope des aktuellen bzw. zukünftigen Systems.

2. Nutzeraufgaben & -aktivitäten identifizieren

Fahre mit der Ebene 3 – den Nutzeraufgaben – fort. Versetze Dich in die Rolle eines (wenn nicht des wichtigsten) Nutzers.

• Welche Ziele verfolgt dieser, wenn er mit dem System arbeitet?
• In welcher Abfolge interagiert er mit dem System?
• Welche Reise (durch-)lebt er?

Notiere die Aufgaben von links nach rechts auf der Story Map. Fasse mehrere Nutzeraufgaben zu Nutzeraktivitäten zusammen. Jede Aktivität zahlt auf ein Ziel ein.

3. Nutzergeschichten detaillieren

Verfeinere die Nutzeraufgaben in kleine Nutzergeschichten.

• Welche Eigenschaften und Fähigkeiten muss das System besitzen?
• Welche Funktionen sollen – verborgen vor dem Nutzer – im Hintergrund ablaufen?
• Welche Schnittstellen zu anderen Systemen müssen existieren?

4. Teilumfänge planen

Lasse nun Deinen Kunden priorisieren.

• Welche Nutzergeschichten sollen als erstes umgesetzt werden?
• Welche später?
• Welche ist technisch schnell und einfach machbar, also ein Quick Win?

Notiere die wichtigsten Nutzergeschichten ganz oben. Markiere durch eine horizontale Linien, welche Nutzergeschichten in welcher Auflage (engl. Release) des Systems umgesetzt werden sollen.

5. Story Map pflegen

Anforderungen, Randbindungen und Ziele ändern sich. Damit auch das System und die Story Map. Bestimme einen Verantwortlichen, der regelmäßig die Karte aktualisiert und qualitätssichert.

Story Mapping ist ein iterativer Prozess. Statt am Stück in einem einzigen Durchlauf die perfekte Geschichtskarte zu kreieren, entwickelt ihr das Ergebnis in mehreren Durchgängen stetig weiter. Neue Aspekte kommen hinzu, bestehende fallen weg, andere werden verändert. Im Zentrum steht die Visualisierung und die Konversation.

---

Beispiele

Story Map für eine E-Mail Software

Untere Abbildung zeigt Dir die Story Map für eine E-Mail App. Für einen Nutzer ‚Unternehmensberater‘ schlägt die Karte drei Aktivitäten vor:

• E-Mails organisieren,
• E-Mails bearbeiten und
• Kalender managen.

Diese Nutzeraktivitäten werden wiederum in Nutzeraufgaben heruntergebrochen, welche ihrerseits erneut in noch kleinere Nutzergeschichten zerfallen.

Die Nutzergeschichten sind vertikal mit abnehmender Priorität sortiert. Von links nach rechts laufende Linien zeigen an, in welcher Softwareversion welche Nutzergeschichten umgesetzt sein wird.

---

Vor- & Nachteile

Pro

• Die Story Map liefert eine vollständige visuelle Übersicht aller Systemeigenschaften entlang der Nutzerreise. Das Gesamtbild lässt sich gut kommunizieren, analysieren und diskutieren. Priorisierungsentscheidungen lassen sich schneller fällen.
• Ein weiterer Trumpf der Methode ist die Ausrichtung auf den Nutzer, das Herunterbrechen von grob zu detailliert und die visuelle Präsentation von Systemeigenschaften und -fähigkeiten.
• Die Methode bedarf kein Vorwissen und lässt sich intuitiv anwenden. Fach- sowie IT-Kollegen verstehen das Konzept innerhalb von 15 Minuten.
• Eine erste Story Map steht bereits nach 90 Arbeitsminuten. Das motiviert für die Weiterarbeit. Gute Grundlage ist das Product Backlog.
• Durch die iterative Erstellung zusammen im Arbeitstreffen sorgt die Story Map ganz automatisch für ein einheitliches Verständnis und eine geteilte Sicht auf das System.
• Eine Story Map erleichtert die Entwicklung eines Minimum Viable Products. Visuell wird klar, welche minimalen Grundfunktionen ein System im ersten Teilumfang für eine Ende-zu-Ende Nutzerreise benötigt.
• Das Konzept hilft zudem aus Nutzersicht funktionale Lücken aufzuspüren und konzeptionell zu schließen.

Contra

• Die Erstellung einer Story Map setzt ein bestehendes System bzw. die Vision, den Scope sowie die Verknüpfung zu den Stakeholdern für ein neues System voraus. Auch ist ein umfassendes Verständnis aller systemrelevanten Aspekte erforderlich.
• Story Mapping kostet Zeit, sowohl bei der initialen Erstellung als später dann auch bei der kontinuierlichen Pflege. Gerade wenn viele Personen mitwirken kann eine Karte rasch sehr groß und detailliert werden.
• Die Gefahr beim Story Mapping besteht, sich bei der Nutzerreise auf den ‚Happy Path‘ – also den Standardablauf – zu konzentrieren. Relevante Sonderfälle werden unbewusst ausgeblendet.
• Die Story Map ist ein Planungs-, Analyse- und Kommunikationswerkzeug, jedoch kein finales Endergebnis.
• Qualitätseigenschaften eines Systems, Schnittstellen, Abhängigkeiten, einzuhaltende Randbedingungen, Qualitätseigenschaften sowie Systemziele werden von einer Story Map nicht erfasst. Auch berücksichtigt das Tool keine Projektaspekte wie Stakeholder, Risiken oder Budgetplanung.
• Das Tool ist vornehmlich in der Software Engineering Welt bekannt. Bei klassischen Geschäftseinheiten und Linienorganisationen Bedarf die Einführung des Story Map Konzepts Fingerspitzengefühl, die richtigen Teilnehmer und ein Mandat des Managements.

---

Praxistipps

Tipp 1 – Story Map mittels Geschichten überprüfen

Eine gute Möglichkeit eine Story Map zu prüfen ist das Erzählen einer Geschichte. Starte mit dem Nutzer und berichte von seinen Zielen.

Anschließend durchläufst Du die Nutzeraufgaben welche vom Start zum Ziel führen. Bei jeder Aufgabe gehst Du kurz auf die Details ein, berichtest von den wichtigsten Nutzergeschichten.

Im Erzählfluss entdeckst Du und die anderen Lücken, Inkonsistenzen und überflüssige Aspekte. Außerdem bringt Ihr Risiken ans Licht und greift erste Umsetzungsideen auf.

Tipp 2 – Story Map analog und/oder digital einsetzen

Story Mapping analog am Whiteboard oder digital am Notebook? Beides funktioniert aus meiner Praxis. Auch ein hybrides Modell tut es. Du wirfst den Rahmen einer Story Map mittels Beamer an die Wand und klebst anschließend physische Karten auf die Projektionsfläche.

Tipp 3 – Nutzergeschichte mit Text & Farbe erweitern

Ergänze die Karten einer Story Map mit Zusatzinformationen. Beispielsweise ergänzt Du die Nutzergeschichten mit einem Status wie ‚Erledigt‘ bzw. ‚In Arbeit‘. Oder Du versiehst bestimmte Aufgaben mit Farben und ordnest diese somit einem Projektteam zu. Oder Du notierst auf der Rückseite die Quelle für die Nutzergeschichte.

Tipp 4 – Wert auf Breite statt Tiefe legen

Die Story Map liefert den Überblick, keine Details. Damit verfolgt sie das ‚Mile-wide-Inch-deep‘-Prinzip, also hohe Breite, geringe Tiefe. Konkret heißt das: Einzelheiten zu den Nutzergeschichten, Aufwände, Verantwortlichkeiten, Abhängigkeiten etc. notierst Du an anderer Stelle.

Tipp 5 – Story Map zentral & gut sichtbar aushängen

Stelle die Story Map zentral auf bzw. lege die virtuelle Fassung einfach zugänglich ab. Jeder im Projektteam sollte die Aspekte des Systems mit geringem Aufwand sehen können. Am besten Du stellst sie neben die Kaffeemaschine. Bei der Kaffeepause wird das Team automatisch an das System erinnert.

Tipp 6 – Anforderungen ans System als Basis nutzen

Eine Story Map fungiert als ein gemeinschaftlich erarbeitetes, abgestimmtes und zentrales Big Picture des Systems. Sie ersetzt nicht den Dialog mit dem Nutzer.

Um zu erfahren, welche Bedarfe ein Nutzer in welcher Güte an das System hat, musst Du zu zusätzliche Methoden in Spiel bringen. Interviews, Beobachtungen, Workshops, Prototypen auf Basis von Hypothesen und Testkarten, Befragungen etc. helfen die Interaktionsreise und Anforderungen zu bestimmen.

Lesetipp

Das Referenzbuch für Story Maps ist Jeff Pattons User Story Mapping- Nutzerbedürfnisse besser verstehen als Schlüssel für erfolgreiche Produkte*. Patton bezeichnet sich als Chief Troublemaker, berät in den Felder Product Management, Agile, Lean, User Experience und Design.

---

Ursprung

Angeblich gehen Story Map und Story Mapping auf den US-Amerikaner Jeff Patton zurück. Er entwickelte das Konzept auf Grundlage von Extreme Programming (XP) und agilen Entwicklungsansätzen wie Scrum und Kanban.

Als Vorlage diente Patton dabei sicherlich die Customer Journey, also die Reise eines Kunden vom Erstkontakt mit einem Angebot bis zu dessen Kauf und Verwendung.

---

Bonusmaterial

VisualParadigm: How to Create a User Story Map (4 min) – Erklärungsvideo untermalt mit klassischer Musik

Jeff Patton: User Story Mapping with Jeff Patton (116 min) – Jeff Patton erklärt das Konzept der Story Map vor deutschsprachigen Teilnehmern

• Jeff Patton & Associates: Story Map Concepts – Auf zwei Seiten wird Aufbau und Vorgehen erklärt optisch ansprechend erklärt
• Thomas Wuttke: ImpactMaps – Ordnung im Backlog (31 min) – Podcast über die Nutzung von Story Maps zur Strukturierung eines Product Backlogs

Letzte Aktualisierung am 2024-11-20 / Affiliate Links / Bilder von der Amazon Product Advertising API