User Story Maps sind ein unglaublich wertvolles Hilfsmittel, um kreativ die Unmengen von Ideen und Features für ein Produkt zu erarbeiten und überblicken. Es eignet sich ausgezeichnet, um die eindimensionale Grenzen eines Backlogs zu sprengen und entlang des Prozesses („Flow“) die Stories zu diskutieren und priorisieren. Das i-Tüpfelchen dabei ist, dass die Ziele der beteiligten Benutzerrollen stets mit im Fokus bleiben.
Als Vordenker/Erfinder der Story Map gilt Jeff Patton. Er hat auch ein hervorragendes und kurzweiliges Buch darüber geschrieben (Patton, Jeff; User Story Mapping; O’Reilly Verlag). Das Buch ist alles andere als eine technische Anleitung, wie eine Story Map zu erstellen ist und welcher Notation sie folgt. Er vermittelt vielmehr, wie ein Team (und ihre Stakeholder) mit Hilfe der Story Map ein Produkt benutzerzentriert auf unterschiedlichen Flughöhen entwerfen, designen, diskutieren und priorisieren kann.
Die drei Ebenen
In der Praxis hat sich bewährt, drei unterschiedliche Ebenen zu betrachten. Dies ist aber keineswegs eine ISO-Vorschrift oder ähnliches. Wenn es in einem Kontext Sinn macht, eine oder mehrere der Ebenen zu unterteilen – Just do it.
Die Ebene der User Activity beschreibt die Aktivitäten, welche ein Benutzer mit dem Produkt machen will. Beispielsweise „E-Mail senden“, „Foto posten“ oder „Zinsabrechnung erstellen“. Als Eselsbrücke dient die Vorstellung, dass die Benutzerin nach getaner Aktivität eine Kaffepause machen kann. Jede Aktivität hat eine dazugehörige Benutzerrolle. Wichtig ist, dass durchaus auch ein Drittsystem die Rolle des Benutzers übernehmen kann (analog zu den Aktoren in einem Use Case Diagramm). Diese dürfen natürlich keine Kaffeepause machen:) Zur Identifikation der Rollen eignet sich ein dezidierter Workshop im Team, um möglichst viele am Produkt beteiligte Personen und Systemen zu identifizieren.
Auf der zweiten Ebenen – den User Tasks – wird die Geschichte erzählt. Patton schreibt vom „Backbone“ oder dem „Flow“. Hierhin gehören die einzelnen Schritte, die getan werden müssen, um die Aktivität zu vollenden. Beispiele:
- E-Mail senden: Leere E-Mail öffnen, Empfänger erfassen, Text schreiben, Anhang hinzufügen
- Foto posten: Foto auswählen, Filter anwenden, Kreativ schmücken, absenden
- Zinsabrechnung erstellen: Kontodaten aufbereiten, Zins berechnen, Daten an Outputsystem senden, PDF im Archiv speichern
Die Tasks sollten in der typischen Reihenfolge der Durchführung platziert werden. Oft gibt es dafür mehrere Möglichkeiten. Die Diskussion darüber ist eine weitere wertvolle Quelle, noch unentdeckte Tasks zu identifizieren und das Produkt zu verstehen.
Die dritte Ebene hält die Details zu einem Tasks fest. Viele der Tasks können auf unterschiedliche Art und Weise erledigt werden. Diese Alternativen sind die potentiellen User Stories. Beispiel:
- Empfänger erfassen: Empfänger tippen, Empfänger aus Adressbuch auswählen, Autocomplete vorschlagen, CC Empfänger…
- Foto auswählen: Foto aus Kamera Ordner wählen, Foto hochladen, Foto von OneDrive wählen
- Zins berechnen: Zinssatz finden, Vorzugszins berücksichtigen, Verrechnungssteuer abziehen,….
Kollaboration
Eine User Story Map lebt von der Kollaboration. Die Map wird gemeinsam im Team und mit den Stakeholdern erarbeitet, ergänzt, diskutiert und priorisiert. Hat man eine physische Map im Büro hängen, kann diese beliebig ergänzt werden. Zum Beispiel mit farbigen Klebepunkte für Stories mit Abhängigkeiten, Logo des verantwortlichen Teams oder Symbole für die Komplexität.
Wer bereits mit physischen User Story Maps gearbeitet hat weiss aber auch um deren Schwächen:
- Die Grösse der Map nimmt sehr schnell zu und die Wände sind begrenzt.
- Das Verschieben von Sticky Notes ist – insbesondere zu Beginn, wenn noch nicht alle Activities oder Tasks identifiziert sind – sehr mühsam. Und was macht man mit den Sticky Notes, welche jeweils frühmorgens am Boden herumliegen?
- Irgendwann kommen die Stories ins digitale Issue-Tracking System und das eindimensional Backlog wird zur Diskussionsgrundlage – die Gesamtsicht geht wieder verloren.
- Verteilte Teams kommen nicht in den Genuss dieser wertvollen Technik.
Um diese Schwächen auszumerzen haben wir uns zusammen mit den Kolleginnen und Kollegen von Swarmit auf die Suche nach Tools für digitale Story Maps gemacht und in diesem Beitrag detailliert beschrieben:
How to start?
Um User Story Maps kennenzulernen, eignet sich wunderbar die von Patton in seinem Buch beschriebene Übung zur Morgenroutine. Sie können die Übung hier nachlesen oder direkt in unserem Kurs „How to User Story“ erleben.
Um einen Überblick zu erhalten sind die Quick Reference Guides und Präsentationen von Patton – als Ergänzung zum Buch – sehr empfehlenswert.
Können wir Sie bei der Durchführung der Morgenrouting-Übung oder beim Erstellen einer Story Map für ein neues oder bestehendes Produkt unterstützen? Gerne helfen wir beim Kennenlernen und Anwenden der User Story Map. Kontaktieren Sie uns für ein unverbindliches Beratungsgespräch, oder informieren Sie sich über unser Trainingsangebot:
Los geht’s!
Der herausragendste Vorteil der Story Map sind die zwei Dimensionen. Während der Flow die Geschichte über die zu erledigenden Aufgaben erzählt, tauchen die drei Ebenen immer weiter ins Detail. Dank diesen Konzepten bleibt in der Diskussion immer die Gesamtsicht gewahrt und man kann flexibel zwischen den Ebenen wechseln. Dadurch eignet sich eine Story Map für fast alle Arten von Software-Produkten – manchmal braucht es allerdings ein bisschen Fantasie für die Benutzerrollen, Activities und Tasks (Tipp: wählen Sie Benutzerrollen, die möglichst direkt mit ihrem Produkt interagieren. Wenn ihr System Datenlieferant für ein System X ist und der ‚richtige‘ Benutzer mit System X arbeitet, ist für Sie die Benutzerrolle „System X“ wahrscheinlich besser geeignet).
Beispiel: Story Map für den Kurs „How to User Story“
Es mag den Eindruck erwecken, dass Story Maps nur für Neuentwicklungen geeignet sind. Sie bietet aber auch einen wunderbaren Rahmen, um einen Gesamtüberblick über bestehende System (zurück) zu erlangen oder zu dokumentieren. Durch das Nachdenken, welche Aufgaben mit dem System erledigt werden und welche Funktionen dabei unterstützen erhält man einerseits den Kontext zurück (falls dieser verloren ging, oder nur noch in den Köpfen einiger auserwählten Personen ist) und hat andererseits ein Werkzeug in der Hand, neue nutzenstiftende Features zu identifizieren.
Probieren Sie es aus. Wenn Sie mögen, können Sie Ihre Erfahrungen mit Story Maps in den Kommentaren gerne teilen.
Viel Erfolg!
Ihr Benjamin Wyss
