Zum Thema User Story Mapping gibt es ein über 300-seitiges Buch von Jeff Patton, welches spannend, aber auch sehr lange zu lesen ist. Dieser Beitrag gibt einen Überblick über das Thema, fasst die wichtigsten Eckpunkte zusammen und zeigt auf, wie wir die Methode des User Story Mappings bei internezzo anwenden.
Es war einmal eine Idee für ein Web- oder Software-Projekt. Die Schwierigkeit in der Anfangsphase solcher Projekte ist häufig, herauszufinden, was nötig ist, um aus der Idee ein nutzbares Produkt zu entwickeln. Wenn an dem Projekt mehrere Personen oder gar Teams aus verschiedenen Firmen beteiligt sind, ist eine Auslegeordnung sehr wichtig, damit alle Beteiligten das gleiche Verstehen und in die gleiche Richtung arbeiten. Hier setzt die Methode des User Story Mappings an und gibt dieser Auslegeordnung eine Struktur.
The problem with software development: pic.twitter.com/DzvPkB91e1
— John Ferguson Smart (@wakaleo) 19. April 2017
Das grosse Ziel ist es, gemeinsam möglichst die schraffierte Fläche zu definieren, um anschliessend fokussiert darauf hin zu arbeiten und sich nicht von anderen Dingen ablenken zu lassen. Denn nur die schraffierte Schnittmenge aus "benötigten" und "gelieferten", also fertig entwickelten Features bringt den benötigten Wert für das Projekt, häufig Business Value oder Return on Invest genannt.
Die Teilnehmer
Wer an einem halb- oder ganztägigen Workshop dabei sein soll, ist immer etwas tricky. Als Dienstleister können wir z. B. selten bereits in der Konzeptionsphase die Entwickler an einen solchen Workshop mitnehmen. Denn zu dem Zeitpunkt ist noch gar nicht klar, wer in der Realisationsphase effektiv involviert sein wird.
Sicher dabei sein sollten aber die Stakeholder und der Projektleiter sowie im Idealfall jemand von der technischen Seite. Im Kontext von internezzo heisst dies, dass ein bis zwei Vertreter des Kunden dabei sind, ein Projektleiter und ein Entwickler. Die Zusammensetzung variiert natürlich abhängig vom Projekt und wird jeweils situativ gewählt. Wichtig ist, dass jemand des Auftraggebers am Workshop teilnimmt, der den Business Value sowie die Abhängigkeiten versteht und abschätzen kann - und auch Entscheidungen bei der Priorisierung treffen kann.
Als gute Grösse hat sich ein Team von 4 bis 6 Teilnehmern gezeigt. Einerseits ist es wichtig, genug unterschiedliche Sichtweisen einzubringen – andererseits ist die Entscheidungsfindung schwieriger, je grösser der Teilnehmerkreis ist.
Vorbereitung
Im Normalfall gibt es schon vor dem Workshop eine grobe Projektbeschreibung. Idealerweise erhalten die Workshop-Teilnehmer diese Unterlagen frühzeitig und machen sich vorgänging bereits Gedanken zum Projekt.
Für den Workshop selbst braucht es nicht allzuviel Equipment: Ein Sitzungszimmer und je nach Wunsch ein grosser Tisch, eine grosse Whiteboard-Tafel oder eine freie Wand. Dazu noch Filzstifte und viele (!) Kärtchen in verschiedenen Farben.
Falls selbstklebende Post-Its verwendet werden, empfehle ich die "Super Sticky" Variante zu nehmen. Insbesondere wenn das Resultat über Tage oder Wochen hängen bleiben soll. Ebenfalls hat sich ein kleiner Snack in Form von Früchten und genug Getränken direkt im Sitzungszimmer bewährt – und ab und zu eine Pause und frische Luft. Dann kann eigentlich fast nichts mehr schief gehen.
Vorgehensweise
Beim User Story Mapping geht es ganz stark vereinfacht darum, die Aufgabe "wir entwickeln das Produkt X" in Teilbereiche zu zerlegen. Dabei ist es nicht wichtig, Details wie z. B. Farbe und Position jedes einzelnen Buttons zu definieren, sondern etwas grobkörniger die einzelnen funktionalen Bestandteile zu erkennen.
Grundsätzlich kann dies von einer einzelnen Person erledigt werden. Das Ziel eines Workshops ist aber, gemeinsam im Team das Projekt durchzusprechen und dabei die Kärtchen zu erstellen und zu sortieren. Der grosse Vorteil ist, dass so alle ein möglichst genaues Bild erhalten, was die Anforderungen an das zu erstellende Produkt sind. Im Gegensatz zum rein schriftlichen Verfassen dieser Anforderungen, werden Unklarheiten direkt besprochen. So minimiert sich auch das Risiko, dass es zu Missverständnissen kommt.
Schritt 1: die offensichtlichen Funktionen
Nehmen wir als Beispiel das fiktive Projekt «Online-Shop für Feuerwehr-Material»: Wie jeder andere Online-Shop wird auch dieser Shop offensichtliche und für den Endbenutzer nutzbare Funktionen anbieten:
- Produkt-Auflistung
- Detail-Ansicht eines Produkts
- Warenkorb
- User-Login
- Bestellung
Dann benötigt dieses System sicherlich auch die Möglichkeiten, dass der Betreiber die Produkt-Daten pflegen und die Bestellungen einsehen kann. Beispielhaft dafür sind folgende Funktionen:
- Admin-Login
- Produkt-Auflistung sehen
- Produkt erstellen
- Produkt ändern
- Rabatte / Aktionen erstellen
- Kunden-Konten erstellen
- Kunden-Konten einsehen
- offene Bestellungen auflisten
- Bestellungen als erledigt markieren
Die ersten Kärtchen entstehen
Im ersten Schritt notiert jeder Workshop-Teilnehmer für sich die offensichtlichen zu erwartenden Funktionen auf Kärtchen. Dabei entsteht zwangsläufig eine gewisse Redundanz und die Dubletten werden im nächsten Schritt aussortiert. Diese Vorgehensweise hat trotzdem einen entscheidenen Vorteil: Ein Feature, welches von allen Anwesenden notiert wurde, kann als zwingend notwendig angesehen werden. Damit muss es – ohne grosse weitere Diskussion – bereits in der ersten Version des Produkts integriert werden. Zudem haben wir gesehen, dass einzelne Teilnehmer Funktionen und Themen notieren, welche sie aus ihrem Blickwinkel als relevant erachten. Diese sind, auch wenn nur einmal genannt, wichtig und im nächsten Schritt in der Diskussion zu berücksichtigen.
Unsortierte Kärtchen am Anfang des Workshops.
Der Begriff «User Story»
Eine kurze Rand-Notiz: In der agilen Software-Entwicklung gibt es den Begriff «User Story». Diese unterliegt einer sehr starken Norm und soll möglichst immer gleich aufgebaut werden. Ein Beispiel: «Als Kunde möchte ich einen Artikel in den Warenkorb legen können, um diesen später zu kaufen». Eine User Story enthält damit also immer
- die Information wer etwas tut, meist ausgedrückt als Rolle (z.B. als Neukunde, als Newsletter-Abonnent, als Administrator etc.)
- die Information zur Funktion, die ausgeführt werden soll (z.B. Newsletter abonnieren, Preis anpassen etc.)
- die Intention dazu, weswegen diese Funktion ausgeführt werden soll
Der Begriff «User Story Mapping» implizierte zumindest für mich am Anfang, dass wir mit Kärtchen hantieren die immer komplette User-Stories enthalten. Dies ist aber nicht nötig, wie wir im nächsten Schritt gleich sehen werden: Halten Sie die Kärtchen einfach und knapp, ein «Artikel in Warenkorb legen» ist genug.
Je kürzer und einfacher die Kärtchen zum jetzigen Zeitpunkt gehalten sind, desto einfacher und praktischer sind sie für die weitere Arbeit.
Schritt 2: Gruppieren und Sortieren
Das Resultat aus der ersten Runde sollten mehrere Kärtchen sein, auf denen Themen oder Funktionen stehen wie oben angesprochen. Im nächsten Schritt geht es darum, diese in eine gewisse Struktur zu bringen.
Am praktikabelsten finden wir, die Kärtchen aus Sicht des Benutzers in der Reihenfolge der vorzunehmenden Aktionen auszulegen. Also von der Produkt-Suche über den Warenkorb zum Checkout - und nicht umgekehrt.
Karten eines Aktions-Strangs, chronologisch sortiert
Gruppen bilden
In vielen Fällen ergibt sich daraus relativ schnell eine Gruppierung nach Funktionen. So lassen sich Funktionen im Bereich Produkt-Suche und Darstellung zusammennehmen und die Funktionen Warenkorb und Checkout in eine weitere Gruppe. Für diese Gruppierung werden Spalten gebildet und die einzelnen Funktionen einsortiert. Geben wir diesen Spalten eine Überschrift, haben wir bereits die ersten Epics – also die Hauptbestandteile erkannt und dargestellt.
Sortieren
Die Priorisierung der einzelnen Kärtchen und Features erfolgt innerhalb der Spalten durch die Reihenfolge der Kärtchen: Das Wichtigste zuoberst, darunter in absteigender Reihenfolge alle weiteren Kärtchen. So ist z. B. die Freitext-Suche nach Produkten gerade bei einem Shop mit geringerer Anzahl an Kategorien und Produkten nicht Prio 1, sondern eher ein Nice-to-Have. Der Shop könnte auch ohne diese Suchfunktion funktionieren.
Wir haben in den vergangenen Workshops gesehen, dass das Thema Reihenfolge/Priorisierung häufig bereits intuitiv erfolgt – und dies häufig schon ziemlich präzise für den ersten Wurf.
Jetzt ist der richtige Zeitpunkt, die Priorität bewusst noch einmal zu prüfen und wo nötig Kärtchen innerhalb der Spalte neu zu ordnen.
Versteckte Anforderungen
Wie wir bei Schritt 1 gesehen haben, gibt es nicht nur die Endbenutzer-Funktionalitäten, sondern häufig auch noch weitere Benutzergruppen mit anderen Bedürfnissen und Funktionen. Ebenfalls als «Nutzergruppe» gelten automatisch erfolgende Funktionen wie ein automatisierter nächtlicher Import oder Aufbereitungsprozess. Zudem besteht eine weitere Dimension an Anforderungen, die häufig zu spät berücksichtigt werden: Die nicht-funktionalen Anforderungen. Diese stellen selbst keine Funktion im Sinne eines Features bereit – sind aber für den Projekt-Erfolg dennoch sehr wichtig. Beispiele für nicht-funktionale Anforderungen sind die Performance, die Verfügbarkeit, die Sicherheit und je nach Interpretation das Design.
Die einzelnen Spalten lassen sich bei Bedarf noch weiter gruppieren. Ob dies die erwähnten Nutzergruppen resp. Rollen sind oder ein anderes passendes Kriterium, ist am Ende nicht match-entscheidend. Solches wird im Workshop projektabhängig erkannt und definiert. Das Resultat könnte im Groben etwa so aussehen:
Karten, gruppiert nach Benutzer-Rolle
Um hier das Thema der User Story noch einmal kurz aufzugreifen, denn so schliesst sich hier unter Umständen der Kreis wieder: Angenommen die oberste Gruppierung ist aktuell die Benutzergruppe resp. Rolle, dann kann jedes einzelne Kärtchen anhand seiner Position nun einer Rolle, einer Intention und der auszuführenden Funktion zugewiesen werden. In diesem Fall hätten wir wieder die Informationen einer User Story zusammen – ohne aber auf jedem einzelnen Kärtchen ganz viel Text geschrieben zu haben.
Schritt 3: Kärtchen-Tuning und Visionen
Der jetzt folgende Schritt verfeinert das Produkt, in unserem Fall die zu entwickelnde Software, weiter. Dazu ergänzt das Projektteam im gemeinsamen Gespräch bestehende Kärtchen mit Kommentaren und Stichworten, teils auch aufgeteilt in unterschiedliche Kärtchen.
Falls die Flughöhe momentan noch sehr hoch ist, ist dieser Schritt womöglich noch etwas zu früh. In diesem Fall werden die Kärtchen zu einem späteren Zeitpunkt diskutiert und verfeinert.
Schritt 4: Die magische Linie zum MVP
Nach der Diskussion sollten nun an der Wand mehrere Spalten voller Kärtchen sein, sortiert nach deren Priorität. Doch soll oder muss die komplette Funktionalität entwickelt werden?
In der Regel sind bis zu diesem Zeitpunkt bereits einige Kärtchen mit Kommentaren wie «das brauchen wir noch nicht von Anfang an» oder «das hier ist Prio 2» versehen. Häufig ist auch die Rede von Nice-to-Have-Features oder einer Aufgabe für die Ponyhof-Liste. Aufgaben und Funktionen, welche dieser Kategorie zugeordnet werden, stehen nun bereits im unteren Teil der Spalten und sind damit tief priorisiert.
Priorisierung der Karten durch Unterteilung in Must-Have-Features des Produktes - und allem anderen (der Ponyhof-Liste)
Das Minimum viable Product, MVP
Widmen wir uns jetzt noch einmal dem oberen Teil der Spalten und fragen noch einmal ganz konkret bei allen Kärtchen: Muss dieses Feature ab Tag eins zur Verfügung stehen? Hier kommt nun das Minimum viable Product (MVP) ins Spiel: Das Ziel dieser Runde ist, aus den momentan als benötigt angesehenen Funktionen das wirklich zwingend notwendige Minimum herauszuschälen:
How to build a minimum viable product. pic.twitter.com/NMrfUtIRWh
— Vala Afshar (@ValaAfshar) October 20, 2014
Beim MVP geht es nicht darum, möglichst schnell (zeitlich) ein Resultat zu erhalten, sondern möglichst früh einen Nutzen aus dem Produkt zu ziehen. Kommen wir auf unser Shop-Beispiel zurück. Damit dieser einen Business Value (= Bestellungen und damit Umsatz) generiert, sind sicher eine Produkt-Auflistung, eine Detail-Ansicht und die Bestell-Möglichkeit zwingend notwendig.
Ob dieser Shop aber bereits am Tag 1 die Möglichkeit bietet, Artikel zu personalisieren (z.B. Grundartikel online konfigurieren, häufig mit einem Aufdruck o.ä.), wäre hier zu diskutieren. Hier kommt es natürlich auf das spezifische Projekt und die konkreten Ziele an. Bei einem Shop für Geburtstagstorten ist die Möglichkeit zur Personalisierung der Torte vermutlich deutlich höher zu priorisieren als bei unserem Shop-Beispiel für Feurerwehrmaterial. Beim Tortenlieferant sind vermutlich >90% der zu erwartenden Bestellungen individuell. Der Feuerwehrmaterial-Lieferant wird hingegen viele Standard- respektive Lagerartikel liefern.
Es wird konkret, wir starten klein
Am Ende dieser Diskussion sollte es möglich sein, eine horizontale Linie über alle Spalten zu legen, die das minimale Produkt definiert: Alles was über der Linie ist gehört ins MVP, alles unter der Linie kann zu einem späteren Zeitpunkt realisiert werden.
Das MVP bildet sich aus dem dringendsten Teil der Must-Have-Features auf welche am Tag 1 nicht verzichtet werden kann. Das Resultat des User Story Mapping Workshops.
Eingangs erwähnte ich, dass für den Workshop mindestens ein Teilnehmer von der Auftragsseite dabei sein muss, der die Ziele, Business-Relevanz und die nötige Portion Entscheidungsgewalt mit in die Diskussion bringt. Ohne diese Kompetenzen könnte dieser Schritt im Workshop nicht erfolgen. Eine mögliche Folge wäre, dass das initiale Projekt zu umfangreich würde. Dies hätte einen negativen Einfluss auf den Terminplan (dauert länger) und die Aufwände (kostet mehr).
Der Start unseres Projektes von healthy+ mit internezzo erfolgte agil und sehr effizient. Mit einzelnen Karten konnten beim ersten Meeting die Epics rasch identifiziert, mit Inhalten ergänzt und priorisiert werden. internezzo hat mich bei diesem ersten Meeting überzeugt von ihrer Kompetenz mit agilen Praktiken und ich freue mich auf den weiteren Projektverlauf.
Yves O. Aeschbacher, CEO der healthy+ AG
Nach dem Workshop
User Story Mapping ergänzt sich sehr gut mit einem agilen Projekt-Prozess: Nach dem Workshop sollte die globale Mission soweit von allen Projektverantwortlichen verstanden und dokumentiert sein, um mit der Schätzung, Planung und Umsetzung des Grundsystems zu starten. Dabei hat der Auftraggeber die Möglichkeit, laufend Korrekturen an der Planung einzubringen. Das können sowohl zusätzliche Funktionen sein als auch andere Kärtchen von der groben Roadmap zu streichen. Diesen Prozess hier im Detail zu beschreiben, würde den Rahmen dieses Posts wohl sprengen.
Nach dem Workshop – oder den Workshops falls es sich angeboten hat mehrmals zusammenzukommen – beginnt die Schätzung der einzelnen Features. In der Regel gelingt dies deutlich besser und präziser, solange die involvierten Team-Mitglieder noch wissen, was die einzelnen Kärtchen genau bedeuten. Ab diesem Schritt wechseln wir bei internezzo jeweils von den Papier-Kärtchen auf JIRA-Aufgaben. Dabei erhalten alle Involvierten bis hin zum Kunden Einsicht in die einzelnen Tasks, Aufwandschätzungen, Planungen für Sprints etc.
Auf Grund der Schätzungen erstellen wir dem Kunden ein Angebot und bei Bedarf ein kurzes Konzept-Dokument (insbesondere wenn mehrere Systeme und Schnittstellen involviert sind). Mit der Umsetzung des Projekts starten wir sobald uns der Kunde den Auftrag erteilt.
User Story Mapping bei internezzo
Intern haben wir die Methode in den letzten zwei Jahren bereits mehrfach angewandt. Für uns hat sich User Story Mapping als sehr einfache, aber wirkungsvolle Methode bewährt. Daraufhin haben wir begonnen, erste Workshops mit Kunden zu organisieren und zu führen.
Wir sehen die Vorteile von User Story Mapping ganz klar bei seiner Einfachheit: Die Methode erwies sich in der Praxis als sehr einfach zu erlernen, da das Regelwerk sehr intuitiv ist. Das macht es auch für jemanden, der das allererste Mal mit dieser Vorgehensweise konfrontiert ist sehr einfach, sich aktiv einzubringen und das Projekt mitzugestalten.
Ich hoffe, diese Einführung in das Thema User Story Mapping war hilfreich, auch wenn dieser Post nun etwas länger wurde als ursprünglich gedacht. Ich freue mich, wenn ich den einen oder anderen Leser inspirieren konnte, es einfach einmal auszuprobieren. Für Feedbacks oder Fragen stehe ich gerne über die Kommentarfunktion oder per E-Mail zur Verfügung.
