Story Maps – Selbsterklärende Product Backlogs

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
Um die kommende Story Map transportieren zu können, sollte man ein paar Flipchart-Blätter zusammenkleben und als Untergrund für die Map benutzen.

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.

Autor: Sven Röpstorff

Sven Röpstorff arbeitet freiberuflich als agiler Projektmanager und Coach mit über 16 Jahren Berufserfahrung. Mit seinen Teams probiert er gern neue Wege und Methoden, um sich und sein Umfeld stets weiter zu verbessern. In seinen Vorträgen und Workshops bringt er den Menschen agile Vorgehensweisen auf interessante und spielerische Weise nahe und macht sie somit sichtbar, fühlbar, erlebbar.

7 Kommentare

  1. Interessant. Nur: warum sollte man überhaupt Stories aufschreiben, die das “finale Produkt mit all seinen Komfortfunktionen” beschreiben, wie verhält sich dies zum Minimal Viable Product, was wenn man mit der Minimalversion lernt, dass die ganzen Stories, die man sich mal ausgedacht hat, gar nicht zum Ziel führen?

    I’m missing some #lean in this #agile! :)

  2. Moin Toby,

    vielen Dank für das Feedback. Es geht an dieser Stelle noch nicht um komplett durchdachte Stories, sondern um die Ideen, die Überschriften, das Visualieren der Vision. D.h. man verschwendet keine Zeit damit, Dinge zu beschreiben, die man möglicherweise später gar nicht umsetzt, sondern man schreibt lediglich die Ideen auf. Die Story Map ist nicht final, sie wird sich stetig ändern.

    Zum Minimal Viable Product (MVP): Ich halte mich hier an die Definition von Marty Cagan:
    “I have long defined minimum viable product as the smallest possible product that has three critical characteristics: people choose to use it or buy it; people can figure out how to use it; and we can deliver it when we need it with the resources available – also known as valuable, usable and feasible.”

    Die Bezeichnung „Walking Skeleton“ trifft am besten das, was die obersten Stories der Story Map beschreiben. Im Vergleich zum MVP wird man es in der Regel keinem Kunden anbieten, da es zwar „irgendwie“ funktioniert, aber noch nicht wirklich reif ist. Ein Walking Skeleton ist meines Erachtens ein Schritt auf dem Weg zu einem MVP.

  3. Bei einer OpenSpace-Session auf der ALE2011 Unconference im September hatten wir eine gute Diskussion über StoryMaps, die ich hier zusammengefasst habe: http://oldagile.blogspot.com/2011/11/storymaps-lets-talk-about-it.html
    Dabei haben wir über StoryMaps für einzelne Epics gesprochen, bei denen die horizontale Dimension die “Functions” des Epic darstellen und die vertikale Dimension, wie in deinem Beispiel die “Features”, von “Working Skeleton” über “can go live” (=MVP?) bis zu “Wow” (den Excitors).
    Der Fokus auf ein Epic ermöglicht dabei vielleicht ein Vorgehen, dass mehr #lean ist. Und die Klassifizierung der vertikalen Dimension kann zu Diskussionen führen, ob ein Feature “nice to have” ist oder doch zum “Working Skeleton” gehört.
    Je nach Anwendungsfall (“Big Picture für das nächste Halbjahr” versus “Wir verfeinern ein Epic”) haben wohl beide Ansätze ihre Berechtigung.

  4. Moin Christoph,

    vielen Dank für Dein Feedback und den Link. Du hast recht, man kann noch weiter ins Detail gehen und sogar Story Maps für einzelne Epics erstellen. Ich würde den Einsatz davon abhängig machen, wie “groß” die Epics hinsichtlich der Anzahl Stories sind.

    Mit dem Artikel wollte ich zunächst die Visualisierung des “Big Picture” und das Kommunikationspotenzial mit den Stakeholdern und dem Team auf Gesamtproduktebene aufzeigen.

  5. Hi Sven,
    ich habe ähnliche Erfahrungen gemacht in agilen Projekten, die ein nach Business Value priorisiertes lineares Product Backlog als Grundlage hatten. Mit dieser Darstellung stößt man sehr schnell an Grenzen, sobald ein System etwas größer wird. Mit deiner beschriebenen Darstellung lassen sich Anforderungen deutlich besser und vor allem übersichtlicher engineeren!
    Allerding stand in unserem Team immer auch die Frage im Raum nach der Abbildbarkeit in einem Tool, das sich in den Produkt- Entwicklungs-Lebenszyklus integriert und die Brücke zum Taskplannung bzw. zum Testing schlägt. Aus diesem Gedanken ist ein tool entstanden, das sich in JIRA als plug in integriert und damit auch Teil der Team Kollaboration wird und nicht nur dem Product Owner zur Verfügung steht. Aktuell gibt es nur wenig vergleichbare Werkzeuge, so dass sich ein Blick lohnen sollte: http://bauer-information-technology.com
    Danke+Gruß,
    Florian

    • Moin Florian,

      vielen Dank für den Kommentar. Ein Jira-Plugin für Story Maps klingt interessant, ich werde es mir mal ansehen. Wie ich sehe, gibt es auch eine Trial-Version. Besonders wichtig finde ich eine (zur Zeit in Greenhopper 6 leider nur sehr rudimentäre) Unterstützung von Epics bzw. der Beziehung zwischen Epics und Stories, mal sehen, wie ihr das abgebildet habt :)

      Viele Grüße,
      Sven

  6. Pingback: Slice me nice - Mit der Hamburger-Methode User-Storys erarbeiten Andrä AG labs