Story Mapping
Das Story Mapping ordnet die Stories einer Lösung auf einem zweidimensionalen Raster an. Die oberste Zeile trägt von links nach rechts die Themen oder Aktivitäten auf dem Weg des Kunden, in der Reihenfolge, in der er sie durchläuft; unter jedem Thema stapeln sich die Stories, die es umsetzen, nach abnehmender Priorität. Die Agile Extension to the BABOK Guide gibt der Technik drei Zwecke: die Funktionalität eines Produkts zu verstehen, den Ablauf der Nutzung zu verstehen und die Lieferung zu priorisieren. Die Karte ist dafür gemacht, aufgehängt zu bleiben: Das Team liest an ihr ab, was die Lösung von Anfang bis Ende tut, was ins nächste Release geht und was wartet.
Ziel
Die Technik erzeugt eine Karte, ein Raster, dessen waagrechte Dimension die Abfolge und die Gruppierung der grossen Schritte des Produkts trägt und dessen senkrechte Dimension das Detail und die Priorität der Stories trägt. Sie stützt einen Entscheid: den Zuschnitt der Releases, den die Release-Linie quer über die Karte zieht. Die Agile Extension to the BABOK Guide sieht darin ein Mittel, das Bedürfnis zu verstehen und die Analyse zugleich auf die höchstpriorisierten Elemente zu richten.
Das Lieferteam hat die Karte während der Sitzungen zur Release-Planung vor sich. Ihre Lektüre macht die Abhängigkeiten sichtbar, die der vorgesehene Ablauf der Nutzung erzeugt: Eine Story, die eine andere vor sich geliefert voraussetzt, erkennt man an der Lage der beiden in der obersten Zeile. Die Karte dient auch der Risikobeurteilung, denn sie zeigt, wie die Stories zusammenwirken müssen, um Geschäftswert zu liefern.
Die auf das Raster gelegten Karten sind bereits erfasste Stories: Die Technik ordnet sie und bringt die fehlenden zum Vorschein; sie teilt keine zu grosse Story auf. Das Format einer Story und ihre Qualitätskriterien finden Sie bei den User Stories. §7.20.2 der Agile Extension bezeichnet das Story Mapping als Technik der Zerlegung, in dem Sinn, dass die Lektüre von der Gesamtsicht zu den detaillierten Stories hinabsteigt; das Aufteilen einer Story, die zum Schätzen oder zum Liefern zu gross ist, gehört zur Story-Zerlegung, behandelt in §7.18. §7.20.3.4 bringt die beiden Tätigkeiten in eine Reihenfolge: Die Sitzung zur Kartierung priorisiert die vorliegenden Stories und bestimmt jene, die in die Ausarbeitung oder in die Zerlegung gehen.
Tabelle 7.0.1 der Agile Extension ordnet die Technik jenen des Anforderungsmanagements zu, auf der Seite der internen Teams.
Einsatz
Wann einsetzen
- Release-Planung: entscheiden, was ins nächste Release geht und in welcher Reihenfolge.
- Verlorene Gesamtsicht: Der Rang einer Story in einem flachen Backlog sagt nicht mehr, an welcher Stelle im Ablauf des Kunden sie dient; die Karte stellt die Gesamtsicht während der Lieferung wieder her.
- Vermutete funktionale Lücken: Das Abschreiten der obersten Zeile bringt die fehlenden Stories zum Vorschein.
- Mehrere abzuwägende Zielgruppen: Die Karte zeigt, welchen Personas das jeweilige Release nützt.
- Zu prüfende Abfolge: Der vorgesehene Ablauf zeigt, welche Stories anderen vorausgehen müssen.
- Zu verstehender Weg eines Datenelements: Die Karte verfolgt ein Datenelement durch das System.
Wann nicht einsetzen
- Eine einzelne, zu grosse Story: Das Raster ordnet bestehende Stories, zur Story-Zerlegung greifen.
- Kontext ohne Nutzungsablauf: nichts, was sich auf der waagrechten Achse anordnen liesse, das Backlog mit einer Technik der Priorisierung ordnen.
Beschreibung
Die beiden Achsen
Eine Karte liest sich in zwei Richtungen, die zwei Fragen beantworten: von links nach rechts, was die Lösung von Anfang bis Ende tut; von oben nach unten, in welcher Reihenfolge die Teile eintreffen. Die Themen der obersten Zeile stehen in der linearen Reihenfolge, in der ein Kunde sie durchläuft, und decken sämtliche bekannten Personas ab. Unter einem Thema belegt die Story mit der höchsten Priorität den Kopf des Stapels, die weiteren folgen darunter.
Die drei Strukturelemente
| Element | Was es trägt | Worüber es entscheiden lässt |
|---|---|---|
| Themen oder Aktivitäten | Die oberste Zeile: alle bekannten Themen oder Aktivitäten, als linearer Ablauf. Der Guide nennt die Nutzung eines Bancomaten, vom Aktivieren des Geräts bis zur Wahl zwischen einer weiteren Transaktion und dem Verlassen. | Den Umfang der Nutzung und die Stelle im Ablauf, an der jede Story steht. |
| Stories oder Funktionalitäten | Unter jedem Thema alle bekannten Funktionalitäten, die dazugehören. Eine Story dient einer Persona oder mehreren. | Was noch zu bauen ist, damit ein Thema erfüllt ist. |
| Prioritätsreihenfolge | Der Stapel von oben nach unten unter jedem Thema. Der Rang stellt jene Stories an die Spitze, die den zahlreichsten und am höchsten eingestuften Personas dienen, sowie jene, deren Lieferung die nachfolgenden Funktionalitäten bedingt. | Die Aufteilung der Funktionalitäten auf die Releases. |
Die Karte bauen
- Themen und Stories vor der Sitzung vorbereiten
Der Guide verlangt es, damit die Gruppe ihre Zeit mit dem Priorisieren und dem Verstehen des Ablaufs beim Kunden verbringt statt mit dem Entdecken des Materials. - Die oberste Zeile legen
Ein Thema ohne Story deutet auf eine Lücke im Backlog oder auf ein Thema ausserhalb des Ablaufs hin. - Die Stories unter ihr Thema hängen
Jede Story kommt zu dem Thema, das sie umsetzt. Eine Story, die zwei Themen findet, ist meistens zwei Stories. - Nach Priorität stapeln
Die Reihenfolge wird Spalte für Spalte besprochen und danach von Spalte zu Spalte verglichen. - Die Release-Linie ziehen
Sie trennt, was ausgeliefert wird, von dem, was wartet. Patton legt sie quer über die ganze Karte, damit das erste Release einen Weg ergibt, den ein Kunde von Anfang bis Ende gehen kann. - Die Karte von Anfang bis Ende nachlesen
Was zu gross geblieben ist, geht in die Zerlegung, was der Lieferung nahekommt, geht in die Ausarbeitung.
Die Sitzung führen
Die Technik kommt ohne eigene Moderation aus. Sie wird meist in der Gruppe geübt, an der Wand oder am Board. Der Product Owner entscheidet, wenn eine Abwägung stockt. Diese Ersparnis beruht auf der Vorbereitung: Wenn Themen und Stories auf bereits beschriebenen Karten in die Sitzung kommen, dreht sich die Diskussion um ihren Platz, der sich durch das Verschieben einer Karte klärt.
Was eine Karte scheitern lässt
Die in Bildschirmen geschriebene oberste Zeile
Wenn die Themen die Module der Anwendung übernehmen, trägt die waagrechte Zeile keinen Ablauf mehr und die Karte wird wieder zu einem Backlog in Spalten. Der Test: die oberste Zeile laut lesen; sie muss sagen, was ein Kunde tut, in der Reihenfolge, in der er es tut. "Eingabemaske, Freigabemaske, Reporting-Modul" besteht diesen Test nicht.
Die Release-Linie, die einer Spalte entlang nach unten läuft
Ein ganzes Thema zu liefern, bevor die anderen angegangen werden, ergibt eine Lösung, die kein Kunde durchlaufen kann. Ein Release, das nur eine Spalte belegt, erkennt man auf der Karte auf einen Blick.
Die für eine Abhängigkeitsanalyse gehaltene Karte
Der Guide nennt die Grenze: Eine Karte zeigt einen Ablauf, ohne die Abhängigkeiten zwischen Anforderungen zu analysieren oder zu zeichnen. Sie erleichtert diese Analyse, indem sie die vorgesehene Abfolge zeigt; die Analyse bleibt eine eigene Arbeit, die an den Anforderungen geleistet wird.
Die für eine Wand zu grosse Karte
Bei einer weitreichenden Lösung wird eine einzige Karte unbeherrschbar, und der Guide sieht mehrere Karten vor, die ein Arbeitsprogramm abdecken. Die Aufteilung erfolgt nach Produkt oder nach Nutzungsbereich, mit einem ausdrücklichen Anschlusspunkt dort, wo ein Ablauf von einer Karte in die nächste übergeht.
KI-Überlegungen
Ein Sprachmodell verkürzt die Vorbereitung. Aus einem dokumentierten Prozess oder aus Gesprächsnotizen schlägt es eine erste Zeile von Themen in der Reihenfolge des Ablaufs vor, die das Team vor der Sitzung korrigiert. Aus einem flachen Backlog gruppiert es die Stories unter Themenkandidaten und meldet jene, die kein Thema aufnimmt, oft der erste Hinweis auf eine Lücke im Ablauf. Es formuliert die fehlenden Stories, die das Nachlesen zutage fördert.
Die senkrechte Reihenfolge entzieht sich dem Modell. Sie entscheidet sich an Erträgen, vertraglichen Fristen und regulatorischen Pflichten, die das Modell nicht kennt, und die Release-Linie verpflichtet das Team gegenüber Stakeholdern. Eine in einem Zug erzeugte und unverändert aufgehängte Karte nimmt der Sitzung ihren Zweck: Der Guide beschreibt eine Tätigkeit der Gruppe, bei der das Gespräch über den Weg des Kunden ebenso viel wert ist wie das erhaltene Raster.
Was ins Modell geht, ist ein Export des Backlogs, in dem die Stories einer Bankanwendung Daten realer Kunden als Beispiel anführen. Er geht nicht in einen öffentlich zugänglichen Dienst, solange die Nutzung nicht im Sinne des Datenschutzgesetzes (DSG) abgedeckt ist.
Beispiele
Eine Schweizer Retailbank kartiert die Zahlung von QR-Rechnungen in ihrer E-Banking-Anwendung. Die oberste Zeile folgt dem Weg des Kunden: sich anmelden, die QR-Rechnung scannen, Betrag und Fälligkeit prüfen, die Zahlung bestätigen, die Bestätigung wiederfinden.
Die Release-Linie durchquert die fünf Spalten. Das erste Release nimmt die oberste Story jedes Themas, was einen Kunden ergibt, der eine QR-Rechnung von Anfang bis Ende bezahlen kann: Sitzung öffnen, den Code mit der Kamera lesen, den gescannten Betrag gegen die Papierrechnung prüfen, mit dem zweiten Faktor bestätigen, Quittung als PDF. Sieben Karten bleiben unter der Linie und verbessern diesen Ablauf, ohne ihn zu bedingen. Vier davon verteilen sich auf je eine Spalte: die auf einem vertrauenswürdigen Gerät gehaltene Sitzung, die Eingabe der Referenznummer von Hand, wenn die Kamera versagt, die auf die Fälligkeit datierte Zahlung, die Suche im Verlauf. Die drei übrigen fallen unter "Betrag und Fälligkeit prüfen", das damit vier Karten zählt und zur höchsten Spalte wird: ein offen gelassener Betrag, den der Kunde ergänzt, eine im Vormonat bereits bezahlte Rechnung, eine Ablehnung über der Tageslimite von CHF 5'000.
Visualisierungen
Die Zeichnung trägt drei Informationen, die eine geordnete Liste nicht trägt. Der Pfeil zuoberst gibt die Reihenfolge des Ablaufs, sodass ein falsch gesetztes Thema auffällt. Die Release-Linie zeigt, ob das Release quer durch alle Spalten schneidet. Die ungleiche Höhe der Stapel zeigt, wo sich die Sonderfälle häufen.
Diese letzte Lesart dient der Schätzung. Ein hoher Stapel ist ein Thema, das bis zu seinen Ausnahmen besprochen wurde; ein niedriger Stapel sagt entweder, dass das Thema einfach ist, oder dass es noch niemand geöffnet hat. Der zweite Fall wird in der Iteration bezahlt, wenn die nicht geschriebenen Ausnahmen eintreffen.
Aufwand
| Phase | Stufe | Begründung |
|---|---|---|
| Vorbereitung | Mittel | Themen und Stories werden vor der Sitzung geschrieben; die Wand oder das gemeinsame Board wird im Voraus reserviert und die Gruppe muss versammelt sein. |
| Durchführung | Mittel | Eine Sitzung von zwei bis drei Stunden legt die Karte eines Produkts, ohne eigene Moderation, aber mit der vollständigen Liefergruppe. |
| Dokumentation | Mittel | Die Karte wird ins Backlog-Werkzeug übertragen und bei jeder Änderung der Priorität nachgeführt: Karte und Backlog laufen ab der ersten nicht übertragenen Neupriorisierung auseinander. |
Werkzeuge
Die Wand und die Haftnotizen sind die ursprüngliche Form und bleiben die beste für den ersten Durchgang: Die Karte lässt sich mit mehreren Händen bewegen, sie bleibt vor dem Team hängen und niemand wartet, bis er an die Tastatur kommt. Sie verlangt ein an einem Ort versammeltes Team und eine genügend breite Wand.
Das Online-Whiteboard (Miro, Mural) trägt dieselbe Handhabung für ein verteiltes Team, und die Karte überlebt die Sitzung in einer Form, die jede und jeder wiederfindet. Die Gesamtsicht ist dort ärmer als an der Wand, denn ein Bildschirm zeigt selten fünf gefüllte Spalten ohne Zoom.
Die ans Backlog angeschlossenen Werkzeuge für das Story Mapping (Easy Agile für Jira, StoriesOnBoard, Avion) halten Karte und Backlog auf demselben Datenbestand. Was sich auf der Karte verschiebt, verschiebt sich im Backlog, was die Nacherfassung nach der Sitzung und das Auseinanderlaufen der beiden Sichten beseitigt.
Das Backlog-Werkzeug allein leistet den geringsten Dienst. Eine geordnete Liste hat keine waagrechte Achse; ein Feld "Thema" auf jeder Story und eine Sortierung stellen eine Lesart nach Spalten her. Verloren geht der Gesamtblick auf den Ablauf.
Quellen
- IIBA, Agile Extension to the BABOK Guide, §7.20 Story Mapping: der Zweck der Technik, das zweidimensionale Raster, die Elemente (Themen oder Aktivitäten, Stories oder Funktionalitäten, Prioritätsreihenfolge) und die Moderation, die während der Release-Planung aufgehängte Karte, die Lektüre der Abhängigkeiten und die Risikobeurteilung sowie die genannten Grenzen, darunter das Fehlen einer Analyse der Abhängigkeiten zwischen Anforderungen, die Grösse, ab der mehrere Karten nötig werden, und die Kontexte, die nicht prozessorientiert sind.
- IIBA, Agile Extension to the BABOK Guide, §7.0, Tabelle 7.0.1 Selecting the Right Technique: die Technik, jenen des Anforderungsmanagements zugeordnet, auf der Seite der internen Teams.
- Jeff Patton, It's All in How You Slice It, Better Software, Januar 2005, S. 16: der ursprüngliche Artikel, der vorschlägt, eine Lieferung in Scheiben zu schneiden, die den ganzen Ablauf durchqueren.
- Jeff Patton, The New User Story Backlog is a Map, 2008: der Artikel, in dem Patton die Praktik benennt und die oberste Zeile als Rückgrat des Produkts beschreibt, von links nach rechts gelesen.
- Jeff Patton mit Peter Economy, User Story Mapping: Discover the Whole Story, Build the Right Product, O'Reilly Media, 2014, ISBN 978-1-4919-0490-9: die vollständige Behandlung, darunter die minimale Scheibe, die den ganzen Ablauf durchquert, die Patton von Alistair Cockburn unter dem Namen walking skeleton übernimmt.