Es handelt sich um eine Technik, die vor allem in der Softwareentwicklung und im Produktmanagement verwendet wird. Sie hilft Teams dabei, besser zu verstehen, was ein Produkt oder eine Software tun soll und wie die Nutzer damit interagieren werden.
In einfachen Worten erklärt
- Was will der Nutzer?: Zuerst denkt man darüber nach, welche Aufgaben der Nutzer mit dem Produkt oder der Software erledigen möchte. Diese Aufgaben werden in kleine Geschichten oder „User Stories“ zerlegt.
- Sortieren der Geschichten: Diese kleinen Geschichten werden dann auf Karten geschrieben und auf einer großen Fläche (zum Beispiel einer Wand oder einem Tisch) in der Reihenfolge angeordnet, in der der Nutzer sie erleben würde.
- Gruppieren: Ähnliche Geschichten werden zusammengefasst. So entsteht eine Art „Landkarte“ (daher der Name „Mapping“), die zeigt, wie der Nutzer durch das Produkt navigieren wird.
- Priorisieren: Das Team entscheidet dann, welche Geschichten am wichtigsten sind und zuerst entwickelt werden sollten.
- Planung: Diese sortierte und priorisierte „Landkarte“ wird dann als Grundlage für die weitere Entwicklung und Planung verwendet.
Die Methode ist sehr visuell und interaktiv, was es einfacher macht, das große Ganze zu sehen und sicherzustellen, dass alle im Team auf dem gleichen Stand sind. Es hilft auch dabei, sich auf den Nutzer und seine Bedürfnisse zu konzentrieren, anstatt nur auf technische Anforderungen.
Das Rückgrat und die Scheiben
Eine Story Map hat zwei Richtungen, und beide bedeuten etwas anderes. Waagerecht liegt das Rückgrat: die Schritte, die eine Nutzerin nacheinander durchläuft, von links nach rechts erzählt wie eine Geschichte. Senkrecht hängt unter jedem Schritt, was dafür gebaut werden muss, oben das Nötigste, weiter unten das Angenehme.
Der eigentliche Trick sind die waagerechten Schnitte durch diese Fläche. Jeder Schnitt ist eine Lieferung, und jeder Schnitt muss für sich allein funktionieren. Nicht die ersten drei Schritte in voller Tiefe, sondern alle Schritte in der dünnsten Variante, die ein Mensch tatsächlich benutzen kann. Daran scheitern die meisten Releasepläne, weil sie in Bauteilen denken statt in benutzbaren Ergebnissen.
Wie eine Session abläuft
Ein halber Tag reicht für ein erstes brauchbares Bild. Wichtiger als die Dauer ist, wer im Raum steht. Drei Rollen müssen vertreten sein: jemand, der die Nutzer wirklich kennt, jemand, der das Ding am Ende bauen muss, und jemand, der entscheiden darf, was wegfällt. Fehlt die dritte Rolle, entsteht eine schöne Wand, die niemand umsetzt.
Material ist banal: eine lange freie Wand, Karten, Stifte. Erst das Rückgrat legen und laut erzählen, bis die Reihenfolge stimmt. Dann füllen. Dann schneiden. Und am Schluss fotografieren statt abtippen, denn der Wert steckt im gemeinsamen Verständnis und nicht im Dokument.
Vier Fehler, die das Ergebnis zuverlässig ruinieren
- Der Jira-Export landet an der Wand. Dann hängt der Export an der Wand und sonst nichts.
- Niemand mit echtem Nutzerkontakt steht im Raum. Dann bildet die Karte ab, was das Team vermutet.
- Der erste Schnitt ist zu dick. Ein Schnitt, der ein halbes Jahr dauert, ist der alte Plan mit Haftnotizen darauf.
- Die Wand wird abgeräumt und nie wieder angesehen. Eine Story Map ist ein Arbeitsstand und kein Ergebnisprotokoll.
Wann sich der Aufwand nicht lohnt
Eine Story Map beantwortet Fragen nach dem Nutzen. Fragen nach der technischen Umsetzung beantwortet sie nicht. Wenn klar ist, was gebraucht wird, und nur offen ist, wie es gebaut wird, spart der Workshop niemandem etwas. Umgekehrt ist sie das schnellste Mittel gegen die Sorte Projekt, in der alle nicken und hinterher jeder etwas anderes gemeint hat.
Häufig gestellte Fragen
Ein Backlog ist eine Liste, eine Story Map ist eine Fläche. Die Liste sagt, was als Nächstes drankommt. Die Karte zeigt, wo dieses Nächste im Ablauf der Nutzerin steht und was rechts und links davon noch fehlt. Deshalb entsteht aus einer Story Map ein Backlog und nicht umgekehrt.
Ein halber Tag reicht für ein erstes Bild, ein ganzer für ein Produkt mit mehreren Nutzergruppen. Länger wird es selten besser, weil die Genauigkeit nach ein paar Stunden schneller sinkt als die Erkenntnis steigt.
Für den ersten Durchgang nicht. Eine Wand und Karten sind schneller, und alle stehen dabei auf und reden miteinander. Digitale Boards lohnen sich danach, für verteilte Teams und zum Festhalten des Stands.
Wer eine Story Map zum ersten Mal an die Wand bringt, merkt schnell, dass die Methode der einfache Teil ist. Der unbequeme Teil ist die Entscheidung, was wegfällt. Genau dabei begleite ich Unternehmen über CTRL+ALT+LEAD, und als Frage vor Führungskreisen bringe ich sie in meinen Keynotes auf die Bühne.
Die Methode stammt von Jeff Patton. Was in seinem Buch steht, was daran stark ist und woran es hakt, habe ich in meiner Rezension zu User Story Mapping aufgeschrieben.
