Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03414.jsonl.gz/1045

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.
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:
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:
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:
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:
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:
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
Sie möchten unsere Expertise nutzen und technologische Innovationen umsetzen?
Haben Sie eine Frage oder suchen Sie weitere Informationen? Geben Sie Ihre Kontaktinformationen an und wir rufen Sie zurück.