Der lise Blog:
Einsichten, Ansichten, Aussichten

User Story Mapping – die perfekte Methode, Anforderungen zu definieren

User Story Mapping ist ein Tool, das jede:r ITler:in kennen muss!

Besonders beliebt ist die Methode in der agilen Softwareentwicklung, um Produktanforderungen zum Start eines Projekts zu erfassen.

Ein neues Produkt zu entwickeln, ist ein spannender Prozess und benötigt, um ihn gut umzusetzen, einen strukturierten Ablauf.

Besonders beliebt ist User Story Mapping in der agilen Softwareentwicklung, um Produktanforderungen zum Start eines Projekts zu erfassen. Mit einer User Story Map stellst du die Bedürfnisse der Anwender in den Mittelpunkt, entwickelst ein gemeinsames Verständnis im Team, kannst einfach Features priorisieren und Releases planen.

Wie das geht und alles, was du über das geniale Tool von Jeff Patton wissen solltest, erfährst du hier!

 

Was ist User Story Mapping?

User Story Mapping ist eine Methode aus der agilen Softwareentwicklung, um die Anwenderreise durch ein Produkt zu visualisieren. Die User Story Map fasst alle User Stories auf einer Art Landkarte zusammen.

Eine User Story beschreibt dabei eine einzelne Aufgabe, die ein Nutzer tätig. Alle User Stories werden auf der User Story Map gesammelt und angeordnet.

Aus den User Stories werden Anforderungen an das Produkt abgeleitet, Features priorisiert und in Releases eingeplant. Die User Story Map lebt vom lebendigen Prozess und dem Austausch im Team.

Aus diesem Grund ist die Map kein statisches Dokument, das einmal erstellt ist, sondern kann jederzeit angepasst und erweitert werden.

 

Vorteile von User Story Mapping

Die User Story Mapping Methode bietet agilen Teams viele Vorteile:
 

1. Big Picture & Zusammenhänge erkennen

Die User Story Map verleiht einen Gesamtüberblick über alle Produktanforderungen.

Das hilft dabei, sich nicht in Details zu verstricken, sondern den Blick für das Große und Ganze zu wahren. Abhängigkeiten lassen sich leicht erkennen, was agile Teams unterstützt eine in sich schlüssige Software zu entwickeln.

2. Planung vereinfachen

Mithilfe der User Story Map kann das agile Team die Entwicklung eines Produktes einfach in mehrere Releases unterteilen. Wichtige Features können priorisiert und mit in die nächsten Sprints eingeplant werden.

3. Kundenfokus wahren

Da User Stories aus der Sicht des Anwenders formuliert sind, behält das Entwicklerteam mithilfe einer User Story Map den Nutzer jederzeit im Fokus. So entsteht eine Software, die sich nah am Kunden orientiert und den größten Nutzen bietet.

4. Gemeinsames Verständnis entwickeln

Die User Story Map wird in der Regel im Team erstellt, was die Kommunikation anregt und Transparenz schafft. Es entsteht ein gemeinsames Bild des Endproduktes, an dem sich alle Teammitglieder bei ihrer Arbeit orientieren können. 

 

 

User Story Mapping: Drei Schritte zur konkreten Anforderung

 

Jeff Patton betont in seinem Buch „User Story Mapping“, wie wichtig der Wissensaustausch bei der Anforderungserhebung zwischen allen Beteiligten ist. Durch Besprechung unterschiedlicher Aspekte wie

  1. Narrative Flow
  2. Activities
  3. User Stories

erkennen diese dann schnell das „Big Picture“ und können einzelne Funktionen besser im Gesamtkontext einordnen.

 

Wir zeigen dir, wie wir die Methode in der Zusammenarbeit mit Kunden umsetzen
 

1. Epics bzw. Narrative Flow

Zunächst starten wir mit der Erstellung des „Grobprozesses", den sogenannten „Epics“ (blaue Kästchen im Beispiel), und modellieren den sequenziellen Prozess von Anfang bis Ende, womit wir versuchen, einen eindimensionalen Prozess aufzustellen.

In Zusammenarbeit mit dem Kunden wird dieser Prozess im Laufe von ein bis zwei Stunden ermittelt und mithilfe von Post-its an der Wand visualisiert.

Die Arbeit mit Post-its erleichtert das spätere Umhängen von Prozessschritten, da es immer wieder vorkommen kann, dass sich bei einer Diskussion eine Diskrepanz zwischen Theorie und Praxis auftut und der Prozess in der Realität anders abläuft, als es theoretisch sein sollte.
 

2. Activities

Es wird immer wieder vorkommen, dass bei größeren Projekten ein sequenzieller Ablauf nicht ohne weiteres modelliert werden kann. Dabei hilft uns das Clustern von Epics zu Activities (grüne Kästchen im Beispiel).

Bei diesem Vorgehen werden Prozesse innerhalb einer Activity sequenziell gestaltet. Andere Activities sind davon nicht betroffen und können unabhängig der vorangegangen Acitivity sequenziell modelliert werden.
 

3. User Stories

Nachdem der Grobprozess erstellt worden ist, widmen wir uns den einzelnen Epics und formulieren User Stories.

In größeren Workshops (> sechs Personen) bietet es sich an, die User Stories in Gruppen zu erheben und diese später im Plenum zu präsentieren, um trotzdem das Wissen mit allen zu teilen.

User Stories sind eine Art der Anforderungsdokumentation und sind speziell aufgebaut:

Als ein Benutzer

möchte ich eine Aktion durchführen,

um einen Mehrwert zu generieren.

In jeder User Story wird eine Referenz zu einem Benutzer gezogen. Somit können gleiche User Stories für mehreren Benutzer erstellt werden. Eine User Story beinhaltet immer eine operationalisierbare Aktion, die implementiert und auch später getestet werden kann.

Das wichtigste einer User Story ist der Mehrwert, der in jeder User Story herausgestellt werden muss. Somit vermeiden wir, Funktionen umzusetzen, „weil sie schon immer so gemacht worden sind“.

Durch die Notwendigkeit des Mehrwertes wird schon bei der Anforderungsermittlung bei jeder Funktion hinterfragt, ob diese wirklich mehrwertstiftend ist. Im Zweifel entfällt eine Funktion, wenn kein Mehrwert ermittelt werden kann.

Im späteren Projektverlauf können User Stories mit weiteren Details, so genannten Akzeptanzkriterien, angereichert werden, um alle notwendigen Anforderungen dokumentieren zu können.

Bewusst wird dies nicht zu Beginn des Projektes für alle User Stories gemacht, da sich viele Anforderungen innerhalb des Projektes verändern können und die ausführliche Dokumentation somit hinfällig wäre. 

 

Ohne Priorisierung geht es nicht

Nachdem alle User Stories erfasst worden sind, kann nun eine Priorisierung innerhalb der Epics vorgenommen werden. Die Priorisierung wird später in das Product Backlog übernommen. Zum Ändern der Priorisierung nehmen wir eine User Story und kleben diese an die gewünschte Stelle innerhalb der Story Map. Dies kann auch gleichzeitig mit mehreren Personen durchgeführt werden. Im Anschluss wird dann nochmal gemeinsam über die Priorisierung diskutiert.

 


 

DEEP: die Erfolgsformel für das Product Backlog

Alle erfassten User Stories werden später in das Product Backlog überführt. Ein gutes Product Backlog wird mit dem DEEP-Akronym beschrieben, welches für folgende Eigenschaften steht:

Detailed appropriately

Emergent

Estimated

Prioritized


„Detailed appropriately“ bedeutet, dass der Detaillierungsgrad der Anforderung angemessen zum Projektfortschritt gewählt wird.

Wie bereits angesprochen, wird nicht jede User Story von vornherein detailliert beschrieben. Im fortschreitenden Projektverlauf werden User Stories nach und nach weiter spezifiziert.

„Emergent“ steht für kontinuierliche Veränderungen des Backlogs. Es werden neue User Stories hinzukommen und initial ermittelte User Stories wegfallen.

„Estimated“ beinhaltet, dass die spezifizierten User Stories geschätzt sind, um diese auch in einem Sprint umsetzen zu können.  

„Prioritized“ bedeutet, dass eine Priorisierung innerhalb des Product Backlogs vorgenommen worden ist (ggf. analog zur Priorisierung der Story Map), damit die wichtigsten Stories als erstes umgesetzt werden. 

 

Sprint-Planung: in fest definierten Steps zum Produkt

Ebenfalls kann mit der Story Map eine übersichtliche Sprintplanung vorgenommen werden. Dafür wird in der Story Map eine Linie gezogen, die die Sprintinhalte aufteilt. Der Vorteil ist hierbei, dass die Sprints analog zur Priorisierung geplant werden können, um die wichtigsten User Stories zuerst umzusetzen.

Mithilfe der Planung in der Story Map ist auch noch im späteren Projektverlauf schnell ersichtlich, welche Funktionalitäten in welchem Sprint umgesetzt worden sind. Die Transparenz ist für alle Beteiligten ein großer Vorteil. 

 

 

Einsatz in der Praxis

Die User Story Mapping Methode lässt sich vielseitig in der agilen Softwareentwicklung einsetzen.
 

1. Anforderungen zum Start definieren

Besonders gut eignet sich die Erstellung einer User Story Map zum Einstieg in ein agiles Projekt, um alle Anforderungen an das Produkt zu sammeln. Feature können im nächsten Schritt abgeleitet, priorisiert und die Entwicklung in Releases aufgeteilt werden.

2. Ist-Situation analysieren

Um die Bedürfnisse oder Probleme von Anwendern besser zu verstehen, lässt sich auch ein Ist-Zustand der Software abbilden. Die aktuelle Situation ist eine gute Grundlage für eine weitere Analyse der Problematiken.

3. Ergänzung zum Product Backlog

Die User Story Map ist eine Erweiterung des Product Backlogs. Die Visualisierung auf einer Map zeigt Zusammenhänge, welche sich nicht durch eine Liste abbilden lassen.

4. Neue Ideen generieren

Auch kann die Methode für kreative Zwecke eingesetzt werden, z.B. um neue Feature- oder Produktideen zu generieren. Die User Story Map dient hervorragend als Einstieg für ein Brainstorming im Team.

 

 

Best Practices & Tipps

Hier findest du weitere praktische Tipps, um das Tool gekonnt einzusetzen:
 

1. Wähle die richtigen Teilnehmer:innen aus

Eine User Story Map ist nur so gut, wie das Team, das es erstellt!

Es sollten vor allem Anwender:innen und Produktmanager:innen involviert sein, welche die Anforderungen an das Produkt sowie die User Journey genau kennen.

Entwickler:innen sowie der Scrum Master sollten im Workshop natürlich nicht fehlen. Sie unterstützen mit Ideen, stellen Fragen und entwickeln ein gemeinsames Verständnis für das Produkt im Team. Optional können noch weitere Verantwortlichkeiten wie Designer, Customer Service oder Geschäftsführer:innen hinzukommen, um das Produkt aus unterschiedlichen Perspektiven zu beleuchten.

 

2. Lasse deiner Kreativität freien Lauf

Nutze das Tool so, wie es für dich und dein Team am besten passt. Bleibe flexibel und werde kreativ. Du kannst weitere Farben, Kreppband oder Seile verwenden. So kannst du Zusammenhänge verdeutlichen und weitere wichtige Faktoren festhalten. Wichtig: Am Ende sollte die Map übersichtlich und leicht verständlich sein!

 

3. Hänge die User Story Map sichtbar auf

Hänge die User Story Map an einem für alle Teammitgliedern zugänglichen Ort auf, z.B. im Flur oder Büro. So lässt sich schnell einen Blick auf die Map erhaschen. Ihr habt das „Big Picture“ immer vor Augen und könnt im Entwicklungsprozess flexibel bleiben.

 

 

Die besten digitalen Tools fürs User Story Mapping

Nicht immer ist es möglich, einen Workshop vor Ort zu organisieren. In dem Fall können digitale Tools Abhilfe schaffen. Hier sind zwei Beispiele, mit denen Teams auch virtuell User Story Maps erstellen können.
 

1. FeatureMap

Wir nutzen FeatureMap, um User Story Maps zu digitalisieren, die wir in Kundenworkshops gemeinsam erstellen. Das Tool bietet viele Funktionen. Die User Journey kann in Activities und Tasks aufgeteilt sowie in verschiedenen Farben visualisiert werden.

Darunter kannst du die Features aufführen und Sprints definieren. Weitere Informationen wie Deadlines, Kommentare und Verantwortlichkeiten lassen sich wie in Jira zu den Karten hinzufügen.

Der Vorteil gegenüber den Whiteboard-Tools ist die klare Struktur der Anwendung. Mit der kostenfreien Variante kannst du bis zu zwei Maps erstellen. Wenn du Featuremap unbegrenzt nutzen möchtest, zahlst du ca. 5 € im Monat.

Probier’s einfach aus, wir können es dir ans Herz legen!

 

2. Miro-Board

Miro ist eine Whiteboard-Plattform für Teams. Hier kannst du das virtuelle Whiteboard verwenden, um eine User Story Map zu erstellen.

Dafür gibt es sogar eine vorgefertigte Vorlage. Zudem bietet Miro auch zahlreiche Integrationen mit anderen Anwendungen wie Zoom, Teams oder Jira. Die kostenfreie Variante ist ein guter Einstieg. Wenn du aber erweiterte Funktionen nutzen möchtest, kommst du um ein kostenpflichtiges Upgrade nicht herum.

 


Fazit: Ein geniales Tool für jedes agile Team

Eine User Story Map bietet viele Vorteile und stellt eine Ergänzung zum Product Backlog dar. Anders als mit einer simplen Liste können User Stories visualisiert und Zusammenhänge deutlich gemacht werden.

Agile Teams können Produktanforderungen einfach definieren, Features priorisieren und Releases planen. Eine User Story Map kann in einem Workshop gemeinsam erarbeitet werden.

Ein möglichst diversifiziertes Team kann die Anwendung aus allen relevanten Blickwinkeln betrachten. Wenn ein Workshop vor Ort nicht möglich ist, lässt sich die Map auch auf virtuellen Whiteboards erstellen. 

Das User Story Mapping ist ein geniales Tool, da es den Anwender in den Fokus stellt. So können agile Teams eine Software entwickeln, die genau den Nutzerbedürfnissen entspricht. 

Zusätzlich empfiehlt es sich zudem bereits in diesem Workshop die Produktvision zu erarbeiten. Dies kann zum Beispiel mit der „Product Vision Map“ von Roman Pichler geschehen.

 

Fragen zu User Story Mapping? Wir helfen!

 

 

 

 

Diesen Artikel weiterempfehlen

 Teilen  Teilen  Teilen  Teilen