Alexander Yzer Product Owner

Alexander Yzer hat 15 Jahre Erfahrung im Projektmanagement und in der IT-Beratung. Bei IT-P ist er seit 2019 als Product Owner im Competence Center Project Management tätig. Dort befasst er sich vor allem mit der Analyse und Verbesserung von Prozessen sowie dem Anforderungsmanagement und der Durchführung agiler Projekte. Privat beschäftigt er sich momentan intensiv mit Automatisierungs-Lösungen für das Smart Home.

User Story Mapping – Den Kunden besser verstehen
Im User Story Mapping nehmen Entwicklungs-Teams konsequent die Kundenperspektive ein. Doch wie funktioniert das?
Autorbox: Ja

Der Erfolg eines Software-Entwicklungsprojekts hängt davon ab, wie gut der Anbieter die Wünsche und Bedürfnisse des Kunden versteht und im fertigen Produkt berücksichtigt.

Hierbei ist sowohl das Big Picture wichtig als auch ein Auge fürs Detail. Um die Kundenperspektive leichter einnehmen zu können, setzen viele Entwicklungs-Teams auf die Methode des User Story Mappings.

Erkennen, was wichtig ist

Was aus Kundensicht relevant ist, können Entwicklungs-Teams nicht immer mit Gewissheit sagen. Ein Lastenheft kann beispielsweise immer Missverständnisse hervorrufen, da es von Menschen geschrieben und gelesen wird. Manchmal werden Inhalte vergessen, unglücklich ausgedrückt oder falsch gedeutet. Selbst das umfangreichste Dokument ist daher keine Garantie für ein einheitliches Verständnis aller Beteiligten.

Lückenhaft formulierte Anforderungen, die Raum für Fehlinterpretationen bieten, können ein Entwicklungsprojekt in ernsthafte Schwierigkeiten bringen. Der Kunde beschreibt A, meint B und der Anbieter versteht C – und am Ende ist niemand zufrieden. Vielleicht denken Sie gerade spontan an den berühmten „Tree Swing Cartoon“, der zur Veranschaulichung dieses Problems gerne zitiert wird:

Der Tree Swing Cartoon. (Quelle: http://www.uidesign.at/journal/2007/05/16/die-anforderungen-der-nutzer-verstehen/)

Um zu verhindern, dass Entwicklungs-Teams an den Bedürfnissen der Nutzer vorbeiarbeiten, braucht es vor allem eins: direkte, intensive Kommunikation. Iterative Prozesse, wie wir sie aus dem agilen Projektmanagement kennen, helfen dabei, Missverständnisse frühzeitig zu erkennen und zu korrigieren.

An dieser Stelle kommt User Story Mapping ins Spiel. Wie der Name sagt, besteht das Ziel der Methode darin, eine Landkarte der Kundenanforderungen in Form von User Stories zu erstellen, um die User Experience von Anfang an zu berücksichtigen. Die Anforderungen werden dabei in der Regel auf Klebezettel geschrieben und auf einem Board angeordnet.

Im Gegensatz zum Product Backlog bieten User Story Maps eine zweidimensionale Sichtweise:

  • Auf der horizontalen Ebene stellen sie die chronologische Abfolge des Prozesses dar – inklusive einer Gliederung der darin enthaltenen Aufgaben.
  • Auf der Vertikalen erreichen Teams eine hohe Detailtiefe in Form der Arbeitsschritte und deren Priorität.

Der große Vorteil der Technik besteht in der Interaktion der Team-Mitglieder untereinander. In den Workshops versammelt sich eine Gruppe von Menschen an einem Board, produziert neue Karten, klebt sie an die Wand und schiebt die Inhalte hin und her. Allein dadurch entsteht ein hohes Maß an Kommunikation. Der intensive Austausch im Team, der für erfolgreiches agiles Arbeiten nötig ist, wird dadurch ebenso gefördert wie ein gemeinsames Verständnis der Anforderungen und Bedürfnisse der Nutzer.

Wie funktioniert User Story Mapping?

User Story Maps entstehen in der Regel in moderierten Workshops. Daran beteiligt sind alle Stakeholder, die einen Mehrwert durch das geplante Produkt haben – insbesondere die Anwender aus den Fachbereichen, die später mit der Software arbeiten. Sind Schnittstellen zu anderen Anwendungen zu betrachten, sollten auch die IT und die Produktmanager der anderen Applikationen involviert sein. Auf diese Weise können Entwickler auch deren Anforderungen berücksichtigen.

Tipp

Geht es in der Software-Entwicklung um Wünsche, entstehen sehr schnell lebhafte, kreative Diskussionen, in denen die Teilnehmer vor lauter Ideen den Fokus verlieren. Das erschwert es, das Big Picture im Auge zu behalten. Hilfreich ist, eine Produktvision über die User Story Map zu hängen. Diese sollte bereits zu Beginn des User Story Mappings feststehen, kann aber in kleinen Projekten durchaus auch zu Beginn des Workshops erarbeitet werden.


Damit Teams Anforderungen richtig erfassen, müssen sie wissen, wer die späteren Nutzer der Software sind. Bewährt hat es sich, gedanklich vorauszusetzen, dass die Software bereits fertiggestellt ist, um dann für jede Persona – fiktive, archetypische Nutzer – die Berührungspunkte zwischen Mensch und Software zu untersuchen.

Persona

Personas agieren im User Story Mapping als Protagonisten einer Geschichte, die ihre Interaktion mit dem Software-Produkt beschreibt. Für jede Persona verfasst das Projekt-Team ein bis zwei Sätze, die die Anforderungen der Nutzergruppe an ein Feature beschreiben. Diese werden später in die User Story Map aufgenommen.

So entsteht eine User Story Map

Die einzelnen Elemente innerhalb einer User Story Map werden in der Literatur uneinheitlich bezeichnet. In diesem Beitrag beziehen wir uns auf die Formulierungen, die Jeff Patton in seinem Buch „User Story Mapping – Discover the Whole Story, Build the Right Product“ verwendet.

1. Schritte

UserStoryMap01

 

 

 

 

 

 

Die Handlungsschritte sind in der User Story Map auf horizontaler Ebene dargestellt.

Patton bezeichnet die einzelnen Handlungen innerhalb einer Story als Schritte. Diese fasst das Team auf Klebezetteln zusammen und platziert sie in der User Story Map chronologisch von links nach rechts. Sie bilden den narrativen Fluss, der die Geschichte vorantreibt.

2. Activities

UserStoryMap02

 

 

 

 

 

 

Einzelne Handlungen (grün) werden Aktivitäten (blau) zugeordnet – auf diese Weise entsteht das Rückgrat (Backbone) der User Story Map.

Die einzelnen Schritte fasst das Team zu Aktivitäten zusammen. Diese werden ebenfalls auf Zetteln (oder in einem digitalen Visualisierungs-Tool) niedergeschrieben und über den Schritten angeordnet. Diese Darstellung bildet das Rückgrat (Backbone; siehe Abbildung 2. Activities) jeder User Story Map. Das Team berücksichtigt darin auch die Personas, die mit den einzelnen Schritten in Berührung kommen, und fügt diese der Darstellung hinzu.

Der Backbone bildet mit den darunter hängenden Schritten den so genannten Walking Skeleton. Hierbei handelt es sich um das Grundgerüst, nach dem sich die Entwickler bei ihrer Arbeit richten. Es ist jedoch nicht starr, sondern ein dynamisches Konstrukt, das sich im Projektverlauf verändert.

3. Details

UserStoryMap03

Die Handlungsschritte (grün) werden in einzelne Tätigkeiten unterteilt.

Als nächstes werden die einzelnen Schritte genauer spezifiziert. Das Team begibt sich nun auf die Detailebene und fügt die jeweiligen Tätigkeiten (meist mit einem Nomen und einem Verb beschrieben; siehe Abbildung 4) hinzu, die eine Handlung ausmachen. Diese Details bilden die Grundlage für die umzusetzenden Tasks, die in User Stories formuliert werden können.

 

4. Releases/Outcome

UserStoryMap04Software-Produkte konzipieren wir im User Story Mapping anhand von Release-Stufen. In jeder Iterationsschleife wird ein funktionsfähiges Produkt entwickelt, das für den Kunden einen Mehrwert hat.

Das Bild, das ein Walking Skeleton für Teams bietet, kann je nach Projektumfang sehr groß sein. Es enthält mit Sicherheit einige Anforderungen, die keine sonderlich hohe Priorität haben, sondern eher nice-to-have sind. Deswegen ist es wichtig, dass das Team die Schritte und Details anhand ihrer Dringlichkeit priorisiert.

Um dies zu erreichen, definieren die Entwickler ein Minimum Viable Product (MVP). Es beschreibt die Mindestanforderungen für ein lebensfähiges, benutzbares Produkt und enthält alle Details, die eine mehrwertfähige Software benötigt. Darauf aufbauend legt das Team den gewünschten Outcome für weitere Releases im Anschluss an die Fertigstellung des MVP fest. Diesen visualisiert es am linken Rand der Story Map, um dort die Karten mit den Details zuzuordnen (siehe Abbildung 4. Releases/Outcome).

User Story Maps erleichtern die Release-Planung

Wichtig ist, dass sich das Team beim User Story Mapping konsequent auf den Kundennutzen ausrichtet. Folgende Abbildung verdeutlicht das. Es geht nicht darum, Schritt für Schritt Einzelteile zu entwickeln, die am Ende zum finalen Produkt zusammengefügt werden. Das Ziel besteht darin, nach jedem Release ein funktionsfähiges Teilergebnis zu liefern, das der Produktvision entspricht. Dieser Release wird in den folgenden Iterationen immer weiter verbessert.

makingsenseAm Ende jeder Iterationsschleife soll ein Produkt stehen, das der Produktvision entspricht. (Quelle: https://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp)

Eine User Story Map ist kein statisches Gebilde. Sie wird ständig ergänzt oder angepasst. Neue Releases können geplant, Anforderungen umpriorisiert oder verändert werden. Die User Story Map verschwindet also nicht in der Schublade des Product Owners. Sie dient als Orientierungspunkt, der Abhängigkeiten aufzeigt und eine Basis für fachliche Diskussionen liefert.

Tipp

User Story Maps dienen auf dem Weg durch das Projekt als Landkarte. Gerade bei zentral arbeitenden Teams empfiehlt es sich, die Map gut sichtbar an der Wand zu platzieren. Das hat erfahrungsgemäß einen stärkeren Effekt als digitale Darstellungen (die wiederum als Ergänzung empfehlenswert sind).

Für welche Projekte ist User Story Mapping geeignet?

Für Unternehmen, die sehr kleine Projekte agil umsetzen, reicht die Ein-Dimensionalität des Product Backlogs völlig aus. Das genügt, um sinnvoll mit User Stories zu arbeiten. Eine genaue Kennzahl für die Anwendung von User Story Mapping, existiert leider nicht. Das liegt daran, dass sich Komplexität nicht zwingend allein durch die Anzahl der zu erwartenden User Stories definiert.

User Story Mapping wird überwiegend bei Neuentwicklungen eingesetzt. Die Methode kann aber auch für bereits bestehende Software sinnvoll sein, beispielsweise zu Dokumentationszwecken, um den Sinn einiger Funktionen zu hinterfragen oder um das Produkt zu erweitern.

Tipp

Durch Home Office und Abstandsregeln geht die Dynamik, die für User Story Mapping charakteristisch ist, ein Stück weit verloren. Dennoch gibt es Tools, mit denen die Sessions auch digital durchgeführt werden können. Dazu zählen beispielsweise Miro, Visual Paradigm, Stories on Board, draw.io oder Easy Agile User Story Map. Einige Tools sind auch als Add-on für Jira verfügbar, falls Sie damit arbeiten.

Zusammengefasst

Beim User Story Mapping dreht sich alles darum, Aufgaben, die aus Kundensicht zu erledigen sind, in Form von Geschichten aufzubereiten. Diese Stories entstehen in enger Abstimmung mit späteren Nutzern und werden in Form einer übersichtlichen Karte visualisiert. Dieses Vorgehen hat mehrere Vorteile:

  • Das Entwicklungs-Team behält Kundenanforderungen jederzeit im Auge.
  • Der Umfang der einzelnen Releases wird erheblich reduziert.
  • Die Methode fördert die Kommunikation im Team und trägt zu einem einheitlichen Verständnis der Aufgabe bei.
  • Dies wiederum führt erfahrungsgemäß zu besseren Ergebnissen.

Wenn Sie nach diesem Beitrag Lust haben, User Story Mapping zu testen, empfehlen wir Ihnen ein klassisches Beispiel: Die Morning Map (siehe Abbildung 1 bis 5). Sie befasst sich mit dem Anwendungsfall „Ich stehe morgens auf und gehe zur Arbeit“. Dieses vermeintlich triviale Szenario löst in der Regel ausführliche Diskussionen aus, die zeigen, worum es im User Story Mapping geht. Diese Erfahrung ist in späteren Projekten von großem Wert.

agiletransformation

Wir nutzen Cookies auf unserer Website. Einige von ihnen sind essenziell für den Betrieb der Seite, während andere uns helfen, diese Website und die Nutzererfahrung zu verbessern (Tracking Cookies). Sie können selbst entscheiden, ob Sie die Cookies zulassen möchten. Bitte beachten Sie, dass bei einer Ablehnung womöglich nicht mehr alle Funktionalitäten der Seite zur Verfügung stehen.