Ich habe wieder mal einen Blogbeitrag der t2informatik gelesen, diesmal zum Thema „user story mapping„. Es ist ein Werkzeug das ich auch gerne im Team verwende, um größere Features, oder ein ganzes Produkt zu visualisieren. Wie im Beitrag vermerkt, führt die gemeinsame Arbeit am Whiteboard oder der Moderationswand zu einem besseren Verständnis aller Beteiligten.
Ich starte hierbei meistens auf der „grünen Wiese“ (oder mit der leeren Leinwand) und lege zunächst die Epics fest. Da es oft um die Realisierung von Geschäftsprozessen geht, sind die Epics meist in ihrer Reihenfolge von links nach rechts deckungsgleich mit dem Prozess. In einem vereinfachten Beispiel: Daten erfassen => Information verarbeiten => Ergebnis präsentieren. Mit der Orientierung am Geschäftsprozess stelle ich gleichzeitig sicher, dass der Zweck der Lösung am Ende erreicht wird. Der steht nämlich i.d.R. als Akzeptanzkriterium des letzten Epic fest.
Zusätzlich sollte jede Storymap mit Persona ergänzt werden. Wer sind denn die AnwenderInnen? Verknüpfe ich dies wieder Quer mit Geschäftsprozess-Modellierung, dann wird die Sache klarer. Und hier kommen wir zur zweigleisigen Verwendung der User Story Map zur Auftragsklärung.
Auch mit den „Stakeholdern“ verwende ich gerne die User Story Map. Eben um „top down“ den Geschäftsprozess zu zerlegen. Wenn ich dies allerdings mit Managern oder anderen nicht-IT Personen tue, dann zerlege ich den anfänglich groben (vielleicht als Chevron dargestellten) Prozess in Unter-Prozesse und nutze dazu BPMN2.0 (https://de.wikipedia.org/wiki/Business_Process_Model_and_Notation). Hier fühlen sich Prozessmanager oft mehr zu Hause. Gleichzeitig hilft dies die Prozesse auf „swimlanes“ aufzuteilen, die Rollen im Prozess repräsentieren – und damit habe ich meine Persona auch schon mal ganz gut definiert.
Ich verwende also aus der Prozessanalyse und Auftragsklärung die Elemente die ich mit BPMN2.0 erstellt habe wieder, um damit eine Story Map für das Entwicklungsteam aufzubauen. Die Prozess-Aktionen werden somit zu Stories und Beschreiben „wer brauch was und warum“. Da sie über den Prozess bereits in einem Kontext stehen, können auch leicht Akzeptanz-Kriterien gefunden werden und der Abgleich mit der Persona erfolgen.
Und zum Schluss noch das Feedback zum Auftraggeber. Haben wir nun im Team eine Story Map mit Priorisierungen und einer groben Sprint- und/oder Release-Planung, dann lässt sich dies auch Verständlich dem Auftraggeber präsentieren, da ja die gleichen Beschreibungen/Überschriften wie im Prozess-Modell verwendet wurden.
Michael's Blog 