Story Mapping

Story Maps - Landkarten für das Product Backlog

Story Mapping ist eine Technik, mit der ausgehend von der User Experience das Big Picture der Anforderungen übersichtlich dargestellt werden kann. Dabei bleibt stets der Kundenfokus erhalten.

Story Mapping beginnt mit den User Tasks; den Aufgaben, die aus Benutzersicht zu erledigen sind. Diese User Tasks ordnen wir horizontal sequenziell so an, dass sie eine nachvollziehbare Geschichte (Story) ergeben. Wir streben keine formale Modellierung an. Sicher werden User Tasks auch mal in einer anderen Reihenfolge ausgeführt oder bestimmte User Tasks entfallen in einer bestimmten Situation komplett.

Haben wir viele User Tasks nebeneinander, gruppieren wir User Tasks nach Aktivitäten (Activities).

Unterhalb der User Tasks listen wir Details auf. Story Mapping spricht von Sub-Tasks. Über die Sub-Tasks können auch Varianten der Ausführung von User Tasks abbilden. So entsteht das Big Picture der Aufgabe, die vor uns liegt. Damit haben wir eine gute Basis, um Releases zu planen. Unsere Überlegungen starten wir mit der wichtigsten Wirkung, die wir mit unserem Produkt erzielen wollen. Für diese Wirkung suchen wir den Ausschnitt aus der Story Map, der dafür notwendig ist und kommen so zum notwendigen Release-Umfang.

Releaseplanung mit Story Maps

Unten findet sich eine Story Map für einen Walking Skeleton einer Smartphone-App, um Arbeitszeiten zu erfassen. Ein Walking Skeleton ist eine rudimentäre Version, die als Ausgangsbasis für die weitere Entwicklung dient. Man kann es auch als das erste Minimum Viable Product betrachten. – Die gelben Karten repräsentieren Benutzeraufgaben (user tasks), die ein Benutzer mit Hilfe des Systems erledigen möchte, die grünen Karten repräsentieren die jeweils dazu gehörigen Arbeitsschritte oder Tätigkeiten (sub tasks).

In dem Beispiel der Zeiterfassung sähe das im Moment so aus: Der Benutzer legt das Datum fest, dann die Start- und Endzeit, dann die Tätigkeit und schließlich gegebenenfalls einen Kommentar. Danach schickt er den Eintrag ab, schließlich kontrolliert und korrigiert er ihn eventuell. Das ist eine plausible Beschreibung des Ablaufs, um Arbeitszeiten zu erfassen.

In der vertikalen Dimension bilden Story Maps die Priorität ab, mit der das zu entwickelnde System einzelne Arbeitsschritte unterstützt. Einen Großteil der Arbeitszeiten tragen Mitarbeiter ohne erklärenden Kommentar ein. Darum ist es wichtiger, die Zeiten und die Tätigkeit einzutippen als einen Kommentar. Ebenfalls ist eswichtiger, überhaupt eine Arbeitszeit mit der mobilen Zeiterfassung eintragen zu können, als die richtige Zeit einzugeben. Kann der Mitarbeiter die Eintragung gar nicht vornehmen, nützt auch die komfortabelste Eingabemöglichkeit für die Zeit nichts, vgl. das Workflow Pattern zum Zerkleinern von User Stories [3].

Einsatzmöglichkeiten
Es liegt nah, die vertikale Dimension einer Story Map, die Priorisierung, zu nutzen, um Releases zu definieren, indem man Anforderungen nach Priorität gruppiert.
In der Abbildung ist eine Story Map zu sehen, die zwei Releases definiert. Sie sind durch das Kreppband optisch abgegrenzt.

Story Map mit zwei Releases bei e-velopment in Hamburg.

Diese Technik kann ein Product Owner unabhängig von der gewählten Releasestrategie nutzen. Veröffentlicht er neue Produktversionen zu festen Zeitpunkten, repräsentiert eine Schicht in der Story Map den aktuell anvisierten Umfang. Zum Beispiel veröffentlicht Canonical jeweils im April und Oktober eines Jahres eine neue Version von Ubuntu. Die enthaltenen Veränderungen liegen erst zum Auslieferungszeitpunkt fest. Bei einem solchen Vorgehen empfehle ich Ihnen, die Anforderungen innerhalb der Schicht konsequent zu priorisieren, um sicherzustellen, dass die wertvollsten Veränderungen zuerst umgesetzt und ausgeliefert werden.Man kann Releases aber auch nach Funktionalitäten schneiden. Google Mail geht regelmäßig so vor, zum Beispiel mit der kürzlichen Vereinheitlichung des Interfaces für Emails und Kontakte: Eine Menge fachlich zusammen hängender Veränderungen wird erst ausgeliefert, wenn sie eine bestimmte Reife erlangt hat. Bei dieser Strategie empfehle ich Ihnen, Releases nach möglichst kleinen sinnvollen Ausbaustufen zu definieren: Liefern Sie so früh wie möglich aus. So bekommen Sie früher Feedback und Ihre Investitionen machen sich früher bezahlt. Verschieben Sie Komfortfunktionen und andere Accessoires, wenn möglich, auf später. Die Schichten einer Story Map repräsentieren genau solche Ausbaustufen: so klein wie möglich, so groß wie nötig. Um die Story Map für mehrere Releases einfacher zu halten, kann man auch darauf verzichten, die Anforderungen innerhalb der Schicht zu priorisieren.Analog zu der zuerst vorgestellten Releasestrategie, bei der man mit festen Zeitrahmen arbeitet, kann man Story Maps zur Planung von Sprints verwenden. Dann repräsentiert eine Schicht der Story Map einen Sprint. Man kann auch weitere Schichten definieren, die eine Vorausschau auf die nächsten Sprints geben.Tätigkeiten in einer Story Map, die der Planung mehrerer Releases dient, werden zwangsläufig grobgranularer sein als Tätigkeiten einer Story Map, die zur Planung von Sprints für ein Release dient. Dort findet man nur Epic Stories und Themes. Hier weit oben in der Priorität auch User Stories – entsprechend dem Prinzip, dass die Items eines Backlogs einen angemessenen Detailgrad aufweisen sollten [4].

Ein Product Owner hat auch die Möglichkeit, auf die Priorisierung innerhalb einer Story Map weitgehend zu verzichten und sich stattdessen auf die andere Dimension, den Arbeitsfluss eines Benutzers, zu konzentrieren. Eine solche Story Map verschafft in erster Linie Überblick über den Funktionsumfang eines Systems und unterstützt die fachliche Diskussion über das System. Sie kann auch Grundlage für eine Schätzung des Gesamtsystems darstellen und als Ausgangsbasis für spätere Verfeinerungen, zum Beispiel die Planung von Releases, dienen.
Bei entsprechendem Abstraktionsniveau der Tätigkeiten kann eine Story Map ein sehr umfangreiches System beschreiben.

Diese Story Map bei e-velopment beschreibt fachlich vollständig das Lagerverwaltungssystem eines Versandhändlers.

Kontinuierlich gemeinsam mit der Story Map arbeiten

Aus der bisherigen Darstellung könnte man schließen, einzig der Product Owner hätte mit einer Story Map zu tun, schlimmer noch: Er könnte sie unter Verschluss halten. Mitnichten!
Ein Product Backlog ist nur so gut, wie es allen am Software-Entwicklungsprozess Beteiligten – sowohl dem Fachexperten als auch dem Umsetzungsteam – hilft, gemeinsames Verständnis über das zu entwickelnde Produkt herzustellen. Fehlt es, entstehen über flüssige Funktionen und die benötigten nützen weniger, als sie könnten. So bleibt das Produkt hinter seinem Wertschöpfungspotenzial zurück. Scrum-Teams erzeugen kontinuierlich gemeinsames fachliches Verständnis über das System. Im Anforderungsworkshop klärt das Scrum-Team, ob die Stories für den kommenden Sprint ausreichend gut verstanden sind und wie sie überprüft werden können. In der Sprint-Planung werden User Stories mit Blick auf das Sprint-Ziel ausgewählt. Das Scrum-Team arbeitet zusammen; das Umsetzungsteam unterstützt den Product Owner. Im Sprint-Review überprüft das Scrum- Team gemeinsam – im Idealfall mit Anwendern und Stakeholdern –, ob das entwickelte Produktinkrement die Bedürfnisse der Benutzer befriedigt, und generiert Ideen, wie das Produkt dies noch besser könnte.
An all diesen Stellen reflektiert das Scrum-Team das Product Backlog und an all diesen Stellen kann es sich Story Maps zunutze machen: Wie passt die User Story in den idealisierten Arbeitsfluss eines Benutzers, was sind angrenzende Aufgaben? Betrifft die Story auch Aufgaben früher oder später im Arbeitsfluss? In welchem Release ist die Funktionalität gut aufgehoben? Da ist es nur konsequent, die initiale Map nicht nur mit Stakeholdern wie Anwendern und Geldgebern, sondern auch schon mit dem Umsetzungsteam zusammen zu erstellen.
Wir empfehlen, die Story Map stets gut sichtbar im Arbeitsbereich des Teams aufzuhängen. Das erleichtert ihre kontinuierliche Pflege und gewährt schnellen Zugriff für fachliche Diskussionen.

Welche Vorteile bietet Story Mapping?

  • Fokus auf User Experience und die Wirkungen, die wir für die Kunden erzielen wollen.
  • Minimierung von Release-Umfängen.
  • Übersichtliche Darstellung des Big Picture.
  • Gutes Instrument, um miteinander ins Gespräch zu kommen.

Tipps fürs Story Mapping

  • Erstelle Story Maps in Workshops mit relevanten Stakeholdern und Teammitgliedern.
  • Benutze Post-Its.

Unser Angebot zu Story Mapping

  • Wir schulen Story Mapping in unseren Product Owner-Schulungen.
  • Wir moderieren Story Mapping-Workshops.
  • Wir beraten inhaltlich dabei, wie Releases möglichst schlank geschnitten werden können.

Treten Sie mit uns in Kontakt.

Literatur

  1. Jeff Patton, 2005. It’s all in how you slice it. www.agileproductdesign.com/presentations/user_story_mapping/index.html
  2. Jeff Patton, 2008. The new user story backlog is a map. www.agileproductdesign.com/blog/the_new_backlog.html
  3. Richard Lawrence, 2009. Patterns for splitting user stories. www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/
  4. Roman Pichler, 2010. Making the product backlog DEEP. www.romanpichler.com/blog/2010/02/making-theproduct-backlog-deep/
  5. Jeff Patton: "User Story Mapping: Discover the Whole Story, Build the Right Product", O'Reilly and Associates, 2014.

it-agile dankt der Firma e-velopment für die Zusammenarbeit und die Genehmigung zum Abdruck der Story Maps.