Was ist 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 (Activitys).

Unterhalb der User Tasks listen wir Details auf. Story Mapping spricht von Subtasks. Über die Subtasks 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.

Wie unterstützt uns diese Technik?

Diese 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.

Wie funktioniert Story Mapping?

Release-Planung 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 (Subtasks).
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 es wichtiger, ü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 Storys [3].

Einsatzmöglichkeiten von Story Maps

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.

Diese Technik kann ein Product Owner unabhängig von der gewählten Release-Strategie 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 empfehlen wir, 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 E-Mails und Kontakte: Eine Menge fachlich zusammen hängender Veränderungen wird erst ausgeliefert, wenn sie eine bestimmte Reife erlangt hat. Bei dieser Strategie empfehlen wir, 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 Release-Strategie, 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 Storys und Themes. Hier weit oben in der Priorität auch User Storys – 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.

Gibt es einen Hauptverantwortlichen für die Story Map?

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 es, ein gemeinsames Verständnis über das zu entwickelnde Produkt herzustellen. Fehlt es, entstehen überflü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 Storys für den kommenden Sprint ausreichend gut verstanden sind und wie sie überprüft werden können. Im Sprint Planning werden User Storys 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 und 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.

Zum Abschluss

Tipps für Story Maps

Erstelle Story Maps in Workshops mit relevanten Stakeholdern und Teammitgliedern (siehe auch: Value Poker).
Benutze Post-Its.
Story Map gut sichtbar im Arbeitsbereich des Teams aufhängen.
Die Story Map kann Grundlage für die Schätzung des Gesamtsystems sein.
Nutzen Sie Story Maps zur Hilfe bei Releaseplanungen.

Literatur

Jeff Patton, 2005. It’s all in how you slice it. https://www.jpattonassociates.com/wp-content/uploads/2015/01/JPA_how_you_slice_it.pdf
Jeff Patton, 2008. The new user story backlog is a map. https://www.jpattonassociates.com/the-new-backlog/
Richard Lawrence, 2009. Patterns for splitting user stories. https://agileforall.com/patterns-for-splitting-user-stories/
Roman Pichler, 2010. Making the product backlog DEEP. https://www.romanpichler.com/blog/make-the-product-backlog-deep/
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.

Über den Autor

Urs Reupke

Urs hat weit über 15 Jahre Erfahrung mit Agilität gesammelt und gelernt, dass Führung, Prozess und Produkt Hand in Hand gehen müssen, damit das Ergebnis stimmt. Heute gibt er diese Erfahrung weiter und hilft Unternehmen aller Größen, elegante Lösungen für ihre Probleme zu finden.

Veröffentlichungen:

Mehr von Urs Reupke

Möchten Sie mehr erfahren?

Tauschen Sie sich mit unseren Expert:innen aus und lassen sich zu Schulungen, Coaching oder Wissensthemen beraten.

+ 49 40 4135 848-0 info@it-agile.de Online Termin buchen

Kennen Sie eigentlich schon it-agile?

Die Expert:innen zu agiler Arbeit und agilen Methoden

Kund:innen wollen begeistert werden. Mit innovativen Produkten, durch Schnelligkeit, Transparenz und auch Verlässlichkeit. Unsere erfahrenen Agile Coaches sorgen gemeinsam mit Ihren Teams und Führungskräften dafür, auch in komplexer Umgebung Ihre Ziele nicht aus dem Auge zu verlieren und implementieren die richtigen agilen Methoden für nachhaltige Veränderung.

Wir integrieren Pragmatismus mit Idealismus
Wir befähigen Sie nachhaltig ohne Abhängigkeit von uns
Wir erzeugen Kundenfokus mit wirkungsvoller Agilität

Lernen Sie uns kennen

agile review

Unser Kundenmagazin

In unserem Magazin stellen wir Artikel rund um agiles Arbeiten für Sie zusammen. Das Spektrum reicht von methodischen Themen wie Scrum und Kanban über Agile Leadership bis hin zu technischen Aspekten wie agilem Testen und flexiblen Architekturen.

Als Abo oder Einzelausgabe erhältlich
Digital oder Print
Einzelne Artikel sofort digital verfügbar

Mehr erfahren