Hauptberuflich bin ich Product Owner bei der ING, und das Werkzeug, an dem die Rolle hängt, ist das Product Backlog. Der Scrum Guide beschreibt es als geordnete Liste. Eine Liste kann sagen, was als Nächstes kommt. Was die Einträge miteinander zu tun haben und welche Geschichte sie zusammen erzählen, kann sie nicht sagen. Genau das ist der Punkt, an dem Story Mapping ansetzt.
Im Beitrag über Silos ging es darum, wie die Reise der Nutzenden verloren geht, wenn jedes Team nur seinen Abschnitt sieht. Ein flaches Backlog kann denselben Effekt haben, nur innerhalb eines einzigen Teams.
Warum die Liste den Zusammenhang verliert
Jeff Patton hat das Problem 2008 in einem Blogbeitrag beschrieben, der den Titel trägt, um den es bis heute geht: The New User Story Backlog is a Map. Sein Einwand war schlicht. Stories in der Reihenfolge aufzureihen, in der sie gebaut werden, hilft nicht dabei, anderen zu erklären, was das System eigentlich tut. Das flache Backlog nennt er dort einen Sack voll Mulch ohne Kontext.
Im Alltag zeigt sich das an drei Stellen:
- Vollständigkeit. Ob eine Liste von achtzig Stories alles abdeckt, was jemand zum Erreichen eines Ziels braucht, sieht man ihr nicht an. Die Lücke fällt erst auf, wenn jemand das fertige Produkt benutzt.
- Release-Planung. Bei hundert Einträgen wird jede Story einzeln als „rein“ oder „raus“ bewertet. Dass die drei wichtigsten Stories zusammen noch keinen Weg ergeben, den irgendwer von Anfang bis Ende gehen kann, bleibt unsichtbar.
- Gespräch. Wer neu ins Team kommt, liest ein Backlog wie ein Telefonbuch. Die Geschichte dahinter steckt in den Köpfen der Leute, die schon länger dabei sind.
Was eine Story Map ist
2014 hat Patton das Verfahren in seinem Buch User Story Mapping ausgearbeitet, zusammen mit Peter Economy, erschienen bei O'Reilly. Der Untertitel fasst das Ziel zusammen: die ganze Geschichte entdecken, das richtige Produkt bauen.
Die Map hat zwei Richtungen:
- Horizontal das Rückgrat (im Original Backbone, ein Begriff, den Patton Dan Rawsthorne zuschreibt). Oben stehen die großen Aktivitäten der Nutzenden, darunter die einzelnen Schritte, von links nach rechts in der Reihenfolge, in der man jemandem erzählen würde, wie das Produkt benutzt wird.
- Vertikal die Details. Unter jedem Schritt hängen die Stories, die ihn umsetzen, sortiert nach Notwendigkeit: oben das Unverzichtbare, weiter unten Varianten, Komfort und Sonderfälle.
Releases werden als horizontale Schnitte quer durch die Map gezogen. Patton hat dafür Klebeband auf die Wand geklebt und die Karten in die Bahnen verschoben. Der erste Schnitt ist das Walking Skeleton, ein Begriff von Alistair Cockburn: das kleinste System, das von Anfang bis Ende funktioniert.
Ein Beispiel: ein Abend mit einem Hörbuch
Zur Veranschaulichung eine Map für einen Audio-Player wie CLAUDIO, meine App für Hörbücher, Musik und Podcasts aus der eigenen Sammlung. Ich habe sie für diesen Beitrag gezeichnet, sie ist nicht das Dokument, mit dem die App entstanden ist. Erzählt wird ein Abend: Jemand hört ein Hörbuch aus der eigenen Sammlung, ob als Datei in iCloud Drive oder auf einem Audiobookshelf-Server.
| Sammlung anbinden | Etwas finden | Hören | Später weiterhören |
|---|---|---|---|
| Lokale Datei oder iCloud Drive wählen | Hörbücher als Liste sehen | Abspielen und pausieren | An derselben Stelle einsetzen |
| Server-Adresse eintragen | Suchen und filtern | Kapitel springen | Sleep Timer bis Kapitelende |
| Mehrere Server zusammenführen | Reihen mit Bandnummer | Tempo anpassen | Offline-Cache für unterwegs |
Die Kopfzeile ist das Rückgrat, darunter nimmt die Notwendigkeit von oben nach unten ab. Eine Tabelle ist eine schwache Map, weil sie Aktivitäten und Schritte in eine Zeile presst, aber das Prinzip trägt sie: Die erste Zeile ist für sich schon ein Weg von links nach rechts, und genau das ist das Walking Skeleton.
Eine Map im Team bauen
In groben Zügen und angelehnt an Patton läuft es so:
- Die Geschichte erzählen, nicht die Features aufzählen. Jemand aus dem Team erzählt, was eine Person mit dem Produkt tut, Schritt für Schritt, im Präsens. Jeder Schritt wird eine Karte. Wer Features sagt („Suchfunktion“), wird nach dem Schritt gefragt („findet das Hörbuch von gestern Abend wieder“).
- Das Rückgrat ordnen. Die Schritte kommen in Erzählreihenfolge, verwandte Schritte bekommen eine Aktivität darüber. Das Rückgrat wird nicht priorisiert, es beschreibt den Weg.
- Darunter in die Breite gehen. Für jeden Schritt sammelt das Team Varianten, Fehlerfälle und Alternativen. In dieser Phase ist mehr besser, gestrichen wird später.
- Das Walking Skeleton ziehen. Die erste Linie geht quer durch alle Spalten. Darüber steht nur, was nötig ist, damit eine Person den Weg einmal vollständig gehen kann, auch wenn er an jeder Stelle karg ist.
- Schnitte nach Outcome legen. Jeder weitere Schnitt bekommt einen Satz, der sagt, was die Nutzenden danach können, das sie vorher nicht konnten. Im Beispiel etwa: „Beim Einschlafen hören, ohne den Faden zu verlieren“ (Sleep Timer bis Kapitelende, Weitersetzen an der richtigen Stelle) oder „Unterwegs ohne Netz hören“ (Offline-Cache). Ein Schnitt, der nur „Paket 2“ heißt, ist ein Feature-Bündel und kein Release.
Patton argumentiert im Buch, die Aufgabe sei nicht, mehr Software schneller zu bauen, sondern aus dem, was man baut, möglichst viel Wirkung zu holen. Der Outcome-Satz über jedem Schnitt ist die Stelle, an der diese Haltung auf der Wand steht.
Typische Fehler
- Die Map als einmaliges Artefakt. Sie entsteht in einem Workshop, wird fotografiert und nie wieder angefasst. Danach arbeitet das Team wieder aus der Liste, und die Map veraltet mit jedem Sprint. Eine Map lebt nur, wenn Schnitte verschoben, Karten erledigt und neue Erkenntnisse eingehängt werden.
- Zu fein. Wenn unter dem Rückgrat schon Tickets in Sprintgröße hängen, wird die Map so groß wie das Backlog und genauso unlesbar. Auf der Map reicht es, dass ein Schritt erkennbar ist; zerlegt wird, wenn ein Schnitt dran ist.
- Die Map als Soloarbeit. Eine Map, die die Rolle Product Owner allein an die Wand klebt, ist ein Dokument und kein gemeinsames Verständnis. Pattons Kernpunkt im Buch ist, dass geteilte Dokumente noch kein geteiltes Verständnis erzeugen. Entwicklung, Design und Fachseite gehören an die Wand, weil dort die Fragen entstehen.
- Features statt Nutzerschritte. Ein Rückgrat aus „Login, Bibliothek, Player, Einstellungen“ ist die Navigationsstruktur der App, nicht der Weg der Nutzenden. Damit landet man wieder bei dem, was das Silo-Bild zeigt: Jeder Bereich ist für sich vollständig, der Weg dazwischen fehlt.
Story Map und Discovery
Die Map zeigt nicht nur, was gebaut wird, sondern auch, wo das Team zu wenig weiß. Ein Schritt mit drei Karten voller Fragezeichen ist ein Hinweis, dass dort zuerst mit Nutzenden gesprochen oder ein Prototyp getestet werden muss, bevor sich ein Schnitt lohnt. Ein Schnitt kann deshalb auch ein Lernziel haben: Was muss das Team wissen, bevor es den nächsten Schnitt festlegt? Discovery bekommt damit einen Ort auf derselben Wand wie die Umsetzung, statt in einem eigenen Dokument zu verschwinden.
Story Map und Akzeptanzkriterien
Ron Jeffries hat 2001 die User Story in drei Teile zerlegt: Card, Conversation, Confirmation. Die Karte ist ein Versprechen auf ein Gespräch, die Bestätigung sind die Akzeptanztests, mit denen sich zeigen lässt, dass die Story umgesetzt ist. Die Map liefert die Karten und den Ort, an dem das Gespräch beginnt. Die Akzeptanzkriterien entstehen, wenn ein Schnitt an die Reihe kommt, nicht vorher.
Dabei hilft der Platz auf der Map. Ein Kriterium wie „Der Sleep Timer stoppt am Ende des Kapitels“ ist allein eine Funktionsbeschreibung. Unter dem Schritt „Später weiterhören“ und im Schnitt „Beim Einschlafen hören, ohne den Faden zu verlieren“ wird daraus eine prüfbare Frage: Setzt das Hörbuch am nächsten Abend an der Stelle ein, an der jemand eingeschlafen ist? Der Outcome-Satz des Schnitts ist oft schon die End-to-End-Prüfung, die am Ende stehen sollte.
Story Map und Coding-Agenten
Im Beitrag über Product Owner und KI-Agenten ging es darum, dass ein Agent nur kennt, was aufgeschrieben ist, und den Rest rät. Die Map ist eine gute Quelle für genau den Teil, der in Tickets meist fehlt. Zu welchem Schritt gehört die Story? Welchen Outcome soll der Schnitt erreichen? Was liegt unter der Linie und gehört ausdrücklich nicht dazu? Die Abgrenzung, die ein Team nebenbei weiß, steht auf der Map als Klebeband. Für einen Agenten muss sie in Worte übersetzt werden. Die Map selbst lesen muss er dafür nicht.
Fazit
Ein Backlog beantwortet die Frage, was als Nächstes kommt. Eine Story Map beantwortet die Frage, wozu. Für Product Owner ist das keine zweite Dokumentation neben dem Backlog, sondern die Ansicht, aus der eine gute Reihenfolge erst entsteht: Rückgrat aus Schritten, Schnitte nach Outcome, und die ganze Zeit Leute vor der Wand, die nachfragen.
Quellen
- Jeff Patton: The New User Story Backlog is a Map - flaches Backlog, Rückgrat (Begriff nach Dan Rawsthorne), Walking Skeleton (Begriff nach Alistair Cockburn), Release-Bahnen aus Klebeband (08.10.2008)
- Jeff Patton mit Peter Economy: User Story Mapping: Discover the Whole Story, Build the Right Product - O'Reilly, 2014; Outcome statt Output, geteiltes Verständnis statt geteilter Dokumente
- Jeff Patton & Associates: Story Mapping - Überblick des Autors, die Map als Modell der Reise der Nutzenden durch das Produkt
- Ron Jeffries: Essential XP: Card, Conversation, Confirmation - Akzeptanztests als Bestätigung einer Story (30.08.2001)
- Ken Schwaber und Jeff Sutherland: Der Scrum Guide (November 2020) - Product Backlog als geordnete Liste