digitalien.org — Stefan Knecht
User Story Mapping schafft Sinn und Ordnung
User Story Mapping (USM) ist eine visuelle Methode. In kleinen Gruppen werden gemeinsam und im Storytelling viele User Stories organisiert und priorisiert.
- Wertschöpfungskette und Workflow werden sichtbar
- Beziehungen und Abhängigkeiten größerer Stories zu untergeordneten, kleineren Stories werden ersichtlich
- die Vollständigkeit des Backlog kann geprüft werden
- die Erreichung ökonomischer Geschäftsziele wird validiert: welchen Nutzen schaffen wir?
Jeff Patton hat User Story Mapping als strukturierte Methode ausgearbeitet und das Vorgehen beschrieben:
Story Maps wirken durch Story Telling.
Es steckt angewandte Psychologie dahinter: wir konstruieren Realität im aktiven Gespräch. Jerome Bruner hat 1991 erforscht, wie Story Telling wirkt. Sinn und Zusammenhang verstehen im Diskurs mit anderen Menschen besser. Geschichten erzählen um die nackte Anforderung herum ist der Kitt, der viele einzelne Informationen verständlich macht.
Wenn eine große Story als zentrales Bedürfnis in einem Gespräch mit allem Kontext vorgetragen wird — dann wird sie automatisch zu kleineren Stories segmentiert. USM macht sich das zu Nutze: im gemeinsamen Sprechen sollen neue Einsichten sofort und nachvollziehbar auf Karten dokumentiert werden, dann gehen sie nicht verloren.
USM als einfaches Schema
Entlang der Wertschöpfungskette werden Stories von links nach rechts, von der ersten Interaktion des Nutzers mit dem geplanten System bis zum Erreichen des Ergebnisses angeordnet.
Jede Karte ist eine User Story. Stories verwenden kurze Sätze mit Verben und beschreiben, was Menschen weshalb tun.
- Start-to-End: horizontal zuerst in die Breite, dann vertikal in die Tiefe, vom Allgemeinen zum Speziellen.
- Duplikate werden identifiziert und aussortiert.
- Ähnliche Stories werden gruppiert und gekennzeichnet, dann konsolidiert.
- Stehen Karten/Items in der vertikal weiter oben, dann sind sie notwendig und wichtig. Weiter unten werden die weniger wichtigen Stories platziert.
Die hier blauen Karten/Stories sind große Stories oder Epics und Aufgaben auf dem Weg zu einem Ziel.
Die roten Karten sind Features/Tools/Werkzeuge der Software um diese Aufgaben zu erfüllen.
Es gibt also Ziele, Aufgaben und Werkzeuge:
- Ziele sind Geschäftsziele: ein Nutzer soll etwas tun oder als Kunde kaufen
- Aufgaben/Aktivitäten sind Geschäftsprozesse: etwas, was der Nutzer aktiv tut um das Ziel zu erreichen
- Werkzeuge sind Features/Eigenschaften des (Software-)Systemes
Sind die User Stories vollständig, dann müsste ein Nutzer von links nach rechts die Wertschöpfungskette durchlaufen, das Ziel unterbrechungsfrei erreichen und mindestens zufrieden sein mit dem Ergebnis.
Und was, wenn Stories sich vermehren ...?
Nach jedem Story Mapping Workshop werden vermutlich noch mehr Karten/Stories an der Wand sein als zuvor.
Genau darum geht es: immer besser verstehen, was genau zu tun ist. Erst Vermutungen formulieren, dann prüfen, gruppieren und aussortieren.
»Scope doesn’t creep — understanding grows.«
Mit mehr Stories ufert nicht das Produktziel aus — das Verständnis wächst.
Wenn mit sehr vielen Stories, mehr, als man sich merken kann, die Story Hell winkt — ist das nicht nachträglich und das Gegenteil der Klärungen und Priorisierung, zu der USM geschieht?
Nein — im Gegenteil: das sich immer wieder beschäftigen mit den Geschichten lässt Verständnis wachsen und Zusammenhänge besser begreifen. Wird in Scrum gearbeitet, dann ist dieses Refinement eine ständige Aufgabe des Entwicklungsteams und des Produktverantwortlichen, keine Fleißarbeit.
Wie ist die Nutzungserfahrung? Use Cases und Personas
Einen prototypischen Nutzer gibt es selten. Es ist also wichtig, Bedürfnisse und Nutzungserfahrungen vieler verschiedener Nutzer so gut als möglich zu kennen um reale Bedürfnisse zu bedienen.
- Was genau ist über Nutzer bekannt?
- Welche Erfahrungen machen Nutzer bislang mit vorhandenen oder ohne Lösungen?
- Wie erreichen Nutzer welche ihrer Ziele?
Szenarien oder Use Cases sind mit Personas gut zu verstehen. Es wird mehrere Personas geben. Use Cases beschreiben, was eine Persona erreichen will und wann sie dem Weg und Ergebnis zufrieden ist.
Mit den Eigenschaften/Features des Produktes soll mindestens eine zufriedene Nutzungserfahrung erreicht werden. Unzufriedene Nutzer suchen nach anderen Angeboten. Zufriedene Nutzer kehren vielleicht zurück und das Geschäftsziel wird erneut bedient. Besser noch sind begeisterte Nutzer, die einen ripple effect auslösen, ihre Begeisterung teilen und authentische Werbung machen.
User Story Maps haben zwei anatomische Eigenschaften
Das Rückgrat oder backbone des Systems sind alle essenziellen Aktivitäten zum Ziel.
Das laufende Skelett oder walking skeleton ist das System, das die minimal notwendigen Aufgaben für die komplette Nutzererfahrung umfasst. Der Begriff stammt von Alistair Cockburn.
Das walking skeleton ist das MVP, das minimum viable product.
Ein MVP hat so wenige notwendige und hinreichende Eigenschaften, dass Nutzer das Ziel erreichen können. Erst dann sind Tests und reales Feedback von realen Nutzern sinnvoll möglich.
Ohne MVP und ohne echte Nutzungsdaten und Rückmeldungen bleiben alle Annahmen Spekulation.
Story Mapping: MVP für einen Webshop
Am Beispiel eines Webshop wird das Vorgehen schnell einleuchtend:
Die blauen Karten sind Epics oder grosse Stories. Von links nach rechts bilden Sie als Backbone ab, was der Webshop mindestens leisten muss, so dass Kunden Produkte kaufen können.
Die roten Karten darunter sind User Stories. Die oben stehenden sind wichtiger als die darunter. Zu jeder Story gehört ein Stapel darunter liegender weiterer Stories.
Wo ist der Fehler?
Das Team hat User Story Mapping zum ersten Mal als Methode zur Sortierung und Priorisierung des Backlog angewendet.
Welche der Karten fallen aus der Reihe?
Welcher Art sind diese Stories — und wie könnten diese Anforderungen besser abgebildet werden?
Reality Check: Was ist das Ziel des Produktes?
Bevor Stories im Backlog priorisiert werden — Abstand nehmen und immer wieder dieselbe Frage stellen:
Welchen Nutzen hat das Unternehmen von diesem Produkt?
Die Produktvision setzt beobachtbare Ziele. Ziele sind messbar und ökonomisch sinnvoll. Allein das zählt.
Das Outcome (Nutzer verwenden das System) kann man meist recht schnell nach dem Output (System ist live) beobachten. Den langfristigeren Impact als ökonomischen Nutzen zu messen, kann ein wenig dauern.
Produktziele und -nutzen müssen ökonomisch quantifizierbar, messbar, beobachtbar sein.
- Der Nutzen unternehmensinterner Systeme kann Vereinfachung, geringere Kosten, weniger Aufwand oder notwendige Technologiewechsel sein.
- Produkte für Konsumenten (B2C, business to consumer ebenso wie B2B) machen Umsatz und verdienen Geld für das Unternehmen, erhöhen die Kundenbindung oder unterstützen wiederholte Verkäufe an zufriedene Kunden.
Das ökonomische Ziel ist: Verhalten ändern
Bei allen Transaktionen geht es um Verhaltensänderung. Ein Nicht-Kunde soll zu einem Kunden werden, ein Nicht-Nutzer zu einem Nutzer.
Es kann um Geld gehen, muss aber nicht:
- in kostenlosen Angeboten wie sozialen Netzen bezahlen wir mit unserer Aufmerksamkeit für Werbung
- im eCommerce bezahlen wir mit Geld für Produkte oder Dienstleistungen.
Der Impact/Konsequenz eines Projektes ist die Verhaltensänderung von Menschen.
Darum geht es: Nutzer sollen mit dem Projekt sich anders verhalten als zuvor.
Ökonomischen Nutzen bringen Verhaltensänderungen bei Kunden/Nutzern — nicht die Beschäftigung mit den Strukturen des eigenen Unternehmens. Was in Meetings geschieht, in PowerPoint verewigt wird oder auf Stundenzettel geschrieben ist, ändert das Verhalten von Kunden/Nutzern nicht.
Also: so schnell als möglich in messbare Verhaltensänderungen investieren und so wenig als möglich in output/Meetings oder outcome/Präsentationen und Reportings.
»Your job is not to build more — it’s to build less. Minimize output, and maximize outcome and impact.«
»Die Aufgabe ist, so wenig wie möglich zu bauen, nicht so viel als möglich. Den Output minimieren, Outcome und Impact maximieren.«
Das MVP als bare minimum — das HiPPO als Gegenteil
Frank Robinson prägte 2001 den Begriff MVP als gemeinsames Ergebnis aus Produkt- und Nutzerentwicklung. Robinson nannte das synchrone Entwicklung. Populär machte Eric Ries das Vorgehen nach MVP in seinem Buch Lean Startup — nach wie vor eine Pflichtlektüre für agilere Organisationsformen.
Ein MVP ist das kleinstmögliche Release mit so wenigen Produktfeatures wie möglich — und hinreichend um die erwarteten Outcomes/Ergebnisse und Annahmen in konkreter Beobachtung zu prüfen.
»The MVP is the right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction and sales, but not so big as to be bloated and risky. Technically, it is the product with maximum ROI divided by risk. The MVP is determined by revenue-weighting major features across your most relevant customers, not aggregating all requests for all features from all customers.«
»Das MVP ist das Produkt in richtiger Dimension für Unternehmen und Kunden. Es ist groß genug, um Akzeptanz, Zufriedenheit und Umsatz zu bewirken, aber nicht so groß, dass es aufgebläht und riskant ist. Technisch gesehen ist das MVP das Produkt mit maximalem ROI geteilt durch das Risiko. Der MVP wird durch die Umsatzgewichtung der wichtigsten Funktionen für Ihre wichtigsten Kunden bestimmt, nicht durch die Zusammenfassung aller Anforderungen für alle Funktionen von allen Kunden.«
Mit einem MVP Produkte und Lösungen zu entwickeln ist damit eher eine Führungshaltung als realistischer Managementstil, mit dem Annahmen geprüft und gegebenenfalls auch verworfen werden — wenn sich herausstellt, dass diese Annahmen nicht zutreffen.
»The alternative (to an MVP) is the HiPPO” method — the “highest paid person’s opinion.”
That one sucks worse.«
»Die Alternative (zu einem MVP) ist die HiPPO-Methode: Die Meinung der Person mit dem höchsten Rang (bestimmt Features).
Das ist übler.«
Klare Produktziele definieren iterative Releases
Story Mapping hilft bei der Priorisierung von Stories um daraus iterative, auf einander aufbauende Releases zu planen. Releases sind zunehmend bessere und reichhaltigere Iterationen mit denen die Produktziele schneller oder komfortabler erreichbar sind. Iterationen bieten mit jedem Schritt bessere Qualität. Das “zunehmend besser werden” ist der Begriff inkrementell
User Story Mapping ist iterativ:
Produkteigenschaften werden mit jedem Release differenzierter, besser ausgefeilt und komfortabler.
Die haptische, visuelle Darstellung als Karte stellt Transparenz her. Die blauen Karten sind Aktivitäten, von links nach rechts betrachtet führen Aktivitäten zum Nutzungsziel. Die roten Karten darunter differenzieren innerhalb einer Aktivität.
- horizontale Swimlanes gruppieren Features/Stories zu Releases
- Features/Stories priorisieren vertikal nach der Notwendigkeit einer Story aus der Nutzerperspektive
- die Aufteilung von Aktivitäten in kleinere Portionen ermöglicht das Verschieben von Stories in folgende Releases
Das erste Release R1 ist ein walking skeleton und bringt nur notwendige Features. Also nur die Funktionen, die gerade ausreichen, um das Produktziel zu erreichen. Demonstriert wird die denkbar einfachste Implementierung.
Das walking skeleton kann das MVP (minimum viable product) sein. Es bietet nur die Mindesteigenschaften eines Produktes um schnell echtes Feedback von realen Nutzern/Kunden zu erhalten.
Feedback ist wichtig um schnell feststellen zu können: Sind wir auf dem richtigen Weg oder geht das Produkt am Bedarf vorbei?
Das zweite Release realisiert nach den notwendigen Features weitere Eigenschaften. Diese erleichtern Nutzern mit Aktivitäten und (Software-)Tools ihr Ziel zu erreichen und bieten weitere Möglichkeiten.
Das dritte Release poliert vielleicht noch einige Kanten und verbessert die Nutzererfahrung (user experience) — es macht die Interaktion einfacher oder variiert Randbedingungen und Datentypen. Edge Cases, seltene Datentypen und Ausnahmen werden abgefangen oder im Frontend validiert
Wenn es zu einem vierten Release kommt, wird weiter an weiteren Vereinfachungen, Design und Ästhetik oder Komfortfunktionen optimiert. Wartezeiten werden eliminiert oder Abkürzungen angeboten.
User Story Mapping ist iterativ:
Produkteigenschaften werden mit jedem Release differenzierter, besser ausgefeilt und angenehmer zu benutzen.
In Schichten vorgehen: von der Story zur Iteration, zum Release, zum Produkt
Jeff Patton verwendet eine Zwiebel als Bild für aufeinander aufbauenden Schichten.
- Welches Bedürfnis/Anforderung erfüllt diese Story?
- Wie genau sieht die Lösung aus?
- Wie kann ich die Erfüllung der Story feststellen?
Akzeptanztests machen beobachtbar, ob die Story so umgesetzt wurde, dass das Bedürfnis bedient wurde.
- Was genau wird implementiert?
- Wie bringt uns diese Iteration näher an die Ziele des nächsten Release?
Definierte Sprint-Ziele erleichtern die Konzentration auf ein Teilziel.
Formulierte Ziele der Entwicklung helfen auszublenden, was gerade keinen Nutzen bringt.
- Wie können wir inkrementell, zunehmend mehr Nutzen anbieten und realisieren?
- Welche Geschäftsziele erfüllt das Release?
- Welche Personas und Nutzergruppen bedient dieses Release?
Eine Release Roadmap skizziert, in welcher Reihenfolge Features erweitert und verfeinert werden.
Personas differenzieren Nutzertypen und Randbedingungen spezifischer Nutzungskontexte.
Dieses Projekt gibt es um ökonomischen Nutzen zu schaffen.
Ist der Impact des Projektes eine beobachtbare Verhaltensänderung?
Sind alle relevanten Kundengruppen adressiert?
Sind Personas mit vielleicht verschiedenen Randbedingungen und Bedürfnissen mit dem Produkt/Projekt zufriedener als zuvor?
Inkrementell < > Iterativ
Wiederum Jeff Patton brachte das schöne Beispiel der Entstehung eines Ölgemäldes.
Zwei zentrale Begriffe lassen sich so besser begreifen: was ist iterativ, was bedeutet inkrementell?
Wie geht ein Maler vor? Inkrementell oder iterativ?
Vor dem ersten Pinselstrich steht die Idee des Malers: »Eine Frau blickt mich direkt an, im Hintergrund ist Landschaft«.
Hat der Künstler das fertige Bild einer Mona Lisa im Kopf und malt es Pixel für Pixel aus dem Gedächtnis? Oder nähert er sich an: skizziert, übermalt, wählt andere Elemente?
Inkremente haben ein komplett vollständiges Zielbild. Wie bei einem Mosaik wird das fertige Bild aus eindeutig definierten Einzelteilen zusammengebaut. Alle Anforderungen, alle requirements beschreiben in ihrer Summe das fertige Produkt. Es fehlt nichts. Das Zielbild wird exakt und ohne Abweichung erreicht.
Übertragen auf ein Softwareprojekt kann perfekte Planung geschehen: geliefert wird in scope, in time, in budget. Diese objektive Qualität bedeutet, alle zuvor restlos bekannten Anforderungen konform zu erfüllen.
Iterationen skizzieren und implementieren eine grobe Version. Dann verbessern sie die Produktqualität in kleinen Schritten.
Die vage Idee experimentiert mit Lösungen bis eine Umsetzung die Bedingungen hinreichend erfüllt. Mit Iterationen wird die subjektive Qualität optimiert bis Benutzer zufrieden sind.
Story Mapping Workshops planen und durchführen
Ein Story Mapping Workshop ist ein aktives Format, in dem das Entwicklungsteam, der Product Owner und die wichtigen Stakeholder eine gemeinsame Sicht auf das weitere Vorgehen entwickeln.
Bei kleineren Vorhaben sind das typischerweise 5-8 Personen, bei größeren können es auch 30 Personen werden.
Vorsicht: die Durchführung erfordert wie jede Grossgruppenveranstaltung Erfahrung, Vorbereitung und Nerven aus Stahl.
Der Kniff für die Skalierung ist, dass nicht frontal präsentiert und konsumiert wird. Die Teilnehmenden sind in vielen Breakout-Meetings in Kleingruppen selbst aktiv und tragen danach immer neue Erkenntnisse in die große Gruppe zurück. Vor den Flipcharts versammeln sich gemischte Gruppen aus Entwicklern, Kaufleuten und Stakeholdern und diskutieren lokal. Sie kommen “zu Besuch” bei anderen Gruppen, gleichen ab, tauschen Ergebnisse aus.
Bereiten Sie alle Teilnehmenden darauf vor, dass es ein intensiver und involvierender Tag wird und kein ereignisarmer Regeltermin. Erklären Sie ausführlich, wie der Workshop funktioniert. Eine Eisbrecherübung zum Start ist ratsam um auf die vielleicht ungewohnte Form der Gruppeninteraktion vorzubereiten.
Die Mischung der Teilnehmenden über Gewerke, Spezialisierungen und Abteilungen macht Story Telling und die Zusammenarbeit wirksam. Es sollten kaufmännisch denkende Personen dabei sein, Softwareentwickler und IT-Techniker aus der Infrastruktur. Je erfahrener und ‘seniorer’ die Mitarbeitenden sind, um so belastbarer werden die Ergebnisse.
Wenn das Vorhaben noch nicht gestartet ist: laden Sie so viele Stakeholder ein, wie Sie kriegen können. Gemeinsam erarbeitete Klarheit ist durch nichts aufzuwiegen.
Verstärken Sie die leisen Stimmen, dämpfen Sie die lauten. Nicht hierarchischer Rang und Titel zählen, sondern kohärente Geschichten und überzeugender Nutzen.
Machen sie klar: die Ergebnisse des Story Mapping bestimmen massgeblich den weitere Projektverlauf.
Achten Sie auf Business-Touristen. Touristen sind Stakeholder, die Höflichkeitsbesuche leisten und management attention zeigen. Das brauchen Sie nicht — Sie brauchen aktive und konzentrierte Mitarbeitende.
Wenn möglich, lassen Sie sich von einem/einer Moderatorin unterstützen. Moderation achtet auf die Prozesse in der Veranstaltungen, auf die Zeit und regelmässige Pausen. Wenn Sie noch nie zuvor ein Story Mapping moderiert haben: lassen Sie sich von jemandem behilflich sein, der mit einem zweiten Paar Augen und Ohren unterstützt. Es wird viel geschehen, Debatten werden sich kreuzen und Untergruppen bilden. Eine:r alleine kann das kaum alles mitverfolgen.
Setzen Sie einen ganzen Tag mit acht verbindliche Bruttostunden für den Story Mapping Workshop an. Bei sehr grossen Vorhaben können es zwei Tage sein, so dass am ersten Tag die Sammlung und Analyse und am zweiten die Priorisierung und das Release Planning geschieht.
Sorgen Sie für ausreichend Materialien, Stellwände und Moderationskoffer. Walking the Board wirkt integrierend und involvierend — entlang einer breiten freien Wand alles aufkleben, was in der Analyse an Themen entsteht. Je größer die Wand, die Ihnen zur Verfügung steht, umso besser. Die Wand muss Klebeband und Haftnotizen aushalten.
Den Raum vorbereiten: kommen Sie früh vor Veranstaltungsbeginn oder erledigen Sie die Einrichtung am Tag zuvor. Sie werden am Tag der Veranstaltung nicht viel Zeit für Hausmeistertätigkeiten haben. Das Backbone können Sie vorbereiten. Es spricht nichts dagegen, auch Aktivitäten (die blauen Karten) schon vorzuschreiben. Auch die horizontalen Swimlanes können als Vorgriff auf das Schneiden der Releases grosszügig bemessen bereits an der Wand kleben. Diese Vorbereitung spart Zeit und gliedert das Vorgehen.
Nutzen Sie Timeboxing! Definierte Zeitfenster gliedern Workshops gut und geben den Teilnehmenden Orientierung. Stellen Sie zu Beginn die Agenda vor und lassen Sie die Agenda gut sichtbar im Raum. Mit jedem Arbeitsschritt markieren Sie auf der Agenda, wo sich die Gruppe im laufenden Prozess befindet.
Ein pragmatischer Tipp: den Tag in Viertel gliedern. Je ein halber Vormittag, Mittagspause, ein halber Nachmittag. Das ist als Taktung ausreichend. Nach jedem Viertel eine Pause. Gemeinsam Essen — das geht schneller als eine gesetzte Mittagspause und bietet neuen Raum für noch mehr Gespräche.
Fragen Sie sich und die Teilnehmenden immer wieder aufs Neue:
- Ist alles bedacht, sind alle Nutzungsszenarien, Use Cases erfasst?
- Was machen Benutzer vielleicht noch mit dem System, das bisher unbeachtet blieb oder gar nicht vorgesehen war?
- Edge Cases, Extremfälle bedenken: Kann es Situationen geben, in denen eine Aktion nicht stattfinden kann weil Randbedingungen nicht erfüllt sind?
- Wie gehen grundverschiedenen Personas mit dem System um?
Was für eine:n selbstverständlich ist, kann für andere eine Nutzungshürde sein. - Wie unterscheiden sich die Use Cases der Benutzergruppen?
Was für eine Gruppe unbedingt notwendig ist, kann für andere störend und nutzlos sein. - Was bedeuten Use Cases für die Ausgestaltung von Features?
- Ist alles im ersten Release, so dass dieses als MVP unsere Annahmen validieren kann?
Für die Dokumentation der Ergebnisse ist eine Fotodokumentation der geringste Aufwand. Ob, wann und wie mit neuen Stories umgegangen wird, regelt das Entwicklungsteam.
Das Wichtigste: haben Sie Spass!
Quellen
Adzic, G. (2014). Impact Mapping; Making a big impact with software products and projects (leanpub).
Adzic, G., & Evans, D. (2014). Fifty quick ideas to improve your user stories. Neuri Consulting LLP.
Bruner, J. (1991). The Narrative Construction of Reality. Critical Inquiry, 18(1), 1–21. https://doi.org/10.1086/448619
Domingues, I., Berndtsson, J., & Adzic, G. (8.11.14). Getting the most out of impact mapping. InfoQ.
Patton, J. (2014). User story mapping: Discover the whole story, build the right product (First edition). O’Reilly.
Ries, E. (2011). The lean startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses (1st ed). Crown Business.
Robinson, F. (2001). Minimum Viable Product. https://www.syncdev.com/minimum-viable-product/
Robinson, F. (3.10.2008). SyncDev: How It Works: Minimum Viable Product. Link zu archive.org
Shore, J. (20.3.05). Beyond Story Cards: Agile Requirements Collaboration. Link
Abbildungen
Das Bild der gelben Post-It Hölle stammt aus dem Film Middle School: The Worst Years of My Life (2017)
Die Abbildungen der Mona Lisa stammen aus Jeff Pattons Buch und einer Präsentation 2013 im Rahmen eines Workshop.
Alle weiteren Grafiken sind von Stefan Knecht hergestellt.