zum Inhalt

Der lise Blog:
Einsichten, Ansichten, Aussichten

User Story Mapping – die perfekte Methode, Anforderungen zu definieren

28. Oktober 2019 von Avatar of ChristophChristoph

Ein neues Produkt zu entwickeln, ist ein spannender Prozess und benötigt, um ihn gut umzusetzen, einen strukturierten Ablauf. Bevor es jedoch entwickelt werden kann, müssen die Anforderungen an das Produkt erhoben und verschriftlicht werden. Dazu stellen wir dir in diesem Blog-Beitrag die Methode „User Story Mapping“ von Jeff Patton vor.

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.

User Story Mapping: Drei Schritte zur konkreten Anforderung

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 so genannten „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 mit Hilfe 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.

  1. 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.

  1. 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. Mit Hilfe 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. 

Fazit

Mit Hilfe der User-Story-Mapping-Methode kann in ein bis zwei Workshop-Tagen ein initiales Backlog aufgebaut werden, mit dem ein Projekt oder ein Produkt entwickelt werden kann. Die Stärke der Methode ist, dass im Projektteam sehr schnell ein gemeinsames Verständnis der Anforderungen aufgebaut und gefestigt wird. Dies ist im gesamten Projektverlauf sehr wichtig, um nicht in eine falsche Richtung zu entwickeln. 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.  

Newsletter-Anmeldung

Newsletter-Anmeldung
* Dieses Formular speichert Ihre E-Mail-Adresse. Weitere Informationen in unseren Datenschutzbestimmungen.