Zu Beginn und während der Softwareentwicklung ist eine der größten Herausforderungen, ein gemeinsames Verständnis über den geplanten Umfang der Lösung herzustellen. User Story Mapping ist eine der besten Methoden, um mit diversen Stakeholdern in den Austausch zu kommen und einen Überblick über die gewünschten Funktionalitäten des Ziel-Produkts zu erhalten. Dabei werden bei einem gemeinsamen Workshop alle Tätigkeiten (User Tasks), die die Nutzergruppe mit dem zukünftigen Produkt durchführen möchte, gesammelt. Durch die Visualisierung und Diskussion werden dadurch sehr schnell Abhängigkeiten zwischen den Funktionalitäten aufgedeckt. Weiter können Lücken in den Arbeitsprozessen erkannt und dann gemeinsam geschlossen werden. User Story Mapping kann initial bei der Produktentwicklung eingesetzt werden, aber auch später im Entwicklungsprozess hilfreich sein.
Zielsetzung
Am Ende des User Story Mappings werden die gefundenen Funktionalitäten gemeinsam priorisiert und es ist möglich, ein Minimum Viable Product (MVP) und ein Minimum Marketable Product (MMP) abzuleiten. Die Story Map sollte genau wie ein Product Backlog der ständigen Weiterentwicklung unterliegen, um das gemeinsame Verständnis zu schärfen.
Workshop vorbereiten
Für einen User Story Mapping-Workshop werden die relevanten Vertreter der Nutzer und weitere Stakeholder eingeladen. Wenn es sich um eine sehr große und komplexe Software handelt und mehr als 20 Leute an dem Workshop teilnehmen werden, empfehlen wir einige Vertreter für bestimmte Teilbereiche temporär einzuladen. Dies ermöglicht während des gesamten Workshops einen effektiven Austausch. Die Schwierigkeit ist hier, den richtigen Schnitt zu finden, damit alle wichtigen Perspektiven dabei sind und ein gemeinsames Verständnis füreinander und für das Produkt aufgebaut werden kann.
Da eine Story Map schnell sehr groß wird, sollten für den Workshop viele Klebezettel, Stifte und eine sehr große freie Wandfläche, bzw. Tisch- oder auch Fußbodenfläche eingeplant werden. Eine Alternative kann ein virtuelles Board sein. Der Workshop kann sich über mehrere Tage erstrecken, abhängig davon wie viele Personen teilnehmen und wie groß die Anwendung ist, die gemappt werden soll.
Abbildung 1: Workshop Situation
Aktivitäten sammeln
Zunächst werden die wichtigsten Aktivitäten gemeinsam gesammelt. Mit Aktivitäten sind Tätigkeiten gemeint, die ein typischer User in der zukünftigen Software durchführt. Für diesen Schritt bietet es sich an, vorher Personas zu erarbeiten und diese zu nutzen.
Zuerst werden auf einem sehr hohen Level Aktivitäten gesammelt und diese dann später nach und nach detaillierter heruntergebrochen. Die ersten Aktivitäten wären beispielsweise: Morgenroutine, Arbeitstag, Feierabend, Abendroutine.
Backbone & Body
Anschließend werden Aktionen für die Aktivitäten erstellt, wie beispielsweise: Aufstehen, Fertig machen, Frühstücken. Dieser detaillierte Bereich wird Backbone einer Story Map genannt.
Diese Aktionen werden in eine sinnvolle Reihenfolge von links nach rechts angeordnet, um eine Geschichte zu erzählen. Das heißt allerdings nicht, dass immer alle Schritte in genau dieser Reihenfolge durchlaufen werden. Manchmal werden bestimmte Handlungen übersprungen oder mehrfach ausgeführt, aber in der Geschichte, die zusammen durchgesprochen wird, ergibt diese Reihenfolge Sinn und hilft, Lücken zu finden und zu füllen.
Falls mit Personas gearbeitet wird, halten wir es für hilfreich, die Personas am linken Rand untereinander anzukleben und die jeweiligen Aktionen danach sequenziell zu sammeln und auf die passende „Persona-Zeile” zu kleben. Durch diese Visualisierung erkennt ihr gut, wer welche Aktion ausführt und bemerkt auch zu häufige Userwechsel im Prozess.
Die Sammlung dieser Aktionen könnt ihr auch als Brainstorming machen, anschließend in Aktivitäten bündeln und dann in die richtige zeitliche Reihenfolge bringen.
Danach wird der Body der Story Map erarbeitet, dieser enthält detaillierte User Tasks unter den jeweiligen Aktionen. Dies wären in unserem Beispiel vielleicht: Brötchen holen, Kaffee kochen, Tisch decken, essen, Tisch abräumen Bei dieser Verfeinerung werden auch Ausnahmen und alternative Pfade berücksichtigt.
Priorisierung
Am Schluss werden die einzelnen User Tasks priorisiert. Hierbei werden die User Tasks pro Aktion so angeordnet, dass die am höchsten priorisierten oben stehen.
Um eine Roadmap erstellen zu können oder deutlich zu machen, welche User Tasks zu einem Walking Skeleton oder einem MVP gehören, werden horizontale Linien eingezeichnet. Im Anschluss an den User Story Mapping Workshop sollten die hoch priorisierten User Tasks, also die, die oben” stehen, als erstes umgesetzt und daher zuerst mit Details und Akzeptanzkriterien zu User Stories ergänzt werden. Die unteren User Tasks werden erst später vertieft.
Abbildung 2: Grafik aus „Product Ownership meistern" von Frank Düsterbeck und Ina Einemann, dpunkt.verlag, S. 116
Unsicherheiten und Spikes
Es können auch Notizen, Blocker, Fragen etc. in die Story Map integriert werden. Diese sollten mit andersfarbigen Klebezetteln hervorgehoben werden.
Außerdem werdet ihr beim Story Mapping die ersten Unwägbarkeiten erkennen. Dies können z. B. Designvorgaben, prozessuale, technische oder fachliche Unsicherheiten sein. Hierfür sollten Spikes definiert werden. Bei einem Spike wird sich ein zeitlich fest begrenzter Rahmen gesetzt, um mit minimalem Aufwand mögliche Problemlösungen und eventuell weitere Probleme bei der Lösung erkunden zu können. Ihr versucht also so viel Unsicherheit wie möglich durch den Spike aus dem Problem zu nehmen.
Bei einer haptischen Story Map ist es hilfreich, wenn diese an einem Ort erstellt wird, wo sie hängen bleiben kann. Dann kann farblich markiert werden, was schon umgesetzt wurde. Das motiviert das Team. Alternativ könnt ihr die User Story Map abfotografieren und für spätere Diskussionen archivieren. Falls virtuell gearbeitet wurde, sollte die Story Map für alle zugänglich bleiben, um sie aktuell halten zu können.
Fazit
Story Mapping ist eine großartige Methode, um ein gemeinsames Verständnis zwischen den verschiedenen Stakeholdern aufzubauen und offene Fragen aufzudecken und zu klären. Das Wichtige am Story Mapping ist dabei, dass es nicht um das fertige Story Map-Artefakt an sich geht, sondern um die Gespräche und den Austausch während der Erstellung. Daher sollte die Auswahl der Teilnehmer gut überlegt sein.
Am Ende des User Story Mappings werden die gefundenen Funktionalitäten gemeinsam priorisiert und es ist möglich, ein Minimum Viable Product (MVP) und ein Minimum Marketable Product (MMP) abzuleiten. Die Story Map sollte genau wie ein Product Backlog der ständigen Weiterentwicklung unterliegen, um das gemeinsame Verständnis zu schärfen.
Workshop vorbereiten
Für einen User Story Mapping-Workshop werden die relevanten Vertreter der Nutzer und weitere Stakeholder eingeladen. Wenn es sich um eine sehr große und komplexe Software handelt und mehr als 20 Leute an dem Workshop teilnehmen werden, empfehlen wir einige Vertreter für bestimmte Teilbereiche temporär einzuladen. Dies ermöglicht während des gesamten Workshops einen effektiven Austausch. Die Schwierigkeit ist hier, den richtigen Schnitt zu finden, damit alle wichtigen Perspektiven dabei sind und ein gemeinsames Verständnis füreinander und für das Produkt aufgebaut werden kann.
Da eine Story Map schnell sehr groß wird, sollten für den Workshop viele Klebezettel, Stifte und eine sehr große freie Wandfläche, bzw. Tisch- oder auch Fußbodenfläche eingeplant werden. Eine Alternative kann ein virtuelles Board sein. Der Workshop kann sich über mehrere Tage erstrecken, abhängig davon wie viele Personen teilnehmen und wie groß die Anwendung ist, die gemappt werden soll.
Abbildung 1: Workshop Situation
Aktivitäten sammeln
Zunächst werden die wichtigsten Aktivitäten gemeinsam gesammelt. Mit Aktivitäten sind Tätigkeiten gemeint, die ein typischer User in der zukünftigen Software durchführt. Für diesen Schritt bietet es sich an, vorher Personas zu erarbeiten und diese zu nutzen.
Zuerst werden auf einem sehr hohen Level Aktivitäten gesammelt und diese dann später nach und nach detaillierter heruntergebrochen. Die ersten Aktivitäten wären beispielsweise: Morgenroutine, Arbeitstag, Feierabend, Abendroutine.
Backbone & Body
Anschließend werden Aktionen für die Aktivitäten erstellt, wie beispielsweise: Aufstehen, Fertig machen, Frühstücken. Dieser detaillierte Bereich wird Backbone einer Story Map genannt.
Diese Aktionen werden in eine sinnvolle Reihenfolge von links nach rechts angeordnet, um eine Geschichte zu erzählen. Das heißt allerdings nicht, dass immer alle Schritte in genau dieser Reihenfolge durchlaufen werden. Manchmal werden bestimmte Handlungen übersprungen oder mehrfach ausgeführt, aber in der Geschichte, die zusammen durchgesprochen wird, ergibt diese Reihenfolge Sinn und hilft, Lücken zu finden und zu füllen.
Falls mit Personas gearbeitet wird, halten wir es für hilfreich, die Personas am linken Rand untereinander anzukleben und die jeweiligen Aktionen danach sequenziell zu sammeln und auf die passende „Persona-Zeile” zu kleben. Durch diese Visualisierung erkennt ihr gut, wer welche Aktion ausführt und bemerkt auch zu häufige Userwechsel im Prozess.
Die Sammlung dieser Aktionen könnt ihr auch als Brainstorming machen, anschließend in Aktivitäten bündeln und dann in die richtige zeitliche Reihenfolge bringen.
Danach wird der Body der Story Map erarbeitet, dieser enthält detaillierte User Tasks unter den jeweiligen Aktionen. Dies wären in unserem Beispiel vielleicht: Brötchen holen, Kaffee kochen, Tisch decken, essen, Tisch abräumen Bei dieser Verfeinerung werden auch Ausnahmen und alternative Pfade berücksichtigt.
Priorisierung
Am Schluss werden die einzelnen User Tasks priorisiert. Hierbei werden die User Tasks pro Aktion so angeordnet, dass die am höchsten priorisierten oben stehen.
Um eine Roadmap erstellen zu können oder deutlich zu machen, welche User Tasks zu einem Walking Skeleton oder einem MVP gehören, werden horizontale Linien eingezeichnet. Im Anschluss an den User Story Mapping Workshop sollten die hoch priorisierten User Tasks, also die, die oben” stehen, als erstes umgesetzt und daher zuerst mit Details und Akzeptanzkriterien zu User Stories ergänzt werden. Die unteren User Tasks werden erst später vertieft.
Abbildung 2: Grafik aus „Product Ownership meistern" von Frank Düsterbeck und Ina Einemann, dpunkt.verlag, S. 116
Unsicherheiten und Spikes
Es können auch Notizen, Blocker, Fragen etc. in die Story Map integriert werden. Diese sollten mit andersfarbigen Klebezetteln hervorgehoben werden.
Außerdem werdet ihr beim Story Mapping die ersten Unwägbarkeiten erkennen. Dies können z. B. Designvorgaben, prozessuale, technische oder fachliche Unsicherheiten sein. Hierfür sollten Spikes definiert werden. Bei einem Spike wird sich ein zeitlich fest begrenzter Rahmen gesetzt, um mit minimalem Aufwand mögliche Problemlösungen und eventuell weitere Probleme bei der Lösung erkunden zu können. Ihr versucht also so viel Unsicherheit wie möglich durch den Spike aus dem Problem zu nehmen.
Bei einer haptischen Story Map ist es hilfreich, wenn diese an einem Ort erstellt wird, wo sie hängen bleiben kann. Dann kann farblich markiert werden, was schon umgesetzt wurde. Das motiviert das Team. Alternativ könnt ihr die User Story Map abfotografieren und für spätere Diskussionen archivieren. Falls virtuell gearbeitet wurde, sollte die Story Map für alle zugänglich bleiben, um sie aktuell halten zu können.
Fazit
Story Mapping ist eine großartige Methode, um ein gemeinsames Verständnis zwischen den verschiedenen Stakeholdern aufzubauen und offene Fragen aufzudecken und zu klären. Das Wichtige am Story Mapping ist dabei, dass es nicht um das fertige Story Map-Artefakt an sich geht, sondern um die Gespräche und den Austausch während der Erstellung. Daher sollte die Auswahl der Teilnehmer gut überlegt sein.
