In den meisten Firmen findet man nach Business Value priorisierte Product Backlogs vor, wie Scrum es uns ja auch seit vielen Jahren gelehrt hat. Der aktuelle Scrum Guide vom Juli 2011 hat diese Anforderung etwas gelockert und spricht nun von Product Backlogs, die “oft nach Wert, Risiko, Priotität oder Notwendigkeit geordnet” sind. Wie auch immer, in beiden Fällen steht man vor der Herausforderung, komplexe Funktionalitäten in kleinere Einheiten herunterzubrechen und sie in einer eindimensionalen Liste anzuordnen. Zu einem bestimmten Epic gehörige User Stories bilden in der Regel keinen Block im Backlog, sondern sind weit verteilt und mit User Stories anderer Epics vermischt. Wie kann man seinen Stakeholdern ein rundes Bild des Produktes lediglich mit dem Product Backlog vermitteln? Oder es ihnen sogar einfach nur zum Lesen geben? Vor einiger Zeit hat sich Jeff Patton dieses Problems angenommen und die Idee der Story Maps hervorgebracht. Mit Story Maps kann man des ganze Produkt in einer kompakten Ansicht darstellen und es damit einfacher erklärbar und diskutierbar machen. Dieser Artikel stellt das Konzept der Story Maps vor.

Man braucht

• eine große freie Fläche (Wand oder Fußboden)
• Post-its wie man sie oft sowieso für User Stories benutzt

Erster Schritt

Zunächst zerlegt man sein Produkt in Epics. Sie werden auf Post-its geschrieben und in einer Reihe von links nach rechts an die Wand geklebt. Je weiter links ein Epic steht, desto eher sollte es implementiert werden. Es ist hilfreich, wenn man bei der Anordnung an den groben Workflow denkt, dem der spätere Benutzer des Produkts folgt.

Zweiter Schritt

Nun werden die Epics in User Stories heruntergebrochen. Die Stories werden einzeln auf Post-its geschrieben, die sich farblich von den Epics unterscheiden. Zu diesem Zeitpunkt sollte man nicht an Releases oder zu gruppierende Features denken, sondern sich einfach das finale Produkt mit all seinen Komfortfunktionen vorstellen, die möglicherweise implementiert werden sollen. Danach sollte die Wand in etwa so aussehen wie die Grafik rechts.

Jeff Patton vergleicht das resultierende Bild mit einer Wirbelsäule (“backbone”) und daraus hervorstehenden Rippen, daher hat sich für die Reihe mit den Epics der Begriff “Product Backbone” eingebürgert.

Dritter Schritt

Wenn alle Epics in User Stories zerlegt wurden, beginnt man mit der Priorisierung der Stories pro Epic. Dazu folgt man am besten dem MuSCoW-Prinzip (Must haves, Should haves, Could haves, Won’t haves) und ordnet die wichtigsten Stories am weitesten oben an. Für die Must haves sollte man eine andere Farbe der Post-Its wählen, da diese das sogenannte “Walking Skeleton” beschreiben. Dieser Begriff wurde von Alistair Cockburn geprägt, der ihn folgendermaßen definiert:

“A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.”

Mit dieser zweidimensionalen Story Map bekommt man einen Überblick über das gesamte Produkt. Sie bildet eine idele Ausgangsbasis für Diskussionen sowohl mit den Stakeholdern über den Umfang und die Business-Anforderungen als auch mit dem Team über technische Abhängigkeiten. Man überblickt das gesamte Produkt auf einen Blick und erkennt sofort, welche Funktionalitäten als erstes geliefert werden.

Wie jedes gute Product Backlog sollte auch die Story Map öffentlich sichtbar sein. Auf diese Weise wird man eine Menge Feedback bekommen und viele wertvolle Diskussionen werden vor der Wand stattfinden. 

Um das “Big Picture” nicht zu verlieren, werden Stories, die es in einen Sprint geschafft haben, nicht aus der Story Map entfernt, sondern in das Sprint Backlog dupliziert und in der Map markiert. Fertiggestellte Stories werden entsprechend als erledigt markiert.

Vor etwa anderthalb Jahren habe ich mit einer Gruppe von Product Owner gearbeitet und erstaunlicherweise sind wir auf eine ähnliche Idee gekommen wie Jeff mit den Story Maps. Niemand von uns kannte Story Maps, wir sind lediglich unserem Bauchgefühl gefolgt. Das Produkt war ziemlich komplex und wir haben sehr gutes Feedback sowohl vom Team als auch von den Stakeholdern bekommen, die eine derartig übersichtliche Darstellung sehr begrüßt haben.

Was habt Ihr für Erfahrungen damit, euer Produkt Leuten vorzustellen, die nicht täglich damit beschäftigt sind? Habt Ihr schon Story Maps benutzt? Kennt Ihr andere Methoden? Ich freue mich über Kommentare.