Ein Kurzer Leitfaden für die Durchführung von Story Mapping
Ein kurzer Leitfaden für die Durchführung von Story Mapping beantwortet die Fragen, die viele Unternehmen bei agilen Übergängen stellen. Wie kommen wir zu unseren Anforderungen? Wie sollen unsere Teams aufgebaut sein? In welcher Form liefern wir unser Produkt und welchen Wert liefert es dem Kunden? Story Mapping kann Antworten auf all diese Fragen liefern.
Inhaltsverzeichnis
Die Absichten und Ziele von Story Mapping
Das Ziel eines Story Mapping ist es, die Anforderungen an das Produkt, in Form von User Stories, den verschiedenen Releases des Produktes zuzuordnen. Hierzu werden die User Stories entsprechend ihrer Zugehörigkeit zu Aufgaben (Epics) und Aktivitäten (Domänen) sortiert und strukturiert.
Das Ergebnis eines Story Mapping ist eine gemeinsame Sicht aller Beteiligten auf die Struktur des Produktes, auf die Prioritäten und Umsetzungsreihenfolge der Anforderungen, als auch die Abgrenzung der verschiedenen Domänen zueinander. Anhand dieser Abgrenzung lassen sich dann die Produktteams etablieren.
Ein Einfaches Beispiel
Zur Erklärung und Verdeutlichung wie ein Story Mapping funktioniert wollen wir uns ein einfaches Beispiel wählen. Das zu entwickelnde Produkt soll es einer Person erlauben, nach dem Aufstehen am Morgen das Haus zu verlassen. Es müssen also Aktivitäten, Aufgaben und Tätigkeiten abgebildet werden die jemand vor dem Verlassen des Hauses durchführt. Die User Journey soll also die Handlungen abbilden, die ein Nutzer nach dem Aufstehen bis zum Verlassen des Hauses durchführt.
Definition von Nutzeraktivitäten
Der erste Schritt des Story Mappings ist die Identifikation von Aktivitäten welche der Nutzer mit dem zu definierenden Produkt ausführen kann. Dies ist eine klassische Aufgabe des Product Owners. Hierzu kann er die Stakeholder und potentielle Nutzer befragen, auf das Wissen von Business Analysten zurückgreifen und natürlich auch seine eigene Kreativität einbringen.
Die Aktivitäten beschreiben die Nutzerinteraktion auf einem sehr hohen Abstraktionslevel. So könnte eine Banking-App beispielweise die Aktivitäten „Konto verwalten“ oder „Depot verwalten“ enthalten. In unserem Beispiel ergeben sich die Aktivitäten „aufstehen“, „Körperfpflege ausführen“, „Frühstück einnehmen“ und „Haus verlassen“ als relevante Inhalte.
Identifikation von Nutzerhandlungen
In einem zweiten Schritt werden die indentifizierten Aktivitäten weiter verfeinert. Der Fokus liegt nun auf den Aufgaben welche sich im Rahmen der einzelnen Aktivitäten darstellen. Die Verfeinerung ist ebenfalls eine Aufgabe des Product Owners, in Absprache mit den Stakeholdern, potentiellen Nutzern, Sponsoren und Business Analysten. Die Aufgaben werden den einzelnen Aktivitäten auf einer untergeordneten Ebene zugeordnet. Diese Ebene wird auch als Backbone der Story Map bezeichnet.
Die User Journey lässt sich im Idealfall als Weg von links nach rechts durch die Story Map, und damit auch durch den Backbone, erzählen. Daher sollten die Aufgabe so sortiert werden, dass sie in eine natürliche Reihenfolge gebracht werden. Hierbei kann sich auch die Sortierung der Aktivitäten ändern und damit der beabsichtigten User Journey annähern.
In unserem Beispiel wurde jede Aktivität in drei Aufgaben verfeinert. Diese beschreiben die Aktivitäten in einem größeren Detaillierungsgrad. Die Ausführung dieser Aufgaben in der korrekten Reihenfolge wird den entsprechenenden Kundennutzen liefern. Im Beispiel wurde die Aktivität „Frühstück einnehmen“ in die Aufgaben „Radio hören“, „Kaffee trinken“ und „Müsli essen“ untergliedert.
Die definierten Aufgaben lassen sich im Anschluss des Story Mapping durch den Product Owner in Epics überführen. Diese Epics beschreiben einen komplexen, aber im Idealfall abgeschlossenen, Aufgabenblock im Sinne des agilen Requirements Engineering. Der ausformulierte Epic enthält dann eine ausführliche Beschreibung der angestrebten Funktionsweise, des Kundenmehrwertes und des Business Values.
Verfeinerung von Nutzerhandlungen
Nachdem die Aufgaben für das zukünftige Produkt definiert wurden gilt es nun diese noch weiter herunter zu brechen. Hierzu kann der Product Owner bereits das Development Team zu Rate ziehen. Es kann diese Aufgabe aber auch alleine durchführen. Die Detailierung der Aufgaben liefert die einzelnen Schritte welche nötig sind um eine Aufgabe abzuarbeiten.
Diese Teilaufgaben können nach dem Story Mapping in User Stories überführt werden. Hieraus leitet sich auch der Name der Vorgehensweise ab. Die User Stories beschreiben die durchzuführenden Handlungen aus Sicht des jeweiligen Nutzers, und motivieren gleichzeitig weshalb die Aufgabe durchgeführt werden soll.
In unserem Beispiel wurden die 12 definierten Aufgaben in insgesamt 42 Unteraufgaben zerlegt. Da es sich um ein sehr einfaches Beispiel handelt ist die Anzahl der Aufgaben und Unteraufgaben noch überschaubar. In der Praxis kann es leicht passieren, dass sich eine Vielzahl von Epics und daraus abgeleitet mehrere hundert User Stories ergeben. Bei einer Durchführung des Story Mapping in analoger Form ist es also notwendig ausreichend Platz udn Material zur Verfügung zu haben.
Identifikation von Abhängigkeiten
Im vierten Schritt ist es notwendig eventuelle Abhängigkeiten zwischen den einzelnen User Stories zu identifizieren. Spätestens an dieser Stelle muss der Product Owner das Develoment Team mit einbeziehen. Es gibt nicht nur fachliche Abhängigkeiten, sondern auch technische Abhängigkeiten. Diese können nur durch das Development Team sinnvoll bewertet und aufgelöst werden.
Unabhängig davon ob die Anforderungen in analoger oder digitaler Form erfasst werden ist es notwendig die Abhängigkeiten transparent zu machen. Im weiteren Verlauf dienen diese als Input für die Festlegung der Umsetzungsreihenfolge der verschiedenen Epics und User Stories. Eine User Story kann erst dann implementiert werden, wenn alle User Stories von denen sie abhängig ist bereits erfolgreich umgesetzt und abgeschlossen wurden.
Priorisierung von User Stories Nachdem die Abhängigkeiten der User Stories identifiziert wurden gibt es im Normalfall immer noch Freiheiten bezüglich einer möglichen Umsetzungsreihenfolge. In unserem Beispiel lässt sich dies gut an der Aufgabe „Bett machen“ erkennen. Es ist nicht wichtig ob man zuerst das Kopfkissen, oder zuerst die Bettdecke aufschüttelt.
Der Product Owner hat an dieser Stelle die Gelegenheit die Priorisierungswünsche der Stakeholder und Nutzer einfließen zu lassen und die User Stories unter Berücksichtigung ihrer Abhängigkeiten neu zu sortieren. Wichtig ist an dieser Stelle, dass User Stories die voneinander abhängig sind in der korrekten Reihenfolge bleiben.
Ein MVP Definieren
Wenn sich der Product Owner und das Development Team einig sind, dass die abgebildeten User Stories, Epics und Aktivitäten ausreichend verfeinert und beschrieben wurden, dann werden im letzten Schritt aus der Story Map die Funktionsumfänge der einzelnen Releases abgeleitet.
Das erste Release eines Produktes sollte immer eine Minimum Viable Product sein. Dies ist ein Produkt mit dem kleinsten, sinnvoll nutzbaren Funktionsumfang. Alle User Stories welche zur Lieferung dieses Funktionsumfangs notwendig sind werden dem MVP zugeordnet.
In weiteren Schritten definiert der Product Owner, unter Berücksichtigung aller externen Faktoren und der Abhängigkeiten und Prioritäten der User Stories weitere Releases. Hierbei sollte auch wieder Feddback des Development Teams bezüglich technischer Aspekte der Umsetzung berücksichtigt werden.
Im gezeigten Beispiel ergibt sich ein MVP welches das „Ankleiden“, „Schlüssel nehmen“ und „Haus verlassen“ umfasst. Mehr als die Erledigung dieser Aufgaben ist nicht notwendig um nach dem Aufstehen das Haus zu verlassen. Man kann sogar darüber diskutieren, ob es notwendig ist die Schlüssel mitzunehmen, oder ob dies nicht Teil des ersten Release sein kann.
Das unten stehende Bild visualisiert die User Journey entlang des MVP auf eine etwas andere Weise. Hierzu wurden die Aktivitäten optisch linear angeordnet, sodass besser zu erkennen ist wie sich der Nutzer entlang der User Stories von „links nach rechts“ bewegt. Alle weiteren Releases werden die User Journey erweitern. Dies kann durch Verlängerung der Aktionskette sein, durch Einführung paralleler Zweige und Handlungen, oder durch Etablierung völlig neuer Aufgaben. Es ändert sich aber nichts daran, dass sich die User Journey als Abfolge von Handlungen entlang der Story Map darstellen lässt.
Domänen Identifizieren und Teams Strukturieren
Im Rahmen agiler Transitionen ergibt sich oft die Frage nach der Struktur der einzelnen Entwicklungsteams. Welches Funktionalität soll von welchem team umgesetzt werden? Wo sind die Grenzen der Teams und der Funktionsblöcke? Was ist der Aufgaben- und Funktionsbereich der einzelnen Product Owner.
Diese Fragen lassen sich anhand einer Story Map intuitiv beantworten. Die definierten Aktivitäten bilden jeweils einzelne Domänen im Sinne der Produktstruktur ab. In unserem Fall könnte man die Aktivitäten auch nach ihrem Aktionsort Schlafzimmer“, „Badezimmer“, „Küche“ und „Hausflur“ betiteln. Dies sind die einzelnen Domänen des Produktes.
Die Teams sollten so strukturiert werden, dass sie eine Domäne vollständig umsetzen und abbilden können. Es ist auch möglich, dass ein Team für mehr als eine Domäne verantwortlich ist. In diesem Fall sollten die Domänen idealerweise „benachbart“ sein. So lassen sich klar definierte Schnittstellen zwischen den verschiedenen Domänen definieren und die Verantwortlichkeiten für Funktionen eindeutig den jeweiligen teams zuordnen.
Abschließende Gedanken
Das Story Mapping sollte im Idealfall in analoger Form, mit Hilfe von Post-Its durchgeführt werden. Dies erlaubt einen hohen Interaktionsgrad zwischen den Teilnehmern, als auch eine hohe Dynamik bezüglich der Strukturierung und Entscheidungsfindung während des Story Mapping. Da eine Story Map sehr groß werden kann, sollte schon bei der Planung eines Story Mapping darauf geachtet werden einen Ort mit ausreichend freiem Platz an den Wänden zu wählen.
Story Mapping ist eine hervorragende Technik um Anforderungen in agilen Teams zu erfassen, zu strukturieren und in eine Release-Planung zu überführen. Die User Journey lässt sich entlang der Story Map abbilden, und aus der Struktur der Story Map lässt sich die Struktur der crossfunktionalen Teams ableiten. Die so gewonnenen Informationen erzeugen eine gemeinsame Sicht aller Beteiligten auf das Produkt und reduzieren die Abhängigkeiten zwischen Teams.
