User Story Mapping: Was es ist und warum wir es einsetzen

Mit User Story Mapping schafft man sich einen Überblick über die geplante Software. Im Mittelpunkt dabei: Jene, die die Anwendung nutzen sollen. Hier stellen wir die Methode vor und erklären welche Vorteile sie hat!

Letzte Änderung: November 2023

Ein Softwareprojekt sollte nie ohne klare Übersicht und ein detailliertes Konzept starten. Sie verhindern, dass man sich im Projekt verrennt, unnötig Geld verbrennt und mit dem Ergebnis komplett unglücklich ist.

Katastrophe vorprogrammiert: Würden Sie so den Hausbau beginnen?

Aber: Es ist gar nicht so einfach, am Anfang sämtliche Anforderungen zu erkennen!

Welche Personen werden die Anwendung nutzen, welche Ziele wollen sie damit erreichen? Was brauchen sie? Wie werden sie die Anwendung benutzen? Und verstehen alle Projektbeteiligten überhaupt das Gleiche unter den Anforderungen?

Zeit für den Auftritt von User Story Mapping!

Der Name dieser Methode ist Programm:

1. User: Man geht von der Person aus, welche die Software nutzen wird.

2. Story: Man erzählt die Geschichte ihrer „Reise“ durch die Anwendung.

3. Mapping: Und man stellt das alles anhand einer übersichtlichen Karte dar.

Ein Beispiel, wie man sich mit User Story Mapping einen Überblick schafft

Sehen wir uns anhand eines vereinfachten Beispiels an, wie eine User Story Map entsteht: Wir nehmen uns dafür eine App vor, die Wettervorhersagen bietet.

Ausgangspunkt unserer Überlegungen sind die Menschen, die unsere App nutzen sollen. Oft gibt es unterschiedliche Gruppen mit unterschiedlichen Zielen.

Für unser einfaches Beispiel nehmen wir die folgende Person: „Userin Sunny möchte sich das aktuelle Wetter am aktuellen Standort ansehen, damit sie weiß, welche Kleidung sie anziehen sollte.“.

Dann machen wir uns Gedanken darüber, wie Sunny zu ihrem Ziel gelangt. Welche Schritte macht sie notwendigerweise? Diese Schritte werden von links nach rechts aufgelistet.

In diesen großen Stories steckt natürlich einiges, daher werden sie in kleinere Schritte aufgeteilt:

Mit User Story Mapping festlegen, was wann umgesetzt wird

Im Regelfall wird man nicht sofort alles umsetzen, was einem für die Anwendung einfällt. Zum einen, weil dadurch der Aufwand am Anfang sehr groß ist und man unnötig viel Zeit braucht, bis man die Software veröffentlichen kann.

Zum anderen auch, weil man eigentlich immer feststellt, dass bestimmte Anforderung fehlen oder doch nicht gebraucht werden – entweder schon während der Umsetzung oder spätestens, wenn die erste Version von den User*innen verwendet wird.

Daher überlegt man sich mit Hilfe der User Story Map, welche Anforderungen tatsächlich in die erste Version fließen sollen.

Diese Anforderungen sollten das wichtigste Ziel erfüllen, dass unsere User*innen erreichen wollen. In unserem Beispiel möchte Userin Sunny wissen, welche Kleidung sie anziehen soll.

Für die zweite Release sucht man das nächste Ziel. Viel weiter plant man noch nicht konkret, da man mit den ersten Releases sicher wertvolle Erfahrungen sammelt!

Die User Story Map wächst im Laufe des Projekts – mit jedem Release wird ein weiteres Ziel der User*innen erfüllt. Ideen, die über die geplanten Releases hinausgehen, sammeln wir auf dem sogenannten „Backlog“.

So eine User Story Map ist natürlich nicht in Stein gemeißelt: Wenn man, wie oben erwähnt, merkt, dass Anforderungen geändert werden sollten, ergänzt oder entfernt man sie einfach! Die Map wächst so flexibel mit dem Projekt mit.

Auch wenn wir das hier in diesem Artikel gemacht haben – es macht natürlich keinen Sinn einfach sofort mit dem Auflegen von Kärtchen zu beginnen!

Es gibt bei jedem Softwareprojekt einige Rahmenbedingungen vorab zu klären. Dazu gehören:

1. Eine kurze Beschreibung der Software, die „big story“ sozusagen. 
    Um bei unserem Beispiel Wetter-App zu bleiben: Als Unternehmen möchte ich meinen (potenziellen) Kunden*innen eine Wetter-App zur Verfügung stellen. Warum? Zum Beispiel, weil ich Outdoor-Kleidung verkaufe und das viel mit dem Thema Wetter zu tun hat – die App ist daher ein guter Kanal, um meine Produkte zu vermarkten. Da meine Kunden*innen anspruchsvoll sind, muss auch die App viel Nutzen (sprich: hilfreiche Infos) für die Kunden bringen. Der Name der App ist „Regenschein“.
   
   
2. Eine Beschreibung der verschiedenen User*innen.
   Oben haben wir schon Sunny als eine Art Standard-Userin beschrieben. Aber vielleicht gibt es noch andere Personen, mit anderen Zielen und daher Anforderungen? Zum Beispiel den begeisterten Skifahrer, der wissen möchte, wie die Schneelage ist (und sich im Idealfall gerne in meinem Shop mit Skihose & Co. ausstattet).  Oder die Wanderin, die vor Unwetter gewarnt werden möchte (und sich über einen funktionablen Wetterponcho freut).
   
   
3. Was hat das Unternehmen von dieser Software?
   In unserem Beispiel kann das Unternehmen über die App neue Kunden*innen ansprechen und zusätzlich Kleidung verkaufen. Gleichzeitig wird die Bindung mit dem bestehenden Kundenstamm und das Markenimage gestärkt.

1. Fokus auf die Personen, die die Software nutzen 

Die Methode sorgt dafür, dass alle die Sichtweise der User*innen einnehmen, deren Bedürfnisse in den Mittelpunkt stellen und ihre Ziele nie aus dem Blick zu verlieren.

2. Klare Visualisierung 

Man sieht es an dem obigen Beispiel: Die User Story Map bietet einen wirklich schönen Überblick über das Projekt. Es ist klar ersichtlich, welche Schritte die User*innen machen und wann welche Teile der Software umzusetzen sind.

3. Bessere Kommunikation:  

Um ein altes Sprichwort umzudichten: Reden ist Silber, Visualisierung ist Gold!  Allzu oft passiert es, dass man in einer Runde zusammensitzt, diskutiert und mit dem guten Gefühl rausgeht, alles geklärt zu haben – um dann später festzustellen, dass man komplett aneinander vorbeigeredet hat! Mithilfe des User Story Mappings werden solche Missverständnisse vermieden.

Die Visualisierung zeigt sofort auf, wenn es unterschiedliche Vorstellungen gibt! | Comic nach Jeff Patton

4. Flexibilität 

Eine User Story Map kann immer wieder geändert werden, Funktionen können hinzugefügt, verschoben oder weggenommen werden. So lebt die Karte mit dem Projekt mit.

5. Schrittweise Lieferung 

Mithilfe der Methode kann einfacher entschieden werden, welche Funktionen in einer ersten Version umgesetzt werden. So kann die Software schneller veröffentlicht werden und damit auch schnelleres Feedback von den User*innen eingeholt werden.

6. Transparenz  

Während der Umsetzung ist die User Story Map sehr hilfreich, um den Fortschritt zu visualisieren. Man sieht sofort, was schon fertig und was noch zu tun ist.

Wie wir konkret damit arbeiten: Vorgehensweise & Tools

Wenn wir feststellen, dass die User Story Map die ideale Methode für ein bestimmtest Softwareprojekt ist, starten wir mit dem Kunden die Workshops. In diesen geht es richtig altmodisch zu: Mit Stift und Post-its arbeiten wir gemeinsam an der Map.

Wir verwenden diese physischen Materialen gerne, weil sie Vorteile gegenüber digitalen Tools haben: Zum einen legt man einfach los, da man dafür keine Einarbeitung wie bei einem digitalen Tool benötigt.

Zum anderen macht es mehr Freude, die Post-its manuell zu Platzieren und zu Verschieben – das Engagement, die Konzentration und die mentale Verarbeitung wird dadurch gefördert. Außerdem wissen wir alle spätestens seit der Pandemie, wie wichtig die physische Interaktion gerade bei solchen Kreativprozessen ist!

Aber natürlich bleibt es dann nicht bei den Post-its: Nach den Workshops wird die User Story Map digitalisiert. Unsere Product Owner*innen nutzen dafür gerne das Produkt Miro.

Die User Story Map muss dann noch für das Entwicklungsteam in „technische Happen“ übersetzt werden. Das geschieht bei uns in Mircosoft DevOps.

Die User Story Map zeigt viel – aber nicht alles

Ein kleiner Exkurs: Auch wenn die User Story Map einen schönen Überblick bietet, so fehlen in ihr doch ein paar Details, die User*innen nie zu Gesicht bekommen. Das sind Dinge mit Namen wie „Datenbank-Setup“ oder „Google-Analytics-Integration“.

Zu einem Software-Projekt gehört also noch weitaus mehr als die nach außen sichtbaren Anforderungen – es ist ein Eisberg, der ziemlich tief gehen kann!

Was man sich alles rund um ein Software-Projekt überlegen muss, haben wir in einem anderen Artikel beschrieben: 
"Software Design vor der Umsetzung: Gut vorbereitet ist halb fertig!"

Nein, absolut nicht! Unser Artikel ist eine Einführung zum Thema User Story Mapping und basiert auf einem stark vereinfachten Beispiel.  

Es gibt noch viel mehr darüber zu erfahren! Wer mehr wissen möchte, findet eine Vielzahl von Informationen auf der Website des Erfinders der User Story Map Jeff Patton.

Er begann vor fast 20 Jahren an der Idee für das User Story Mapping zu arbeiten, da er unzufrieden war mit der Art, wie die Umsetzung von Softwareprojekte und deren Versionen geplant wurden.

Story-Mapping-Partner gesucht?

Wenn Sie ein Softwareprojekt umsetzen möchten, ohne sich zu verlaufen, sind Sie bei uns richtig!

Wir stellen Ihnen gerne unsere Erfahrung aus fast 30 Jahren Softwareentwicklung für mittlere und große Unternehmen unterschiedlicher Branchen zur Verfügung.

Kontaktieren Sie uns und reden Sie mit uns über Ihr Projekt!