Das Tool User Story Map ist sehr beliebt für die Darstellung von User Stories und der Abfolge von Userinteraktionen. Hierbei bietet es die Möglichkeit, User Workflows visuell und systematisch zu beschreiben. Die User Story Map unterstützt das Backlogmanagement und stellt Sachverhalte vereinfacht, visuell und transparent dar. Weiterhin kann es für die Definition des MVP (Minimal Viable Product) verwendet werden. User Story Map hat viele Stärken und einige Schwächen[1]. Speziell bei prozessualen Tasks, die ganzheitliche Prozesse aus einer Systemsicht über Anwendungsgrenzen hinaus beschreiben, können User Story Maps Grenzen in der Übersichtlichkeit bzw. Anwendbarkeit eine Herausforderung darstellen.
Ein Blick in die Toolkiste des klassischen Requirementsmanagements und der Geschäftsprozessmodellierung kann hier helfen. Für diese Darstellung wird traditionell das Modell einer Wertschöpfungskette verwendet[2]. Folgende Grafik gibt eine mögliche Darstellung eine User Story Map als Geschäftsprozess wieder:
Die oben dargestellte Grafik unterteilt die Geschäftsprozesse in diverse systemische Aktoren, welche durch die Swimlanes visualisiert wird. Weiterhin zeigt die Grafik, dass der Geschäftsprozess in diverse Prozessschritte zerlegt werden kann. Aufgrund der besseren Verständlichkeit wurde sich dafür entschieden, weitere Elemente aus der Ereignisgesteuerten Prozesskette (EPK)[3] zu verwenden. Währenddessen bei der oben gewählten Darstellung die Userinterkation in den Hintergrund tritt, tritt die Systeminteraktion in den Vordergrund. Bei dem oben gewählten Prozess gibt es tatsächlich nur eine User Interaktion am Anfang des Prozesses. Alles Weitere soll automatisiert ohne Benutzerinteraktion im System von verschiedenen Geschäftsprozessschritten in verteilten Anwendungen bearbeitet werden.
Jeder Prozessschritt ist in eine oder mehrere User Stories (US) unterteilt. Hierbei wurde darauf geachtet, dass die erste User Story bereits prototypisch den jeweiligen Prozessschritt ausfüllt. Weitere User Stories haben dann den jeweiligen Prozessschritt komplettiert. Weiterhin lässt sich erkennen, dass Prozessteile für den ersten MVP als „Out of Scope“ gekennzeichnet wurden. Folgende Tabelle zeigt, wie der zu entwickelnde Geschäftsprozess beispielhaft in einem Backlog aussehen kann:
| User Story | Sprint | Release Version |
|---|---|---|
| US1 | S1 | MVP |
| US3 | S1 | MVP |
| US4 | S2 | MVP |
| US5 | S2 | MVP |
| US6 | S2 | MVP |
| US2 | S3 | MVP |
| US10 | S3 | MVP |
| US7 | Not planned | Release Candidate 2 |
| US8 | Not planned | Release Candidate 2 |
Oben aufgeführtes Backlog versucht einen Querstich durch den Prozess als erste Hürde zu nehmen. Dies bedeutet, der Prozess funktioniert bereits End2End nachdem User Story 1-6 vollständig implementiert wurden. Weiterhin wurde bereits im ersten Sprint versucht darauf zu achten, dass der Prozess ausführbar ist. Auch wenn der Prozess unvollständig nach dem ersten Sprint ist, gibt dies bereits wertvolle Informationen und Feedback die für die weitere Entwicklung verwendet werden können. Weiterhin wird ersichtlich, aus welchen User Stories sich der MVP zusammensetzt und der logische Aufbau des Backlogs ergibt sich aus dem Zusammenhang mit der Prozessgrafik. Darüber hinaus werden US7, US8 bereits für zukünftige “Release Candidates” aufgeführt. Diese sind als eine weitere Automatisierungsstufe in dem zu entwickelnden Gesamtprozess angedacht.
Das Beispiel zeigt, dass es verschiedene Varianten gibt, um eine Visualisierung des Backlogs zu erreichen. Weiterhin können auch klassische Methoden des Requirementsengeneering mit agilem Backlogmanagement verbunden werden. Die gewählte Methode zur Visualisierung sollte nicht zu detailliert sein, da dies zu einem erhöhten Aufwand bei der Änderung durch neue Informationen und Feedback führt. Das Wichtige ist, dass die gewählte Methode für eine bessere Verständlichkeit des Backlogs sorgt, zu der Transparenz des Backlogs beiträgt und Abhängigkeiten innerhalb des Backlogs aufdeckt bzw. visualisiert. Dadurch kann das Selbstmanagement und Agilität gefördert werden und zu besseren Sprintergebnissen führen.
[1] Vgl. https://de.wikipedia.org/wiki/Ereignisgesteuerte_Prozesskette
[2] Vgl. https://www.it-agile.de/wissen/agiles-produktmanagement/story-mapping/
[3] Vgl. https://de.wikipedia.org/wiki/Wertsch%C3%B6pfungskettendiagramm
Leave a Reply