Warum haben wir User Story Mapping ausprobiert?
Eine klare Vision und ein gemeinsames Verständnis der Zielsetzung sind in der Softwareentwicklung von großer Bedeutung. Es ist essenziell, dass alle Beteiligten – von den Stakeholdern über das Management bis hin zu den Entwicklungsteams – die Endziele des Projekts verstehen. Dies erfordert ein Bild davon, wie diese Ziele erreicht werden sollen. Ein gemeinsames Verständnis ermöglicht es, dass alle an einem Strang ziehen. Das fördert die Zusammenarbeit, reduziert Missverständnisse und steigert die Effizienz.
In all unseren Projekten ist es immer wieder eine Herausforderung, diese Vision zu erarbeiten und mit allen Projektbeteiligten kohärent teilen zu können. Gleichzeitig ist dies aber ein wichtiger Erfolgsfaktor.
Deshalb sind wir ständig auf der Suche nach Möglichkeiten, dies noch weiter zu verbessern.
Vor einigen Jahren wurden wir auf das Thema User Story Mapping aufmerksam. Wir erkannten hierin zu den genannten Aspekten vielversprechende Ansätze. Daher beschlossen wir, der Idee eine Chance zu geben und das Vorgehen in verschiedenen Projekten zu erproben. Ich möchte nachfolgend erzählen, was wir auf dieser Reise erlebt und gelernt haben.
User Story Mapping – was ist das?
Eine grundlegende Einführung in User Story Mapping würde den Rahmen dieses Artikels sprengen. Ich werde mich vielmehr auf unsere Erfahrungen beim Einsatz konzentrieren.
Für diejenigen, die vor dem Sprung in unser Abenteuer noch ein paar grundlegende Informationen brauchen, nur so viel:
Den Anstoß für User Story Mapping lieferte Jeff Patton 2008 in seinem Beitrag „The New User Story Backlog is a Map“. Darin erklärte er, wie die Anwendung von User Story Mapping zu einem verbesserten Produkt-Backlog führt.
Ohne User Story Mapping erscheint das Product-Backlog als eine Sammlung von einzelnen und nicht in Beziehung stehenden Backlog-Items.
User Story Mapping ist eine Technik im Bereich der agilen Softwareentwicklung, die dabei hilft, das Produkt aus der Perspektive der Nutzer zu visualisieren und die zu entwickelnden Features zu planen. Die einzelnen User Stories (kurze Beschreibungen von Funktionen aus Sicht des Nutzers) werden in einen visuellen Kontext gebracht. Dies hilft, das Gesamtbild des Produkts zu verstehen und die Prioritäten festzulegen. Durch die Zuordnung auf verschiedene Release-Ebenen lässt sich leichter auch die Roadmap für die Entwicklung definieren.
Wenn Sie tiefergehende Informationen oder Beispiele benötigen, finden Sie hilfreiche Ressourcen auf Seiten wie Atlassian, Mountain Goat Software oder auch in entsprechenden Fachbüchern und Artikeln zur agilen Entwicklung.
Erste Erfahrungen und „Aha-Erlebnisse“
Vor einigen Jahren bot unser Forschungsprojekt SeReMo die Gelegenheit, das Vorgehen außerhalb eines Kundenprojektes zu erproben. Wir beschlossen, User Story Mapping in diesem Kontext einfach einmal auszuprobieren – und machten dabei Erfahrungen, die wir so nicht erwartet hatten.
Die erste User Story Map: Kreativität bis an die Grenzen und darüber hinaus
Nachdem wir uns den Ansatz von der theoretischen Seite intensiv angesehen und im Team besprochen hatten, starteten wir gespannt und hochmotiviert in das Abenteuer. User Story Mapping erfordert – wie der Scrum Prozess selbst – nicht zwingend ein Tool. Eine Wand und ein paar Stifte und Haftzettel genügen, um zu starten. Wir beschlossen, genau diesen Weg zu gehen, weil wir uns aus der gemeinsamen haptischen Arbeit an der Map einen Vorteil versprachen. Daher wurde als Erstes das Projektzimmer umgestaltet. Eine Wand wurde freigeräumt und mit Plakatpapier beklebt, um hier unserer User Story Map eine Heimat zu geben.
Stifte und zahlreiche Klebezettel in verschiedenen Farben wurden bereitgelegt und wir begannen mit dem Aufbau der Map. Unsere ideale Situation: alle Stakeholder und Teammitglieder konnten diese Phase gemeinsam durchleben, da unser Gesamtteam lediglich aus vier Personen bestand.
Die ersten User, Activities und Tasks wurden gesammelt und auf der Wand platziert. Die gemeinsame interaktive Arbeit an unserer Wand verlief ausgesprochen kreativ. Schnell mal eine Idee auf ein neues Post-it, die bestehenden Zettel kurz neu angeordnet – nochmal die Einwände diskutiert und die Zettel umsortiert … so stellt man sich agiles Arbeiten vor. Die Ideen sprudelten nur so.
Dann wurden uns sprichwörtlich erste Grenzen aufgezeigt: unsere Wand war nicht breit genug. Die verfügbare Fläche war schneller erschöpft als unsere Ideen. Also mal eben agil die Fläche erweitert und um das Eck herum die zweite Wand im Raum gekapert. Die hier stehenden (zum Glück geschlossenen) Schränke wurden einfach ebenfalls mit Plakatpapier überklebt. Schon hatten wir wieder ausreichend Raum für Kreativität. Kleiner Tipp am Rande: Die Übergänge zwischen den Schranktüren freilassen. Sonst lassen die sich nicht mehr öffnen (ist natürlich nicht uns passiert – hat uns ein Bekannter erzählt…). 
Nachdem wir unsere physischen Grenzen überwunden hatten, konnten wir unsere Map dann zu einem ersten Entwurf komplettieren.
Kein Backup – kein Mitleid
Am kommenden Morgen startete ich bei herrlichem Sommerwetter entsprechend gut gelaunt und hochmotiviert in den Tag. Gleich zu Beginn war ein Folgemeeting zur Verfeinerung und Ergänzung unserer User Story Map angesetzt. So machte ich mich auf den Weg zu unserem Projektzimmer. Die verschlossene Zimmertür irritierte mich kurz. Bei uns sind geschlossene Türen eher ungewöhnlich. Ich dachte mir aber nichts weiter – ein fataler Fehler!
Als ich die Tür öffnete, wurde ich vom spitzen Aufschrei der Kollegen begrüßt. Ich merkte schnell, dass es sich nicht um Freudenschreie wegen meines Erscheinens handelte. Die Kollegen sprangen wild durch den Raum. Entsetzt hechteten sie den wie Herbstlaub herumwirbelnden Klebezetteln unserer Story Map hinterher. Die Kollegen hatten die Fenster weit geöffnet, um durchzulüften. So wurde unser gerade neu gestartetes Projekt gleich mal sprichwörtlich durchgewirbelt. Wie meistens haben solche Ereignisse aber auch ihr Gutes – wir hatten dadurch gleich zwei wichtige Erkenntnisse:
1. Lüften kann Software-Projekte gefährden
2. Das Prinzip „kein Backup – kein Mitleid“ gilt auch für physische User Story Maps
Wir achteten ab diesem Tag auf regelmäßige Backups in Form einer Fotodokumentation der Story Map. Zudem hatten wir gelernt, dass Zettel nach häufigem Umhängen an Haftkraft verlieren und besser mal ausgetauscht werden.
Trotz initial fehlendem Backup unserer Wand ließ sich der Stand vom Vortag aber gemeinsam schnell rekonstruieren. Wir hatten die Zettel zügig wieder an Ort und Stelle. Schon mit der zweiten Kreativsitzung erreichten wir eine vollständige erste User Story Map. Unsere User, die Activities, Tasks und die wesentlichen Storys waren darauf gesammelt und durch die Anordnung in Beziehung gebracht.
Viel wichtiger als die nun vorliegende User Story Map war – wie so oft – aber der Weg dorthin. Der Prozess der Entstehung und die Kommunikation im Team waren hierbei ein riesiger Vorteil. Es wurden Ideen ausgetauscht, unterschiedliche Betrachtungsweisen diskutiert und gemeinsame Prioritäten festgelegt. Wir waren uns bereits sicher, dass wir auf dieser Basis ein stabiles gemeinsames Verständnis mit wenig Raum für Missverständnisse aufgebaut hatten.
Der Schritt zur Roadmap: plötzlich irgendwie ganz einfach
Im nächsten Schritt haben wir dann mehrere Release-Stufen definiert und als horizontale Swimlanes auf unserer Wand visualisiert. Die Stories auf unserer Story Map haben wir im Team gemeinsam priorisiert und den Release-Stufen zugeordnet. Dabei haben wir uns von der Überlegung treiben lassen, ein Minimal Viable Product (MVP) zu definieren. Dies war in unserem Fall zwar noch kein verkaufbares Produkt, versprach uns aber einen wesentlichen Erkenntnisgewinn für unser Forschungsprojekt.
Verglichen mit den Erfahrungen aus anderen Projekten erschien uns die Planung auf Basis der User Story Map überraschend einfach. Wir hatten bei den zu treffenden Entscheidungen stets das Gefühl, einen klaren Überblick zu haben. In unseren Diskussionen erkannten wir bestehende Abhängigkeiten zwischen den Stories. Wir fühlten uns sicher, nichts zu übersehen und eine konfliktfreie und konsistente Zuordnung auf die Release-Stufen vornehmen zu können. Auf der Map die große Vision als Ganzes wirklich sehen zu können, hat diesen Schritt massiv unterstützt.
Die tägliche Arbeit mit der Story Map
In der Entwicklung nutzten wir zusätzlich ein Scrum Tool, in dem wir unser Backlog parallel zur Story Map pflegten. In dieser Umgebung erhielten wir die übliche Unterstützung des Scrum Prozesses, z.B. durch eine detaillierte Sprint- und Taskplanung sowie aktuelle Burndown-Darstellungen. Die Story Map pflegten wir zusätzlich in der physischen Ausprägung.
Während der Entwicklung hielten wir unseren Daily Scrum sowie Planungsmeetings in der Regel vor unserer User Story Map ab. Wir empfanden das als ausgesprochen hilfreich. Unsere aktuellen Themen ließen sich direkt in den Gesamtkontext einordnen. Konsequenzen von Verschiebungen oder Planänderungen konnten wir unmittelbar erkennen und diskutieren.
Die Story Map wurde für uns schnell ein wertvolles Instrument. Sie half uns, im Team das gemeinsame Verständnis und unser Ziel nicht aus den Augen zu verlieren. Wir merkten, dass wir fundiertere Entscheidungen im Projekt treffen konnten.
Schnell erkannten wir, dass die User Story Map bei zu hoher Detailtiefe unhandlich wird. Daher begrenzten wir die Map auf einen gewissen Detaillierungsgrad. Die weitere Verfeinerung, etwa das Aufspalten von Stories, wurde ab dieser Ebene ausschließlich in unserem Scrum Tool vorgenommen. Dieses Vorgehen reduziert maßgeblich den Pflegeaufwand, ohne die notwendige Transparenz zu verlieren.
Hier gilt es, für jedes Projekt die passende Granularität zu wählen. Ziel sollte es sein, die Map so klein wie möglich, aber so groß wie nötig zu halten. Kleinere Maps sind überschaubarer und mit weniger Aufwand zu pflegen. Die Map muss aber natürlich ausreichend detailliert sein, um die gewünschte Klarheit zu schaffen und die Release-Planung ausreichend zu unterstützen.
Aus meiner Sicht gibt es hierzu kein klares Regelwerk. In unserem ersten und auch in allen weiteren Projekten hat sich das passende Level für die Map im Hinblick auf Projekt und Zielsetzung meist schnell intuitiv ergeben und eingeschwungen.
Unsere Take Aways - wie nutzen wir User Story Mapping heute und künftig?
Nach unserem initialen, internen Projekt haben wir das Vorgehen auch in diversen Kundenprojekten eingesetzt – insgesamt mit sehr guten Erfahrungen. Die physische Ausprägung der Story Map war für uns in unserem internen Projekt großartig. Durch den gestiegenen Remote-Anteil in unseren Teams ist dies aber kaum praktikabel. Zudem teilen sich in unseren Kundenprojekten eben nicht alle Projektbeteiligten die Räumlichkeiten.
Daher sind wir dazu übergegangen, User Story Maps eher in einer elektronischen Ausprägung und vor allem in zwei Stoßrichtungen zu nutzen:
Bei neu anlaufenden Projekten sehen wir hierin ein großartiges Instrument, um in Workshops mit den Stakeholdern gemeinsam die Vision zu entwickeln. Uns gelingt es dabei sehr schnell, ein gemeinsames Verständnis aller Beteiligten aufzubauen. Aufgrund der Vorgehensweise und der gemeinsamen Interaktion und Kommunikation erreichen wir beim Aufbau der Map bereits erstaunlich viel Klarheit.
Darüber hinaus nutzen wir die Story Maps bei länger laufenden Projekten, um gemeinsam mit unserem Kunden die längerfristige Roadmap aufzusetzen. Hierzu nutzen wir Story Maps auf einer gröberen Ebene. Den Detailgrad wählen wir so, dass alle Beteiligten die Elemente einfach erfassen und verstehen können. Gleichzeitig müssen natürlich alle für die Planung relevanten Aspekte ausreichend enthalten sein.
Die durch die Map geschaffene Transparenz zur Gesamtvision unterstützt den Abstimmungsprozess massiv. Warum wir viel Wert auf das Aufstellen einer Roadmap legen, lesen Sie in unserem Blog-Artikel „Software-Evolution: die Roadmap für Ihren Erfolg„.
Die bei uns eingesetzten Scrum-Tools unterstützen User Story Maps leider nicht.
Daher nutzen wir getrennte Visualisierungs-Werkzeuge wie z.B. Miro oder Mural. Zwar wäre die Integration in ein Scrum Tool ideal, aber es stellt sich dann u.a. die spannende Frage, wie der Detaillierungsgrad der Map bestimmt werden kann. Andererseits war unser Bedarf für eine erweiterte Tool-Unterstützung nicht so groß, dass wir hier aktiv nach einer Lösung gesucht hätten. Falls jemand hierzu eine Meinung oder Erfahrungen hat, sind wir für einen Kommentar zu diesem Artikel und mögliche Impulse dankbar.
Zusammenfassend finden wir die Nutzung von User Story Maps in vielen Projekte sehr hilfreich. Wir werden den Ansatz daher je nach Aufgabenstellung und Projekt weiterverfolgen.
2 Antworten
Sehr amüsanter Beitrag. Ich hatte schon immer den Verdacht, dass Frischluft für die meisten Software-Entwickler giftig ist 😉
Aber Scherz beiseite. Hilft denn der zweidimensionale Aspekt der Map auch noch bei einer sehr großen Anzahl an Tasks? Wie behält man da denn Überblick?
Ja – wir bereiten gerade Frischluft in Sprühflaschen vor, damit sich das besser dosieren lässt…
Zu Deiner Frage: Hier liegt aus meiner Sicht genau die Krux.
Ich fand einerseits gerade bei größeren Maps die Möglichkeit mit dem Team vor einer „haptischen Map“ zu stehen extrem hilfreich, weil man eben Zusammenhänge viel besser erkennt als in einem klassischen Backlog. Aber gerade die physische Ausprägung ist ab einer gewissen Größe zunehmend schwierig zu handhaben – wobei die Übersichtlichkeit nicht das Thema ist, eher Platzbedarf, Anzahl der Zettel die wegfliegen können etc.
Aus diesem Grund, aber auch wegen der gestiegenen Remote-Anteile in unseren Teams und der räumlichen Trennung zu unseren Kunden sind wir vermehrt auf elektronische Abbilder übergegangen – die werden am Bildschirm dann aber wirklich irgendwann unübersichtlich.
Daher unser Versuch einen guten Kompromiss zu finden: Wir nutzen StoryMaps eher zur Abstimmung mit den Kunden auf höherer, abstrakterer Ebene, um die Roadmap zu diskutieren. In diesem Fall sind die Maps nicht zu groß. Sie definieren eher das große Bild auf Epic-Ebene. Die Verfeinerung in die diversen Stories erfolgt dann wie üblich im Backlog des Scrum Tools. Die Map ist also eher die übergeordnete Struktur zu dem parallel im Detail gepflegten Backlog.
Das funktioniert aus meiner Sicht recht gut.