User Story Mapping

User Story Mapping Definition

Mit steigender Anzahl von Einträgen werden Backlogs leicht unübersichtlich. Hier bietet die Visualisierung mit User Story Maps Abhilfe, denn mit ihnen lassen sich Zusammenhänge darstellen, die beim Arbeiten mit eindimensionalen Backlogs leicht übersehen werden. Die User Story Map ist eine Art Landkarte, mit der einerseits die Reihenfolge der Verwendung des Systems durch einen Anwender, und andererseits die Zuordnung von User Storys zu den übergeordneten Wünschen der Anwender (also zu den Epics oder Features) visualisiert wird.

Mit dem Story Mapping gelingt es Ihnen leichter, ein Product Backlog zu erstellen. Durch den visuellen, strukturierten Aufbau ist es möglich,

• ein gemeinsames Verständnis zu schaffen,
• Lücken im Backlog zu identifizieren
• und Abhängigkeiten zu erkennen.

Zusätzlich kann es auch bei der Aufteilung und Freigabe von Planungsaktivitäten helfen.

Erläuterungen:

Im Gegensatz zu einem flachen Product Backlog bietet eine User Story Map eine zweidimensionale Karte, durch die sich Zusammenhänge bei der Entwicklung einfacher nachvollziehen lassen.

Die horizontale Anordnung der High-Level-Anforderungen (Epics, Themes oder Features) folgt dem Ablauf der Systemverwendung durch den Anwender. Einfach ausgedrückt nutzt der Anwender zuerst Feature 1, dann Feature 2 usw. Diese Anordnung wird als Backbone bezeichnet.

Aus der User Story Map lässt sich auch eine Priorisierung ablesen. Je höher eine User Story angeordnet wird, desto wichtiger ist sie.

Wann werden welche User Storys umgesetzt? Diese Information können Sie durch die Zuordnung zu Sprints erkennen.

Arten von User Story Mappings

Es gibt verschiedene Arten von Mappings mit verschiedenen Formen der Anordnung. So können Sie bspw. Produktvisionen und Ziele, notwendige Maßnahmen, abgeleitete Aufgaben und User Storys visualisieren. Oder Sie stellen Epics, Features, User Storys und Tasks in einer gemeinsamen Visualisierung dar. Auch die Visualisierung von nicht-funktionale Anforderungen, funktionalen Anforderungen und User Storys findet sich in Unternehmen. Wollen Sie Anforderungen aus einer Anwenderperspektive identifizieren, bspw. aus Sicht eines Kunden, eines Mitarbeiters, eines Partners etc., würde sich eine Visualisierung mit Anwender, Zielen, Workflow, Aktionen und User Storys anbieten.

Ob die verwendete Visualisierung der Items top-down, also von oben nach unten, oder von links nach rechts erfolgt, ist für die Anwendung unwesentlich. Wichtig ist, dass Sie für Ihre Entwicklung Abstraktionsebenen finden, mit denen die Beteiligten Anforderungen besser identifizieren und vorhandene Zusammenhänge leichter verstehen können.

Der iterative Prozess beim User Story Mapping

Das Arbeiten mit Story Maps bietet einen Rahmen für Gespräche zwischen Teams, Teammitgliedern und Stakeholdern. Wie das eigentliche Produkt entwickelt sie sich immer weiter. Sie ist stets eine Momentaufnahme der Gedanken des Teams. Werden in den Gesprächen neue Erkenntnisse gewonnen, Annahmen bestätigt oder widerlegt, ändert sich die Story Map entsprechend.

User Story Mapping beginnt mit der Entscheidung, welches Medium für den Aufbau der Story Map verwendet werden soll. Es kann mit einfachen physischen Ressourcen – wie einer Wand oder einem Whiteboard und Haftnotizen – oder mit einer Vielzahl von Softwaretools durchgeführt werden, die beim Erstellen einer virtuellen Karte für verteilte Teams helfen. Unabhängig vom Medium besteht das Story Mapping aus folgenden Aufgaben:

• Definition der Zielgruppe(n)
• Definition der Ziele der Stakeholder
• Visualisierung des Backbones – also des roten Fadens (des Workflows oder der Geschichte) – der Anwender
• Erstellung und Zuordnung von User Storys zu den Highlight-Anforderungen der Anwender
• Priorisierung der User Storys
• Identifikation von Abhängigkeiten, technischen Anforderungen und Lücken
• Verwendung von Technical Storys und Spike Storys zum Finden von Alternativen und zur Beseitigung von Unklarheiten
• Die Planung von Sprints, Release und Abnahmen

Die Erfahrung zeigt, dass auch zu Beginn getroffene Annahmen regelmäßig überprüft werden sollten. Ziele von Anwendern können sich ebenso ändern, wie die Priorisierung von User Storys oder die technische Möglichkeiten von verwendeten Architekturen.

Die Zusammenarbeit im Team

User Story Mapping ist ein kollaborativer Ansatz, mit dem funktionsübergreifende Teams Produkte und Systeme entwickeln können. Es macht daher Sinn, dass Vertreter aus den Teams an dem Mapping teilnehmen, die zur Realisierung des Kundenwerts beitragen. Dies können Vertreter aus den Bereichen

• Entwicklung und Architektur
• IT und Operations
• Produktmanagement
• Projektmanagement
• UX Design und Entwurf
• Vertrieb und Marketing
• Finanzen und Recht

sein. Zusätzlich ist die regelmäßige Kommunikation mit Stakeholdern stets zu empfehlen.

Vorteile beim User Story Mapping

Es gibt verschiedene Vorteile beim Arbeiten mit User Story Maps:

• Items, die in einem haptischen Format erfasst werden, fördern das gemeinsame Verständnis und die Zusammenarbeit im Team.
• Der Backbone zeigt die Highlights der Kundenanforderungen; er ist quasi ein roter Faden und bietet eine gute Orientierung bei der Realisierung der Anforderungen.
• Die Visualisierung vermittelt einen guten Überblick über den Umfang der Anforderungen und Aufgaben. Es wird daher auch als Tool für das sogenannte Big Picture bezeichnet.
• Die Priorisierung wird erleichtert, denn Items lassen sich leicht verschieben. Gleichzeitig bleibt der Zusammenhang zu den Kundenanforderungen erhalten. Somit ist das User Story Mapping auch ein gutes Hilfsmittel bei einer Release Planung.
• Das Mapping ermöglicht die Aufteilung von größeren Items in mehrere kleinere, wobei die Abhängigkeiten untereinander stets nachvollziehbar bleiben.
• Abhängigkeiten lassen sich gut darstellen, so dass besondere Herausforderungen oder Risiken frühzeitig erkannt werden können.
• Das Arbeiten mit User Story Maps macht Spaß und fördert den Dialog im Team, zumal es auch ein Werkzeug für Teams ist.

Manchmal wird Kritik am User Story Mapping geäußert, da die Methode nicht den Austausch mit Kunden fördert. Die Kritik verfehlt allerdings den Kern des Vorgehens, denn primär ist es ein Werkzeug für Entwicklungsteams und nicht für die Kommunikation mit Kunden. Davon unbenommen kann der Product Owner regelmäßig mit den Stakeholdern kommunizieren und je nach Situation und Bedarf die gewonnenen Erkenntnisse vermitteln. Ähnliches gilt auch den “Nachteil”, dass sich Einzelpersonen ggf. schwer mit dem Erstellen einer Story Map tun, da sie selten alle produkt- und entwicklungsrelevante Aspekte kennen. Genau: es ist ein Werkzeug für Teams.

Tipps für User Story Mapping

Es gibt Situationen, in denen es Sinn macht, zusätzliche Informationen in einer Story Map zu erfassen. Dies könnten Technical Storys oder Spike Storys sein, Verbindungen zu Personas oder auch einfache “Nice-to-have” User Storys. Richtig ist, was Ihnen in Ihrer Situation hilft. Hier finden Sie einige Möglichkeiten:

• Verwenden Sie verschiedene Farben, um unterschiedliche Ebenen in der Story-Map darzustellen, bspw. orange für Ziele, blau für Epics, grün für Features und Gelb für Storys.
• Verwenden Sie Fäden oder Kreppband, um Zusammenhänge hervorzuheben.
• Nutzen Sie Aufkleber (Sticker) für zusätzliche Informationen, Follow-ups, Notizen oder Fragen.
• Verlinken Sie zusätzliche Informationen (Zeichnungen, Grafiken, Dokumente), um das gemeinsame Verständnis zu erhöhen.
• Bauen Sie Alternativen ein, um technisch robustere oder kostengünstigere Lösungen zu evaluieren.

Kritische Punkte und weitere Tipps

User Story Mapping ist ein sehr gutes Werkzeug für agile Teams. Es kann als Werkzeug aber auch Probleme verursachen, wenn es nicht zu Ihrer Unternehmenskultur passt oder Ihre Teams auf eine solche Zusammenarbeit schlecht vorbereitet sind. Hier finden Sie einige Herausforderungen, auf die Sie achten sollten:

• Wer ist Ihr Anwender und welche Ziele verfolgt er?
  Wenn Sie nicht wissen, wer die Anwender Ihrer Lösung sind, ist es unmöglich herauszufinden, wie sie das Produkt erleben und nutzen werden.
• Was ist die zu lösende Aufgabenstellung?
  Wenn Sie nicht wissen, welches Problem Ihr Produkt für Kunden löst, kann die gesamte User Story Zuordnung leicht scheitern. User Storys auf ein falsches Kundenziel auszurichten, kann zu einer Verschwendung von Zeit und Ressourcen führen – nicht nur im Mapping, sondern auch später bei der Realisierung in den Sprints und Releases, die darauf basieren.
• Wie erfolgt die Aktualisierung Ihrer Story Map?
  Physische Story Maps, die aus Haftnotizen an einer Wand oder einem Whiteboard bestehen, sind schwer zu aktualisieren. Die Notizen fallen herunter, Whiteboards werden gereinigt und die Arbeit geht verloren. Es passiert auch, dass Releases ohne ein Updaten der Story Map ausgeliefert werden, d. h. Planung und Realität laufen auseinander.
• Wie gewährleisten Sie den Zugang zur Story Map?
  User Story Maps, die an einem einzigen physischen Standort erstellt wurden, stehen häufig Teams an anderen Standorten nicht zur Verfügung. Und auch bei der Verwendung an einem Standort mit mehreren Teams muss der Zugang zu den Informationen stets gewährleistet sein.
• Wie vermeiden Sie Nacharbeiten und Redundanzen?
  Erkenntnisse aus dem Arbeiten mit einer User Story Map müssen oft anschließend in einem Product Backlog neu erstellt oder überarbeitet werden. So kann sich das Gefühl einstellen, dass dieselbe Arbeit zweimal durchgeführt wird.

User Story Mapping Tools

Oftmals stehen Organisationen vor der Frage, welches Tool sie für das User Story Mapping einsetzen können. Sofern die Möglichkeit besteht, dass alle Teilnehmenden an einem Ort zusammen kommen, gilt allgemein das Whiteboard in Verbindung mit Post It’s als die beste Lösung. Doch was tun, wenn digitale Lösungen benötigt werden, da die Teilnehmenden verteilt und remote arbeiten? Hier finden Sie einige Tools, allerdings ohne Wertung und auch ohne Anspruch auf Vollständigkeit:

• aha
• Avion
• Cardboard
• craft
• delibr
• draft
• Miro
• Mural
• ScrumDesk
• StoriesOnBoard
• Trello
• upwave
• Visual Paradigm

Hinweise:

Haben Sie Lust auf einen neuen Lieblings-Newsletter?

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie Anmerkungen haben, schicken Sie uns bitte eine Nachricht.

Im aktuellen Scrum Guide 2020 wird User Story Mapping nicht erwähnt. Dies ist aber nicht verwunderlich, denn auch User Storys werden dort nicht genannt. Der Guide spricht “lediglich” von Backlog Items.

Eine Empfehlung zum praktischen Umgang mit User Story Maps finden Sie im Beitrag: Boost your Backlog.

Hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.