Von der Journey zur Story Map

Teil sechs der Werkzeugkiste des Product Owners. Für das Ferientool haben wir ein Epic und eine User Journey. Jetzt verbinden wir die beiden.

Features

Ein Feature ist eine Funktionalität oder ein Teil einer User Journey, aus der Sicht einer bestimmten Nutzergruppe. Es liefert einen Wert, der die Bedürfnisse dieser Gruppe erfüllt. Ein Feature wird über mehrere User Stories umgesetzt, die aus Sicht der Nutzer zusammengehören. Es dauert länger als einen Sprint und passt in ein Release.

Features entstehen meistens in Zusammenarbeit von Product Manager, Product Owner und weiteren wichtigen Stakeholdern. Ich beschreibe sie auf einer Karte mit sechs Feldern:

Feld	Inhalt
Titel	Der Name des Features
Nutzenhypothese	Der messbare Wert für Nutzer oder Geschäft
Messgrössen	Woran wir es erkennen
Akzeptanzkriterien	Was funktionieren muss
Business Value	Warum es wichtig ist
Nicht im Umfang	Was dieses Feature ausdrücklich nicht enthält

Features und User Stories sind sich ähnlich, weil beide ein Nutzerbedürfnis beschreiben. Ein Feature ist grösser und abstrakter und wird in mehrere Stories aufgeteilt. Schreib ein Feature nicht im Story-Format («Als Teamleiterin will ich…»). Sonst lassen sich Features und Stories nicht mehr auseinanderhalten, weder im Backlog noch im Gespräch.

Das Feature «Teamkalender» des Ferientools:

• Nutzenhypothese: Teamleitende sehen Konflikte, bevor sie bewilligen, und unterbesetzte Wochen im August fallen auf null.
• Messgrössen: Anzahl Schichten unter der Mindestbesetzung im Juli und August, verglichen mit dem Vorjahr.
• Akzeptanzkriterien: Eine Teamleiterin sieht alle bewilligten und offenen Abwesenheiten ihres Teams für jeden Monat. Wochen unter dem Minimum sind markiert.
• Business Value: Keine kurzfristigen Temporärkräfte im Lager.
• Nicht im Umfang: Feiertage pro Kanton. Abwesenheiten anderer Teams.

Die Zeile «Nicht im Umfang» ist die nützlichste. Dort beginnt die nächste Diskussion, und sie steht schon da, bevor diese Diskussion stattfindet.

Story Maps

Ein flacher Backlog ist eine Liste, und eine Liste zeigt schlecht, wie ihre Einträge zusammenhängen. Die Story Map von Jeff Patton legt den Backlog in zwei Dimensionen aus.

• Horizontal liegt das Rückgrat (Backbone): der Ablauf des Nutzers von links nach rechts. Das kann ein Prozess sein, eine Reihe von Tätigkeiten, ein Workflow oder, wie hier, eine User Journey.
• Vertikal, unter jedem Schritt des Rückgrats, stehen die Stories zu diesem Schritt, nach Priorität sortiert, die wichtigste zuoberst.
• Horizontale Linien schneiden quer durch die Karte und teilen sie in Releases.

Die Karte gibt allen ein gemeinsames Bild des Produkts, was besonders nützt, wenn man einen ersten Backlog sammelt. Sie zeigt auch zwei Dinge, die eine Liste versteckt: Lücken (ein Schritt ohne Stories darunter) und Abhängigkeiten (eine Story, die nicht funktioniert, bevor es einen anderen Schritt gibt).

Eine Story Map entsteht in vier Schritten:

1. Das Rückgrat festlegen.
2. Die Stories für jeden Schritt des Rückgrats schreiben, mit Card, Conversation und Confirmation (mehr dazu im nächsten Text).
3. Die Stories in jeder Spalte priorisieren.
4. Die Release-Linien ziehen.

Eine gute Story Map hängt von zwei Dingen ab: einem Rückgrat, das zeigt, wie sich der Nutzer wirklich bewegt, und klaren Kriterien für die Priorität. Priorisier nach dem Wert für den Nutzer, wo immer es geht.

Die Story Map des Ferientools

Das Rückgrat ist die Journey aus dem letzten Text:

	Guthaben prüfen	Team prüfen	Beantragen	Bewilligen	Entscheid erhalten
Release 1	Verbleibende Tage anzeigen	Teamkalender, nur bewilligte	Ganze Tage, nur Ferien	Per Link bewilligen oder ablehnen	E-Mail mit Entscheid
Release 2	Geplant vs. bezogen	Offene Anträge, unterbesetzte Wochen markieren	Halbe Tage	In der App bewilligen, mit Begründung	Abwesenheit im persönlichen Kalender
Release 3	Übertrag aus dem Vorjahr	Feiertage pro Kanton	Weitere Abwesenheitsarten	Bewilligung bei Abwesenheit delegieren	Benachrichtigung im Chat

Release 1 ist dünn, geht aber ganz durch. Ein Mitarbeiter kann die ganze Journey von Anfang bis Ende durchlaufen. Darum geht es bei der Karte: Jedes Release ist von Anfang bis Ende nutzbar, statt eines perfekten Antragsformulars, hinter dem nichts kommt.

Die Karte zeigt auch eine Lücke: Niemand hatte eine Story zum Stornieren eines Antrags geschrieben. Sie passt in keine Spalte der Journey, weil die Journey nur den Happy Path abdeckt. Sie kommt in Release 1, weil sonst die erste stornierte Ferienwoche wieder als E-Mail bei HR landet.

Release-Linien brauchen Zahlen

Wo die Linien liegen, hängt davon ab, was das Team tatsächlich liefern kann. Nimm die gemessene Kapazität aus früheren Releases, nicht die Kapazität, die der Plan gern hätte. Eine Release-Linie ohne Zahlen ist ein Wunsch.

Als Nächstes

Die Karte besteht aus User Stories. Nächstes Mal: was eine Story wirklich ist und warum sie keine Anforderung ist.