Story Map
Das Story Mapping ist eine von Jeff Patton entwickelte Methode. Sie wird in der agilen Entwicklung angewendet, um von der Reise, die ein Kunde mit einem Produkt unternimmt, zu erzählen und diese übersichtlich darzustellen.
Ziel
Mit der Story Map entwickelt das gesamte Team ein besseres Verständnis davon, was der Nutzer vom Produkt braucht und wie die Nutzung des Produktes aussehen soll. Durch die Darstellungsform können sowohl fehlende Funktionen als auch Abhängigkeiten zwischen Funktionen identifiziert werden.
»Story Mapping sorgt dafür, dass wir uns auf die Benutzer (User) und ihre Erfahrungen (User Experience) konzentrieren. Das Ergebnis ist eine bessere Konversation und schlussendlich ein besseres Produkt.« – Jeff Patton
Darüber hinaus kann dir die Story Map bei der Releaseplanung helfen.
Geschichte
Ohne die Story Map als solche zu benennen beschreibt Jeff Patton das Prinzip zum ersten Mal im Jahr 2005 in seinem Artikel “It’s All in How You Slice It”. Konkreter wird es im Jahr 2008, als er in seinem Artikel “The new user story backlog is a map” ausführlich erklärt, dass das eindimensionale Backlog nicht genügend Möglichkeiten bietet, um auf das Produkt als Ganzes zu fokussieren. Im Jahr 2014 beschreibt er die Methode ausführlich in seinem Buch „User Story Mapping: Discover the Whole Story, Build the Right Produkt“.
Funktionsweise
Die Story Map bietet dir zwei Dimensionen zum Arbeiten.
Die horizontale Dimension wird von links nach rechts gelesen. Sie orientiert sich an der Reihenfolge der Aktivitäten, die ein Nutzer bei der Verwendung deines Produktes durchführt. Dabei sind die Aktivitäten des Nutzers jeweils auf Kärtchen festgehalten. Wenn du die Interaktion des Nutzers mit dem Produkt beschreibst, verbindest du diese Aktivitäten mit “und dann…”. Dadurch entsteht eine Geschichte, die Story. Varianten oder kleinere Teilschritte beim Durchführen einer Aktivität werden unter den Aktivitäten ergänzt.
Über die vertikale Dimension hast du weiterhin die Möglichkeit, in Zeilen den Umfang von bspw. Releases zu beschreiben. Dies tust du beispielsweise, indem du die Aktivitäten, die unterstützt werden sollen, in die entsprechende Zeile ziehst.

Doch lass uns den Aufbau Stück für Stück besprechen:
Der Backbone
Auf der obersten Ebene der Story Map siehst du den Backbone. Dieser beschreibt die Interaktion des Nutzers mit deinem Produkt als Abfolge von Aktivitäten. Eine Aktivität beschreibt einen Arbeitsschritt, den man abschließt, bevor man einen neuen beginnt. So eine Aktivität ist bspw. das Duschen. Üblicherweise unterbrichst du deine Dusche nicht, um später fertig zu duschen. Die Liste der Aktivitäten von links nach rechts gelesen bildet also die Geschichte deines Nutzers mit dem Produkt in groben Schritten ab. Es spielt bei der Darstellung keine Rolle, ob einzelne Aktivitäten manchmal in einer anderen Reihenfolge ausgeführt werden oder in einer spezifischen Situation komplett entfallen.
Das Walking Skeleton
Das Walking Skeleton beschreibt die kleinstmögliche Version deines Produktes aus technischer Sicht. Es beschreibt die minimale und doch „lauffähige“ Umsetzung eines kompletten Funktionsbereiches bzw. Geschäftsprozesses und stellt somit sicher, dass der Prozess aus technischer Sicht von Beginn bis Ende durchgespielt werden kann. Somit dient das „Walking Skeleton“ dazu, die technische Machbarkeit deines Produktes zu überprüfen. Durch das Hinzufügen von Grundfunktionen für den Nutzer ergibt sich dann ein MVP.
Body
Im Body der Story Map finden sich Tasks. Diese beschreiben die Aktivitäten auf einem nächsten Detaillevel. Außerdem kannst du mit Tasks Varationen der Ausführung einer Aktivität abbilden. Die Tasks sind jeweils unter die Akvititäten gemappt, die sie näher beschreiben.
Releaseplanung mit der Story Map
Deine Story Map kannst du nun auch zur Planung von Releases und Sprints nutzen. Dabei kann die Planung auf unterschiedliche Weise erfolgen: Zum einen durch das Einzeichnen horizontaler Linien zwischen den Tasks und die Umsortierung dieser in die entsprechenden Zeilen, zum anderen können die einzelnen User Tasks ohne weitere Sortierung durch Release Lanes je nach Bedarf verbunden werden.
Anpassung der Story Map
Deine Story Map kann sich im Projektverlauf durchaus verändern, z.B. wenn ihr durch Nutzerfeedback Input bekommen habt oder im Team eine tolle Idee für die Verbesserung eines Features bekommen habt. Es empfiehlt sich daher, regelmäßig mit der Story Map zu arbeiten, sie entweder physisch gut sichtbar oder virtuell leicht zugänglich bereitzustellen.
Einsatz
Nachdem wir die grundlegenden Elemente der Story Map vorgestellt haben, wollen wir nun an das Entwerfen gehen. Zunächst einmal solltest du dafür dein Team versammeln. Auch angrenzende Teams oder wertvolle Inputgeber außerhalb deines Teams können beim Story Mapping unterstützen. Nicht zuletzt sind aktuelle oder potenzielle Nutzer wichtige Inputgeber für die Story Map. Wenn du eine Story Map für die gesamte Nutzergeschichte entwirfst, geh wie folgt vor:
1. Den Rahmen feststecken
Vor dem Story Mapping sollte eine kurze Beschreibung des Produktes erstellt werden. Die Beschreibung sollte den wesentlichen Rahmen feststecken. WIE heißt euer Produkt? WAS für ein Problem wollt ihr mit eurem Produkt lösen? WER sind die wesentlichen Nutzer eures Produktes? WARUM ist euer Produkt ein Mehrwert für eure Nutzer?
2. Das Big Picture malen
Startet mit dem Big Picture. Notiert von links nach rechts die Schritte, die der Nutzer mit eurem Produkt unternimmt. Fokussiert euch hierfür möglichst größere Tasks und Aktivitäten und den für euren Produkterfolg kritischsten Nutzer. Stellt euch einen typischen Tag im Leben des Nutzers vor und wie er euer Produkt verwenden würde.
Identifiziert die Aktivitäten. Einzelne Aktivitäten werden oft klarer, wenn der Erzählfluss grob steht. Nutzt die Chance zu iterieren und eure Aktivitäten Stück für Stück zu vertiefen.
Steht der Erzählfluss für die Geschichte des kritischsten Nutzers, könnt ihr weitere Nutzer in die Story Map hinzufügen.
3. Erkunden
Nachdem der Erzählfluss und die Aktivitäten identifiziert sind, füllt den Body eurer Story Map. Brecht hierzu größere Nutzeraufgaben in Teilaufgaben auf und verseht diese mit passenden Nutzerinterfaces. In dieser Phase kann es eurem Team helfen
- Euch die Frage zu stellen “Was wäre wenn…”?
- Euch ausgefallene Variationen zu überlegen
- Euch in unterschiedliche Nutzer hineinzuversetzen
- Menschen außerhalb eures Team um Feedback zu bitten
In dieser Phase geht es vor allem darum, euren Ideen freien Lauf zu lassen und diese zu sammeln. Habt Spaß dabei!
4. Releases schneiden
Nachdem ihr Ideen gesammelt und die Nutzeraufgaben detailliert habt, geht es nun darum, eine ganzheitliche Produktversion, d.h. ein Release, zu schneiden.
Wenn ihr bereits eine zielorientierte Roadmap erstellt habt, könnt ihr die Funktionalitäten identifizieren, die ihr für das Erreichen des jeweiligen Releaseziels für relevant haltet.
Es ist auch möglich, nur für Teile des Produkts Story Mapping zu nutzen und bspw. eine Gruppe zusammengehöriger Features zu betrachten. Genauso kannst du den Scope der Story Map erweitern und die gesamte Customer Journey abbilden.
Beispiele
Die Vorbereitung eines Story Mapping Workshops kann viel Zeit kosten. Aus diesem Grund hat Jeff Petton ein Beispiel zum Üben der Methode weitestgehend vorbereitet:
»Basically, I’ve chopped, mixed, and cooked up a small software product. It’s nearly done. But to finish it, you’ll need to add a little of your own effort.« – Jeff Patton
DIE MOBILE PLANNING UND TO-DO LISTE
Es geht um eine simple App zur Erstellung von To-Do Listen, Plänen oder was auch sonst deine Zielgruppe sich wünscht. Wer deine Zielgruppe ist und was genau erstellt werden soll, musst du selbst festlegen. Die Unterlagen findest du unten unter “Downloads”.
Tools
Wir empfehlen dir, Story Maps gemeinsam mit deinem Team zu entwerfen. Analog benötigst du für das Story Mapping lediglich eine freie Fläche wie z.B. Wand, Fenster, Moderationswand oder Tischfläche. Liegt bereits eine ähnliche Aufbereitung oder Visualisierung vor, berücksichtige entsprechend zusätzliche freie Flächen für weitere Sortierungen nach der Kundenreise. Wenn z.B. bereits erste Inhalte vorbereitet wurden, kann es sich in der Gruppenarbeit herausstellen, dass diese aufgrund weiterer Abhängigkeiten anders gruppiert werden müssen. Erfahrungsgemäß ist es umständlich, die Elemente innerhalb des bestehenden Aufbaus umzusortieren. Auf einer weiteren freien Fläche können diese leichter Schritt für Schritt umgezogen und neu strukturiert werden.
Digital gibt es mittlerweile mehrere Möglichkeiten. Je nachdem welche Tools schon in Verwendung sind bietet zum Beispiel sowohl Miro, als auch Jira Story Map Addons an. Ansonsten existieren auch eigene Story Mapping Tools, wie zum Beispiel Craft.io.
Fragen
- Hast du schon mit einer Story Map gearbeitet?
- Welche Vorteile bringt die User Journey als Ausgangspunkt für die Story Map?
- Was könnten Vor- und Nachteile der verschiedenen Arten sein, wie Releases eingezeichnet werden?
Diskussionen
Hier geht es zum Diskussionsforum zu Handbuchkapiteln auf dem oncampus.
Downloads
Jeff Pattons To-Do-List Beispiel:
- Eine Problembeschreibung
- Ein ausgefülltes Opportunity Canvas - mit ein paar sehr vagen Angaben, die ihr gemeinsam ausführlicher gestalten könnt
- 3 mögliche Persona mit extra Platz für weitere Details
- Eine Story Map zum Ausdrucken (optimiert für Avery pre-perforated business cards)
- Ein paar UI Skizzen als Ideeninput
Quellen, Links und Hinweise
- Patton, Jeff (2014); User Story Mapping- Discover the whole story, build the right product
- Patton, Jeff (2008): The New User Story Backlog is a Map