Remote User Story Mapping

 

Um es gleich vorwegzunehmen: Wenn man die Möglichkeit hat, ein User Story Mapping in Form eines Workshops vor Ort durchzuführen, dann ist dies immer die beste Wahl. Wir bei Chrono24 glauben fest daran, dass Teams ihre besten Ergebnisse erzielen, wenn sie persönlich zusammenarbeiten können – “Team is where the magic happens!” Da dies aber nicht immer möglich ist, möchte ich heute meine Erfahrungen mit virtuellen User Story Mappings teilen. Sie sind weitaus positiver, als es die ersten Sätze vielleicht vermuten lassen.

 

Was ist ein User Story Mapping?

 

Das User Story Mapping ist eine Methode zur Konzeption von Produkten, die den späteren Nutzer und seine Bedürfnisse in den Mittelpunkt stellt. Das Ergebnis eines User Story Mappings ist die User Story Map. Sie beinhaltet alle Anforderungen, die an ein Produkt gestellt werden, und setzt sie in einen Kontext. Die Methode eignet sich besonders dann, wenn man das Gesamtbild eines Produktes erzeugen möchte.

 

Was brauche ich für ein (virtuelles) User Story Mapping?

 

Eigentlich braucht man für ein User Story Mapping nicht viel außer einer großen Menge Post-its, ein paar Stifte, ein bisschen Klebeband und einer freien Wand, die nie lange genug sein kann. Eigentlich. Die aktuelle Situation hat uns dazu gezwungen, eine Alternative zu den Post-its und Bürowänden, die wir so lieben, zu suchen. Auch in diesem Fall hieß die Lösung: Miro-Board.

Wie eingangs erwähnt ist ein Workshop, in dem ein Team zusammen vor Ort arbeitet, durch nichts zu ersetzen. Digitale User Story Mappings haben aber auch viele Vorteile: So muss man nicht die ganze Zeit vor der Wand stehen, die heruntergefallenen Post-its wieder aufheben und rätseln, wo diese denn mal gehangen haben könnten. Auch verwackelte Bilder zu Dokumentationszwecken, bei denen man nur raten kann, was auf den einzelnen Post-its steht, gehören damit endlich der Vergangenheit an. Des Weiteren kann man eine digitale User Story Map ohne großen Aufwand mit anderen Kollegen teilen. Frei nach dem Motto: Bring die User Story Map zum Meeting, statt das Meeting zur User Story Map. Und abschließend sei gesagt, dass die Ressourcen eines digitalen Boards schier unerschöpflich sind.

Ich empfehle zudem, die Moderation des User Story Mappings an einen Scrum Master zu übergeben. Sie haben oft ein feines Gefühl dafür, was eine große Gruppe braucht, um erfolgreich zusammenarbeiten zu können und achten darauf, dass auch jeder im Team zu Wort kommt. Gerade bei virtuellen Meetings in großen Gruppen ist dies häufig ein Problem. Außerdem sind sie begnadete Timebox-Manager.

Ein weiterer wichtiger Punkt ist, dass die Teilnehmer des User Story Mappings möglichst viele verschiedene Unternehmensbereiche vertreten. Die unterschiedlichen Sichtweisen von Marketing, Produkt, Sales, UX oder auch Data sorgen dafür, dass ein Produkt aus allen wichtigen Perspektiven durchdacht wird.

 

Wie erstelle ich eine User Story Map?

 

Im Folgenden möchte ich nun auf die einzelnen Schritte zur Erstellung einer User Story Map eingehen. Um das Ganze ein wenig greifbarer zu machen, habe ich versucht, mit einem einfachen Beispiel den Entstehungsprozess zu verdeutlichen. Ich habe mich dabei für ein Problem entschieden, das unseren rudimentärsten Bedürfnissen entspringt und jeder nachvollziehen kann: Hunger! Das Beispiel ist deshalb eine App zur Bestellung von Pizza.

 

1. Den Nutzer und sein Problem beschreiben

 

Im ersten Schritt wird das Problem des Nutzers vorgestellt. Am wertvollsten ist es natürlich, wenn ein echter Nutzer sein Problem beschreibt, sodass die Teilnehmer des Workshops es aus erster Hand erfahren. Besonders bei der Konzeption von unternehmensinternen Produkten kann dies leicht realisiert werden, da die Nutzer in diesem Fall die eigenen Kollegen sind. Ist es nicht möglich, dass ein echter Nutzer sein Problem beschreibt, können hier auch Personas, die einen typischen Nutzer beschreiben, zum Einsatz kommen. Wenn das zu lösende Problem klar ist, sollte noch darüber nachgedacht werden, ob es verschiedene Nutzergruppen gibt, die von diesem Problem betroffen sind und ob man diese klar definieren kann.

“Fall in love with the problem” – Das Team sollte sich für den gesamten Schritt wirklich Zeit nehmen, da ein tiefes Problemverständnis einen starken Einfluss auf die Qualität des Ergebnisses hat. Erst wenn alle das Problem verstanden und durchdrungen haben, sollte mit dem nächsten Schritt begonnen werden.

 

2. Die Aufgaben des Nutzers zur Lösung des Problems sammeln

 

Der zweite Schritt hat zum Ziel, das Problem des Nutzers in kleine Teile zu zerlegen. Man versucht deshalb die einzelnen Aufgaben zu sammeln, welche der Nutzer absolvieren muss, um das gesamte Problem zu lösen. Eine Aufgabe hat dann die richtige Größe, wenn sie eine abgrenzbare Einzelaufgabe, die ohne Unterbrechung abgeschlossen werden kann, darstellt. Ist eine Aufgabe größer als diese Definition, sollte sie in mehrere kleine Aufgaben aufgeteilt werden. Ist eine Aufgabe kleiner, ist es sinnvoll, sie mit anderen Aufgaben zu einer größeren Aufgabe zusammenzufassen.

Es ist hierbei zu empfehlen, die Aufgaben in stiller Einzelarbeit zu sammeln und sich die Ergebnisse anschließend gegenseitig vorzustellen und zu clustern.

 

3. Die Aufgaben in die richtige Reihenfolge bringen / einen narrativen Fluss erzeugen

 

Im dritten Schritt werden dann die kleinen Aufgaben in die Reihenfolge gebracht, in der sie der Nutzer durchlebt. Man bezeichnet diese Reihenfolge auch als narrativen Fluss. Wurden am Anfang mehrere Nutzergruppen definiert, so sollte man diese den einzelnen Aufgaben zuweisen, um deutlich zu machen, wer wann welche Aufgabe erfüllen muss. Es kann passieren, dass die Reihenfolge in der Praxis nicht ganz trennscharf ist, da bspw. manche Aufgaben parallel erledigt werden. Dies ist nicht weiter schlimm. Wichtig ist nur, dass sich am Ende dieses Schrittes die ganze Gruppe auf die Reihenfolge committen kann.

 

4. Die Aufgaben zu übergeordneten Aktivitäten zusammenfassen

 

Im vierten Schritt werden zusammenhängende Aufgaben nochmal zu übergeordneten Aktivitäten zusammengefasst. Dieser Schritt dient der Übersichtlichkeit, indem er mehrere kleine Aufgaben in größeren Aktivitäten bündelt, die i.d.R. auch als Ganzes vom Nutzer bearbeitet werden. Hier können dann auch die im ersten Schritt definierten Nutzergruppen zugeordnet werden. Das Ergebnis dieses Schrittes, also der strukturierte narrative Fluss des Nutzers, wird als Backbone einer User Story Map bezeichnet.

 

5. Alternative Lösungswege für die einzelnen Aufgaben sammeln

 

Der fünfte Schritt ist meiner Meinung nach der spannendste. Während vorher mehr das Verstehen und Visualisieren des Nutzerproblems im Vordergrund stand, wird es hier endlich kreativ: Der Fokus liegt nun auf dem Sammeln von möglichst vielen unterschiedlichen Lösungswegen, die es dem Nutzer ermöglichen oder erleichtern, eine Aufgabe abzuschließen. Es bietet sich deshalb an, die einzelnen Aufgaben systematisch durchzugehen und sich bei jeder Aufgabe die Frage zu stellen, welche unterschiedlichen Möglichkeiten es gibt, sie zu lösen. Die Ergebnisse dieses Schrittes, also die unterschiedlichen Lösungswege, stellen die Anforderungen an das Produkt dar. Sie werden als der Body einer User Story Map, der am Backbone hängt, bezeichnet. Die einzelnen Lösungswege können ohne größere Umstände als User Stories formuliert werden und sind deshalb auch für die spätere Verarbeitung in einem Scrum Team sehr gut geeignet.

In diesem Schritt habe ich die Erfahrung gemacht, dass es durchaus sinnvoll sein kann, die User Story Map aufzusplitten und die einzelnen Aktivitäten auf Kleingruppen zu verteilen. Besonders bei sehr ausführlichen User Story Maps hilft diese Form der Arbeitsteilung, um in einem angemessenen Zeitrahmen ein gutes Ergebnis zu erzielen. Mit einer kleinen Gruppengröße von drei bis vier Personen habe ich dabei die besten Erfahrungen gemacht. Es bietet sich hier an, dass die kleinen Gruppen in ein eigenes Meeting oder in Breakout-Sessions gehen und erst am Ende wieder in der großen Gruppe zusammenkommen, um ihre Ergebnisse zu präsentieren.

 

6. MVP definieren / Swimlanes bilden / Priorisieren

 

Im sechsten und letzten Schritt werden die einzelnen Lösungswege priorisiert und anschließend ein MVP definiert. Dadurch soll sichtbar werden, welche Anforderungen die dringlichsten sind und deshalb zuerst umgesetzt werden sollten. Hier bietet es sich an, sogenannte „Swimlanes“ zu bilden, welche die einzelnen Anforderungen umfassen. Dadurch erhält die User Story Map eine klare Struktur, die auch zur Releaseplanung verwendet werden kann. Dieser Schritt sollte in der ganzen Gruppe stattfinden, um bei der Priorisierung möglichst viele Perspektiven zu berücksichtigen.

 

Mein Fazit

 

Ein virtuelles User Story Mapping kann zu großartigen Ergebnissen führen. Neben einer guten Organisation des Workshops erfordert dies aber auch eine hohe Disziplin aller Beteiligten, um die Nachteile von virtuellen Meetings zu überwinden. Abschließend möchte ich erwähnen, dass eine User Story Map kein Konzept ist, welches einmal erarbeitet wird und danach als abgeschlossen gilt. Vielmehr lebt es von der permanenten Veränderung durch die Einbeziehung von neuen, in der Entwicklung gesammelten Erkenntnissen. Es ist deshalb wichtig, dass Scrum Teams die User Story Map in ihren Alltag integrieren, vielleicht sogar als vollwertiges Backlog – „Now go, be a hero!“

 

Referenz

Jeff Patton – User Story Mapping: Discover the Whole Story, Build the Right Product