t2informatik » Wissen kompakt » User Story Mapping

Was ist User Story Mapping?

Wie ist der Prozess bei der Erstellung einer User Story Map, welche Vorteile und Herausforderungen existieren?

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.

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.
  • Die Priorisierung wird erleichtert, denn Items lassen sich leicht verschieben. Gleichzeitig bleibt der Zusammenhang zu den Kundenanforderungen erhalten.
  • 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.
Was ist Scrum?
\

Zwei Dimensionen

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 Umsetzung

Wann werden welche User Storys umgesetzt? Diese Information können Sie durch die Zuordnung (hier im Beispiel zu den Sprints) leicht erkennen.

\

Horizontal

Die horizontale Anordnung der High-Level-Anforderungen (Epics 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.

\

Priorisierung

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

\

Zuordnung

Schnell erkennen Sie beim User Story Mapping, welche User Storys zu welchem Feature gehören. Einen solchen Zusammenhang erkennen Sie nur sehr schwer in einem flachen Product Backlog.

Verschiedene Mapping-Varianten

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.

User Story Whitepaper - t2informatik Download

Jetzt das User Story Whitepaper kostenlos downloaden.

Alles Wichtige über User Storys, Unterschiede zu Use Cases und User Story Mapping auf 11 Seiten zum Mitnehmen.

Hier klicken »

Arbeiten mit User Story Mapping

Story Mapping als iterativer Prozess

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 beim Story Mapping

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
  • Projektmanageent
  • UX Design und Entwurf
  • Vertrieb und Marketing
  • Finanzen und Recht

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

Die Verwendung von Zusatzinformationen

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.

 

Wollen Sie mehr über User Storys erfahren?

Dann erfahren Sie hier mehr über die Formulierung von User Storys, die Verwaltung in Backlogs und die Herausforderungen beim Backlog Grooming.

Herausforderungen für Unternehmen

Die Identifikation von Schwierigkeiten

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 er das Produkt erleben wird.
  • 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 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.

Gerne stellen wir Ihnen Wissen, Erfahrung und 100% Leidenschaft für Ihre Softwareentwicklung und Anforderungsanalyse zur Verfügung. Wir helfen Ihnen bei der Erhebung, Strukturierung und Verwaltung von Anforderungen und achten dabei auf Konsistenz, Vollständigkeit und Nachvollziehbarkeit. Wir unterstützen Sie beim Arbeiten mit User Storys und Identifizieren von technischen Zusammenhängen. Und wir nutzen Ihre Anforderungen für die Planung und Steuerung Ihrer Projekte.

Hier erfahren Sie mehr zum Thema Softwareentwicklung »

Weitere Details und Hintergründe ...
Share This