Story Map versus Geschäftsprozessmodell

von | 18.03.2019 | Requirements Engineering

User Story Mapping

Story Maps sind cool: In einer Dreiviertelstunde können Sie gemeinsam mit einem kleinen Team von Stakeholdern einen Geschäftsprozess ausführlich analysieren. Dabei gehen Sie in folgenden Schritten vor:

  1. Zuerst sammeln Sie die während des Geschäftsprozesses durchzuführenden User Stories auf Zetteln. (Oft wird auch von Tasks gesprochen, aber das ist irreführend, weil Tasks die Aufgaben bezeichnen, die die Programmierer durchführen, um die User Stories umzusetzen.) Am besten verwenden Sie die schon vorhandenen Product Backlog Items.
  2. Dann ordnen Sie die User Stories an einer Wandtafel oder auf einem Tisch in eine zeitliche Reihenfolge von links nach rechts an, um den „narrativen Fluss“ des Geschäftsprozesses zu erhalten. Manche nennen dies auch „Customer Journey“.
  3. Danach überlegen Sie sich alternative Abläufe. Gibt es Ausnahmen? Fehler- und Sonderfälle? Eine Überholspur? Der normale Ablauf steht oben, die Varianten werden darunter angeordnet. Je weiter oben eine User Story klebt, umso wichtiger.
  4. Dann fassen Sie User Stories, die gemeinsam ausgeführt werden, zu Aktivitäten (oder Epics oder Features) zusammen. Die Aktivitäten werden auf einen andersfarbigen Zettel geschrieben und geben der Story Map eine Struktur, das „Backbone“ (deutsch: Rückgrat). Optional werden den Aktivitäten Benutzergruppen zugeordnet
  5. Zuletzt gruppieren Sie die User Stories nach Ziel (Outcome) in waagrechte Spuren. Diese Outcomes können auch als Grundlage für Release Slices oder Sprint Backlogs dienen, also diejenigen User Stories zusammenfassen, die gemeinsam implementiert werden sollen.

Beschrieben ist hier ein Bottom-up-Vorgehen. Genauso wie die Geschäftsprozessanalyse, die sowohl die Richtung bottom-up vom Feinen zum Groben kennt als auch umgekehrt, kann auch die Story Map in beide Richtungen aufgebaut werden. Sie könnten also auch mit den Aktivitäten beginnen.

Geschäftsprozessmodellierung

Das klingt nun sehr nach einer Geschäftsprozessanalyse, bei der ja ebenfalls die auszuführenden Funktionen von links nach rechts angeordnet, um parallele Sonderfälle angereichert und Benutzern zugeordnet werden. Wird uns da also von der agilen Community alter Wein in neuen Schläuchen aufgetischt?

Ja und nein. Bei aller Ähnlichkeit bestehen einige entscheidende Unterschiede:

  • Interaktivität: Während bei der klassischen Geschäftsprozessanalyse ein Berater das digitale Modell des Prozesses mit dem Laptop und Beamer an die Wand wirft und jede Änderung, die jemand vorschlägt, von ihm als Gatekeeper bewertet und über die Tastatur umgesetzt wird – oder auch nicht – kann beim Story Mapping jede/r einen Zettel und Stift in die Hand nehmen und mitwirken. Jede/r kann seinen Vorschlag sofort umsetzen, darstellen und miteinander diskutieren.
  • Einfache Notation: Grafische Geschäftsprozesse im UML-Aktivitätsdiagramm, EPK, BPMN oder Flussdiagramm verwenden eine eigene Notation. Auch wenn diese mit relativ wenig Elementen auskommen, fühlt sich der Nichteingeweihte gehemmt und wagt kaum, Fragen zu stellen. Beim Story Mapping muss man nur wenige Grundsätze kennen: Die Zeit verläuft von links nach rechts, User Stories und Aktivitäten haben unterschiedliche Farben. Dies ist leicht zu verstehen.
  • Arbeitsplanung: Story Map und Product Backlog sind nur zwei verschiedene Anordnungen derselben Inhalte, nämlich der umzusetzenden User Stories. Gleichzeitig dienen sie verschiedenen Zwecken: Das Story Mapping analysiert den Geschäftsprozess auf Vollständigkeit, Reihenfolgen und Prioritäten, das Product Backlog steuert die Arbeitsplanung. Man sagt auch, die Story Map diene als „Landkarte“ für das Product Backlog, denn sie verleiht diesem eine thematisch sortierte mehrdimensionale Struktur. Dadurch kann die Story Map noch besser als das Backlog die Arbeitsplanung unterstützen. Beispielsweise könnten Sie alle User Stories, die zu einem bestimmten Outcome (Ziel) beitragen, für die Umsetzung im nächsten Sprint vorsehen. Die User Stories können Sie 1:1 ins Sprint Backlog übernehmen und abarbeiten. Es gibt keine Übersetzungsarbeit zwischen Geschäftsprozessmodell und Projektstrukturplan bzw. Arbeitspaketen wie im klassischen Projektmanagement. Die Story Map ist der Projektstrukturplan, die User Stories sind die Arbeitspakete.

Die agile Welt hat also die Geschäftsprozessanalyse nicht neu erfunden, aber so modifiziert, dass sie leicht zu verstehen ist, sich nahtlos in die Arbeitsplanung integriert und auch Anwender sich daran beteiligen können. Das gemeinsame Story Mapping macht sogar Spaß.

Varianten, Alternativen und Deatails beim Storymappen

Zum Weiterlesen und für alle, die ihn auf der REConf nicht live erlebt haben:

Jeff Patton: User Story Mapping – Die Technik für besseres Nutzerverständnis in der agilen Produktentwicklung. O’Reilly Verlag, 2015

https://jpattonassociates.com/wp-content/uploads/2015/03/story_mapping.pdf

Mehr über Dr. Andrea Herrmann erfahren Sie auf Ihrer Website: http://www.herrmann-ehrlich.de/