Agile Planung mit Story Maps

Sind Sie in einem Agilen Softwareentwicklungsprojekt schon einmal in die Verlegenheit gekommen…

sich zu fragen, wie Sie am besten:

  • Ihre Anforderungen organisieren?
  • die Geschäftsziele des Kunden im Blick behalten?
  • Zusammenhänge und Abhängigkeiten zwischen Anforderungen erkennen können?
  • die Aufgaben konkret priorisieren und die Umsetzungsreihenfolge bestimmen?
  • Ihr Produkt insgesamt planen?
  • den Status der Entwicklung und Releases visualisieren und planen?
  • mit verschiedenen Stakeholdern oder dem Entwicklungsteam übergreifend über Konzepte, Technik, Rahmenbedingungen etc. diskutieren?

Wenn Ihre beste, womöglich leicht gequälte Antwort darauf „Natürlich, mit Hilfe des Product Backlogs!“ lautet, kann ich Ihrem Leiden möglicherweise ein Ende bereiten! Es gibt hierfür ein großartiges Instrument: die Story Map bzw. das Story Mapping von Jeff Patton [1].

Beim Story Mapping handelt es sich um eine Technik für die Erarbeitung, Organisation und Release-Planung von Anforderungen in Agilen Projekten. Die Story Map ist eine kompakte, mehrdimensionale Darstellung eines Produkts, und begleitet die Entwicklungsarbeit permanent. Sie berücksichtigt und visualisiert dabei Faktoren wie:

  • die Umsetzungsreihenfolge und den zeitlichen Verlauf
  • die Priorität, Zusammenhänge und Abhängigkeiten von Anforderungen
  • unterschiedliche Granularitäten (User Story, Epic,, ggf. auch Thema)
  • unterschiedliche Rollen oder Personas

Im Kontext der Agilen Planung schafft eine Story Map den optimalen Übergang von der strategischen Ebene eines Produktes mit seinen Zielen, einer Produkt Vision, Lean Canvas, Unique Value Proposition etc. auf die taktische Ebene der Release Planung und der vermarktbaren Feature Sets. Diese können dann für die operative Ebene weiter in ein Produkt Backlog mit User Storys und eine Iterativ-inkrementelle Umsetzung überführt werden.

Aber wie funktioniert so eine Story Map, und wie wird sie erstellt?

Der Grundgedanke ist, ein gemeinsames Verständnis für die Produktidee und die vordringlichen Produktziele zu erarbeiten. Der Fokus liegt dabei auf der Identifikation und Eingrenzung des Nutzens und der relevanten Anwender mit ihren Aktivitäten und Aufgaben. So werden Geschichten erzählt, variiert, destilliert, weiterentwickelt und ausgearbeitet. Dann werden Cluster gebildet, priorisiert und spezifische Outcomes definiert, die dann zu konkreten Aufgabenpaketen führen. Diese gilt es nun iterativ-inkrementell zu verifizieren. So entstehen bspw. nach und nach und zielgerichtet Epics und User Storys, die dann in einem Product Backlog landen und abgearbeitet werden.
Dieses Vorgehen ist der Idealfall und ganz klar mein persönlicher Favorit. Oft wird aus verschiedenen Gründen aber nach Abkürzungen zu dem o.a. Vorgehen gesucht, bspw. wenn Produktidee und -ziele in den Köpfen der Kunden (vermeintlich?!) schon klar zu sein scheinen. Aber selbst dann kann man über eine Story Map mit den Anwendern im Hinterkopf das Produkt strukturieren, und Epics und User Storys erstellen.

Die initiale Erarbeitung einer Story Map erfolgt in Form von Workshops mit möglichst allen relevanten Stakeholdern, insbesondere mit allen Vertretern der fachlichen Domäne, die etwas zum Erkennen und Beschreiben der Fachlichkeit beitragen können.

Zu Beginn werden die relevanten Rollen bzw. Personenkreise identifiziert, die mit dem Produkt arbeiten sollen, und dafür ggf. Personas definiert. Anhand der Rollen werden dann die groben Anforderungen in Form von Epics erfasst. Diese Epics werden nebeneinander gelegt und bilden so die 1. Ebene eines 2-dimensionalen Diagramms (also die Spalten bzw. die X-Achse). Diese Achse reflektiert, von links nach rechts betrachtet, die gewünschte Umsetzungsreihenfolge der Epics. Die Position der Epics kann dabei vom Kunden auch im weiteren Projektverlauf „beliebig“ vertauscht werden, d.h., unter Berücksichtigung aller Konsequenzen, je nach Änderungszeitpunkt.

Im nächsten Schritt werden die Epics in vorgesehener Umsetzungsreihenfolge besprochen, konkretisiert und zu jedem Epic User Storys ausgearbeitet. Diese werden unter das jeweilige Epic gelegt und bilden damit die 2. Ebene des Diagramms (die Y-Achse). Diese Achse reflektiert von oben nach unten die absteigende Priorisierung – bspw. nach MoSCoW [2] – der User Storys je Epic, und kann vom Kunden analog zur Umsetzungsreihenfolge angepasst werden.

Beim Finden der Epics und User Storys in der Story Map wird vor allen Dingen Ausschau nach den zentralen Aktivitäten der User gehalten, die für das Produkt den Kern abbilden und am wichtigsten sind, ohne die das Produkt letztlich also nicht funktioniert. Diese Kernfunktionalität findet sich im Diagramm (auf der Y-Achse) immer ganz oben und (auf der X-Achse) tendenziell weiter links wieder. Sie steht im Fokus, auch der späteren Entwicklung, und sollte dabei so gut und weit wie möglich verstanden und durchdacht werden. Wie weit man initial in die Details geht und im Diagramm bei den Epics nach rechts in die Zukunft bzw. bei den User Storys nach unten in Richtung Optionalität schaut, ist letztlich freigestellt. Aber man sollte hier gerne Zeit investieren und nicht zu früh aufhören. Meine Empfehlung ist, zu Beginn als absolutes Minimum operatives Material für die ersten 4-5 Iterationen bzw. für das 1. Release zu erarbeiten, besser aber, für 2 oder 3 Releases. Eine effiziente agile Planung und Umsetzung kann natürlich bei Bedarf auf Veränderungen reagieren und das Vorgehen anpassen. Generell gilt es aber trotzdem vorausschauend zu arbeiten und einen Plan zu verfolgen, sich einen konzeptionellen Vorlauf zu erarbeiten und diesen zu erhalten. In einer Iteration arbeitet man idealerweise also an User Storys, die man sich nicht erst „gestern“ überlegt hat, sondern bereits „vorvorgestern“, vor ein paar Iterationen.

Im nächsten Schritt werden nun die gefunden User Storys aus der Story Map in ein Product Backlog überführt, wobei die Priorisierung übernommen wird. In der Folge können die User Storys in Feature Sets iterativ-inkrementell umgesetzt werden. Die Fertigstellung von User Storys wird dabei regelmäßig auch in der Story Map vermerkt, so dass der Entwicklungsfortschritt insgesamt zu erkennen ist.

Für die Planung bzw. Visualisierung von Releases wird in der Story Map unter der Achse der Umsetzungsreihenfolge eine horizontale Linie zur Kennzeichnung des Releases gezogen. Alle abgeschlossenen, darin enthaltenen User Storys verbleiben oberhalb der Release-Linie. Alle unfertigen oder nicht enthaltenen User Storys werden unter die Linie geschoben, und stehen als Material für nächste Releases zur Verfügung. Hier schließt sich ein Release-Zyklus, und ein neuer beginnt.

Eine Story Map adressiert also direkt oder indirekt die o.a. Fragestellungen: sie bietet einen Überblick über das gesamte Produkt, die Planung, den aktuellen Status und den Entwicklungsfortschritt. Sie eignet sich als Ausgangsbasis für die Organisation und Diskussion mit prinzipiell allen Stakeholdern über Inhalt, Umfang, Komplexität, Reihenfolge etc. von Anforderungen, aber speziell auch mit dem (Entwicklungs-)Team über technische Abhängigkeiten, Konzepte, Rahmenbedingungen etc.

Wichtig für den Spaß und den Erfolg der Arbeit mit Story Maps ist, dass sie im Projektverlauf regelmäßig aktualisiert und für die o.a. Zwecke im Idealfall als führendes Instrument eingesetzt wird. Es geht darum, die Story Map laufend mit der Realität abzugleichen und geplante oder ungeplante Veränderungen abzubilden, neue Epics und User Storys zu schreiben, vorhandene zu erweitern und überflüssige zu verwerfen etc.

Und noch ein letzter Tipp: lassen Sie bitte nicht zu, dass die Story Map bspw. vom Product Backlog permanent überholt oder gar abgelöst wird! Oder schlagen Sie Ihre Nägel tatsächlicher lieber mit dem Schraubenzieher in die Wand?!

Quellen:

[1]          http://jpattonassociates.com/user-story-mapping/

[2]          https://de.wikipedia.org/wiki/MoSCoW-Priorisierung


Der Autor

Fabrizio Scarpati

Fabrizio Scarpati

Technischer Berater