Bei der agilen Projektentwicklung stehen User Stories an erster Stelle. Kein Wunder, denn darin werden alle Anforderungen de*r Kund*in an das Projekt festgehalten. Somit sind User Stories enorm wichtig, weil sie den Fahrplan für alle weiteren Schritte im Projektablauf vorgeben. Über die große User Story hinaus empfiehlt es sich aber auch, kleinere User Stories bzw. Aufgaben für einzelne Features zu entwickeln. Dabei kann das Planungsboard schnell voll werden – egal, ob digital oder analog. Damit Sie auch bei Projekten mit vielen Aufgaben nicht den Überblick verlieren, empfiehlt sich die Visualisierung mittels User Story Mapping. Was das ist und wie es funktioniert, verraten wir Ihnen hier.

User Story – Definition

Ohne User Stories kein User Story Mapping. Deswegen schauen wir uns vorab kurz an, was eine User Story eigentlich impliziert. Der Begriff setzt sich aus „user“ und „story“ zusammen, beschreibt also die Geschichte eine*r Nutzer*in im Hinblick auf einen Anwendungskontext. Im digitalen Projektmanagement heißt das: Eine User Story beschreibt die gewünschte Funktionalität eines Systems oder Produkts aus Sicht de*r Nutzer*in. Wichtig sind dabei drei Fragen:

• Wer?
• Was?
• Und: Warum?

In einer User Story wird definiert, wer die Nutzer*in ist, was sie sich wünscht und warum bzw. wozu sie es braucht. Beim Schreiben von User Stories ist deshalb eine festgelegte Syntax ratsam, die ungefähr so aussieht:

Als (wer?) will ich (was?), um (warum?) zu erreichen.

Zum Beispiel:

Als Restaurantgast will ich eine virtuelle Karte vom Restaurant, um den besten Platz online zu buchen.

Natürlich sind auch Abwandlungen von dieser Struktur erlaubt. Hauptsache, sie beinhalten die drei W-Elemente.

Übrigens: Wussten Sie, dass User Stories gar keine Erfindung des SCRUM sind? Zwar werden sie heute häufig in einem Atemzug mit der agilen Prozesssteuerung genannt. Ursprünglich stammt das Konzept aber aus dem Extreme Programming (XP) und tauchte erstmal 1996 bei einem Chrysler-Projekt auf.

Zu jeder User Story gehören auch Akzeptanzkriterien. Damit gemeint sind alle fachlichen Anforderungen, die erfüllt sein müssen, damit die User Story als vollendet gilt. Im Beispiel oben könnten das folgende sein:

• Wenn ein User auf die Webseite des Restaurants kommt, muss er oder sie eine virtuelle Karte finden.
• Wenn ein User auf die virtuelle Karte klickt, muss sie ihm oder ihr den gesamten Raum mit Sitzplätzen anzeigen.
• Wenn ein User einen Sitzplatz auswählt, muss ihm oder ihr die Karte anzeigen, ob dieser noch frei ist.
• Wenn ein User auf „Reservieren“ klickt, muss der gewählte Sitzplatz für sie oder ihn reserviert sein.

Das sind natürlich nur einige Beispiele für Akzeptanzkriterien. Normalerweise hat jede User Story noch viel mehr davon. Es empfiehlt sich, dabei so genau wie möglich zu beschreiben, was gefordert ist. Haben Sie Ihre User Story definiert, geht es an die Planung der einzelnen Schritte. Hier kommt das Mapping ins Spiel.

So gehen wir die Liste für sämtliche weitere Schritte durch, bis wir alle Anforderungen dokumentiert haben. Das Beispiel des Automobilherstellers finden Sie auch in unserem Video von Scrum Coach Felix noch einmal anschaulich erklärt:

Nach dem ersten Release können wir uns an die vertikal zweitrangigen Aufgaben machen. Sind diese abgeschlossen, können wir eine neue Version veröffentlichen. Die verschiedenen Versionen müssen natürlich von echten Usern getestet werden. So können wir auch fundiert entscheiden, ob die vertikal drittrangigen Aufgaben überhaupt noch benötigt werden oder ob stattdessen andere Aufgaben hinzukommen, bzw. andere Features implementiert werden müssen.

Diese Überprüfung nehmen wir nach jeder Version vor. Damit erreichen wir höchste Effizienz und können mit jedem Release weiter optimieren.

Vorteile von User Story Mapping

Früher haben wir, wie viele Unternehmen, unsere Projekte in einem Lastenheft dokumentiert. Dort wurden gleich zu Beginn alle Anforderungen de*r Kund*in festgehalten. Demgegenüber stand das Pflichtenheft, dass das „Wie“ der Anforderungen geregelt hat, also die einzelnen Schritte bis zum gewünschten Ziel der Anforderungserfüllung. Gemäß der Wasserfallmethode war dieses Vorgehen aber sehr starr. Sobald sich eine Anforderung geändert hat, mussten wir die komplette Planung über den Haufen werfen. In einer agilen Entwicklungsumgebung ändern sich die Dinge jedoch ständig.

Mit einer User Story Map ist das Pflichten- und Lastenheft überflüssig. Mehr noch: Das Vorgehen anhand der User Journey bringt immense Vorteile mit sich.

• Übersicht: Ein simpler, aber nicht zu unterschätzender Vorteil – wir haben bisher kein besseres Visualisierungstool gefunden als eine User Story Map. Damit haben wir alle Steps und deren Priorisierung auf dem Weg zum erfolgreichen Projektabschluss immer im Blickfeld. Auch Lücken im Backlog werden so schnell erkannt.
• Allround-Anwendungsgebiete: User Story Mapping funktioniert nicht nur bei der agilen Aufwandsschätzung oder der initialen Projektplanung, sondern auch beim Controlling.
• Eindeutige Hierarchien: Eine Landkarte aller benötigten Funktionen sorgt auch für eindeutige Hierarchien unter den einzelnen Aufgaben. So wissen wir immer, was wir zuerst angehen sollten.
• Schnellere Releases: Das gilt für agiles Arbeiten insgesamt, wird aber u. a. durch User Story Mapping ermöglicht. Durch dieses Vorgehen kann eine erste Version viel schneller veröffentlicht werden, als wenn man zunächst versucht, das Produkt zu perfektionieren. Mit der agilen Arbeitsweise bekommen wir also auch schneller Feedback. Dadurch können Änderungen früh einfließen und das Produkt wird insgesamt besser.
• Schnelle Änderungen möglich: Dieser Vorteil gilt ebenso nicht nur fürs User Story Mapping, sondern allgemein für agile Arbeitsweisen. Im Gegensatz zu vordefinierten Abläufen kann mit Hilfe agiler Tools jeder Arbeitsschritt leicht zurückgenommen oder abgeändert werden. Das spart viel Arbeit.
• Weniger Bürokratie: Akribische Dokumentation im Vorfeld entfällt beim User Story Mapping. Das Lastenheft war sehr detailliert. Funktionen wurden exakt definiert, die später vielleicht gar nicht mehr gebraucht wurden. Dadurch wurde viel Waste produziert. Das verschwendet nicht nur Arbeitszeit, sondern wirkt auch demotivierend. Wer lange jeden Schritt genau geplant hat, um dann festzustellen, dass schon am Anfang ein Fehler lag oder sich Anforderungen diesbezüglich geändert haben, hat allen Grund, genervt zu sein. Mit einer User Story Map hält sich der bürokratische Planungsaufwand in Grenzen – und Mitarbeiter*innen haben die Köpfe frei für produktive Arbeit.
• Einfache Unterteilung: Durch (vor allem händisches) User Story Mapping können Sie einzelne Aufgaben leicht in verschiedene Parts aufteilen, ohne den Überblick zu verlieren. Die Abhängigkeiten untereinander bleiben dabei bestehen.
• Kooperatives Teamwork: Mapping ist eine gemeinschaftliche Aufgabe und wird in der Regel von allen beteiligten Projektteams, Scrum Master/Product Owner und ggf. Kund*in zusammen ausgeführt. Dadurch wird der Teamgeist gestärkt und ständige Kommunikation gewährleistet. Auch eine gemeinsame Sprache bzw. das Verständnis für den Projektablauf wird hier festgelegt.

Verwendungsmöglichkeiten und Tools für User Story Maps

Wie bei vielen anderen agilen Tools gibt es auch das User Story Mapping zahlreichen Varianten. Neben der Einteilung in User Journey und Tasks wie bei uns teilen viele Teams ihre Schritte und Anforderungen weiter in Epics, Features und Subtasks ein. Das ist dann sinnvoll, wenn Projekte viele kleine Einzelschritte benötigen. Es kann auch sinnvoll sein, zusätzliche Informationen in einer Story Map unterzubringen. Manchmal können reine Technical Stories sinnvoll sein, die sich anders als funktionale User Stories weniger auf Funktionen als vielmehr auf technische oder infrastrukturelle Anforderungen an ein Projekt konzentrieren. Auch so genannte Spike Stories können in einer User Story Map untergebracht werden. Dabei geht es um das Finden von Antworten oder Informationen, die benötigt werden, nicht um das Entwickeln eines Produktes.

Bei den Werkzeugen rund ums User Story Mapping haben Sie die Wahl. Ob sie nun wie wir analog mit Zettel und Stiften arbeiten wollen oder lieber auf digitale Tools zurückgreifen, liegt ganz bei Ihnen. Wichtig ist nur, dass Sie die einzelnen Ebenen der User Story Map auf Ihrem Board oder Screen gut sichtbar voneinander abgrenzen. Verschiedene Farben sind hier also empfehlenswert. Ansonsten können Sie nach Lust und Laune kleben, pasten, verlinken oder mit bunten Fäden verbinden – eben so, wie es zu Ihnen und Ihrem Projekt passt.

User Story Map anwenden in 6 Schritten

Wie gehen Sie also konkret vor, wenn Sie eine User Story Map erstellen möchten?

• Sie definieren Ihre Zielgruppe.
• Sie definieren die Ziele Ihre*r Kund*in.
• Sie visualisieren die User Journey bzw. den Backbone.
• Sie erstellen einzelne Tasks oder User Stories und priorisieren diese nach Ziel der Kund*in.
• Sie identifizieren Abhängigkeiten zwischen den einzelnen Aufgaben und ggf. Backlog-Lücken.
• Sie planen Ihre Projektentwicklung in einzelnen Sprints bis zur Abnahme.

Natürlich können diese Schritte nicht immer chronologisch erfolgen. Manche sind im einen Projekt notwendig, im anderen bereits überflüssig. Diese Schritte bieten Ihnen nur eine Orientierung.

User Story Map – unsere Basis für erfolgreiches Projektmanagement

Wir bei Ambient haben dem Lastenheft schon lange „Adios“ gesagt und es durch User Story Maps ersetzt. Die vielen Vorteile haben uns auch in der Praxis überzeugt: Sie ermöglichen uns eine strukturierte und doch flexible Vorgehensweise und führen uns auch bei Projekten mit vielen Anfangsvariablen zum Erfolg. Für uns ist besonders wichtig, dass wir unsere Projekte stets aus den Augen unserer Kund*innen betrachten. Mit User Story Maps ist dies uneingeschränkt möglich. Deshalb wollen wir unsere bunten Landkarten nicht missen und empfehlen jedem digital agierenden Projektteam, sich selbst vom Nutzen diesen agilen Planungstools zu überzeugen.

Wollen Sie mehr über agiles Projektmanagement erfahren? Oder haben Sie Fragen, Anregungen oder Kritik zu unserem Blog? Dann schreiben Sie uns. Wir freuen uns auf den Austausch mit Ihnen!