Ein Jahr mit vielen Storymappings

Von einer Stunde Power Storymapping über einen Tag intensiv Storymapping mit Prototyp bis hin zum drei Tage Storymapping Marathon war in diesem Jahr alles vertreten. Daraus haben sich einige Erkenntnisse ergeben, die ich gerne teilen möchte. Ich gehe davon aus, dass ihr wisst, was Storymapping ist. Am Ende des Textes stehen ein paar Buzzwords, mit denen man sich den Kontext sonst schnell ergoogeln kann.

Es sei gleich vorab gesagt: Wer eine exakte Darstellung der Anforderungen und eine verbindliche, stunden-genaue Auflistung der Umsetzung zu erreichen sucht, ist hier falsch!

Mit den richtigen Leuten starten

Wir brauchen Fachleute, die den Prozess kennen und Erfahrung in ihrer Domain mitbringen. Entscheider, die das Big Picture sehen. Entwickler, die das technische Verständnis beitragen. Jemand mit IT Projekterfahrung.

Mit einer kleinen Menge Personas starten

Solange es nicht um Endkunden geht, macht die Funktion einer Persona mehr Sinn als der soziale Background, das Alter usw. Wir konzentrieren uns also auf die Personas, die den Kernprozess steuern: ein Disponent, die Auftragsbearbeiterin, ein Fahrer, ein Empfänger von Ware, ein Sender von Ware, um z.B. den Prozess einer Spedition zu beschreiben.
Bei einer Happy Hour App dagegen interessieren wir uns für verschiedene User:

• Die Schülerin mit kleinem Taschengeld und hohem Party-Drang
• der Studenten auf der Suche noch sozialen Kontakten
• die Touristengruppe oder die Messebesucher auf der Suche nach einem intensiven Absturz in einer unbekannten Stadt

Alle mit ihren jeweiligen sozialen Hintergründen. Aber auch sie kann ich in der ersten Runde, in der ich feststellen möchte, was mein Gesamtsystem können muss und mit welchem Aufwand ich rechnen kann, in einer Persona vereinen.

Actions sind noch keine User Stories!

Wir definieren zu jeder Persona Goals und die Actions, mit denen sie diese erreicht. Wir bewegen uns strikt in einem nicht-technischen, nicht auf die Softwareentwicklung ausgerichteten Kontext. Also Umsatz verbessern, Happy Hour definieren. Goals und Actions sind wie Gliederungspunkte in einem langen Text, sie helfen, die Übersicht zu behalten und den Gesamtkontext zu verstehen.

Anschließend schreiben wir die Stories zu den Activities. Jetzt ist der technische Kontext gefragt, jetzt brauche ich ein Formular, in das ich eine Happy Hour mit Wochentag, Uhrzeit, Angebot und Preis eingeben kann.

Wo wir erkennen, dass Stories einen einfachen Teil haben, der die Basisfunktionalität herstellt und weitere, die den Funktionsumfang erweitern und z.B. die Usability erhöhen, splitten wir sie auf und hängen sie in die jeweiligen Kategorien (z.B. Prototyp, MVP, MMP, etc.).

Stories zu Epics zusammenfassen und gemeinsames Verständnis schärfen

Sind wir mit den Stories durch, lösen wir uns von den Actions. D.h. wir fassen die Stories zu sinnvollen Epics zusammen. Z.B. habe ich die Ausgabe von Daten als PDF an verschiedenen Stellen und kann sie jetzt in ein Epic „Export als PDF“ zusammenfassen. Anschliessend überprüfen wir den Zusammenhang auf Epic-Ebene noch mal: Habe ich alle Komponenten, werden mit den Epics die Goals erfüllt? Dieser Schritt hilft allen, wieder Übersicht und gemeinsames Verständnis herzustellen. Das kann am dritten Tag nach vielen Diskussionen auch mal unbemerkt über Bord gegangen sein.

Klein, also prototypisch anfangen

Es empfiehlt sich, einen Prototypen abzugrenzen, der mir Klarheit über das Kerngeschäft verschafft. Hier lasse ich möglichst viel weg: Registrierung, Anmeldung, User Profil, statische Seiten, Notifications etc. Ich validiere einzig den speziellen Kundennutzen, der mein Alleinstellungsmerkmal ausmacht – z.B. eine Filterfunktion, die Einbindung einer Bibliothek, einen Prozessfluß als State Machine, aufwendige Berechnungen oder Algorithmen. Ich möchte nur wissen, ob meine Idee aufgeht, ich will sie besser verstehen und anpassen.
Erkenne ich zu diesem Zeitpunkt, dass ich falsch lag, habe ich nur wenig Zeit und Geld verbraucht.

Nur das Wesentliche kommt in das MVP

Als zweite Version definiere ich das MVP. Jetzt will ich im Rahmen von Family and Friends – durchaus auch von echten Usern  – wissen, ob meine Idee zündet. Dazu müssen Basiskriterien nach Kano erfüllt sein. Ich gehe aber davon aus, dass Kunden Fehlertolerant sind. Early Adopter dürften sich wohl fühlen. Hier hänge ich alle Stories hin, die mir ein funktionierendes Grundsystem ermöglichen. Da ich mit wenig Traffic rechne, bleibt meine Infrastruktur klein (z.B. ein Server auf dem Webserver, DB und Applikation laufen).
Alle weiteren Stories hänge ich

• unter das MVP in die Version des Minimal Marketable Product (MMP) – die Version, mit der ich offiziell und mit Marketing raus gehe
• in das Backlog, wenn ich es noch weiter in der Zukunft sehe
• in einen Rettungsring, wenn ich noch keinen Konsens darüber habe, ob und wann die Anforderung umgesetzt werden soll

Diese Stories werde ich mir wieder anschauen, wenn ich mit dem MVP rausgegangen bin und Feedback eingesammelt habe. Mit den Erfahrungen aus dem Prototyp und dem MVP werde ich sehr viel schlauer sein und kann neu priorisieren, Stories splitten oder neu schreiben. Das aktuelle Wissen im Storymapping gibt mir aber einen Anhaltspunkt für den ungefähren Aufwand und liefert einen wichtigen Beitrag für das Gesamtbild der Anforderungen, das ich brauche, um früh die richtigen Weichen zu stellen (Architektur, Infrastruktur, Skalierbarkeit, Programmiersprache, Framework, Entwickler, Know How Aufbau usw.)

Moderation

Ein Storymapping muss moderiert werden, wenn es brauchbare Ergebnisse erzielen und effektiv sein soll. Bei der Moderation muss man ein gutes Mittelmaß finden. Diskussionen sind notwendig, um Alignment herzustellen oder divergierende, vielleicht problematische Sichten zu erkennen. D.h., man muss sie auch mal laufen lassen. Gleichzeitig muss der Fokus gehalten werden, um das Ziel nicht zu gefährden.

Schätzen macht klug

Wann ist es fertig? Sie wird immer kommen, diese Frage. Daher schätzen wir das Erreichte auf Story-Ebene. Wir machen eine Magic Estimation. Als Bewertungsgröße nehmen wir Personentage, z.B. 1, 3, 5 und 10 Werktage. Jeder kann schätzen, Unschärfen gleichen sich bei einer hohen Anzahl an Stories mit großer Wahrscheinlichkeit aus. Die beim Schätzen gewonnen Einsichten sind besonders für die Nichttechniker eine gute Erfahrung.

Der richtige Rahmen

Der Prototyp sollte klein, mit wenigen Leuten in kurzer Zeit (2-4 Wochen) umzusetzen sein. Das MVP sollte nach weiteren ca. 3 Monaten stehen. Geben meine Story-Pakete das nicht her, muss ich neu priorisieren. Kann ich noch etwas weglassen, habe ich noch Exiter, die ich nach unten verschieben kann? Hier unbedingt streng sein. Das Backlog wächst mit Sicherheit während der Umsetzung (Dark Matter, Scope Creep!), also starte ich möglichst klein, damit ich etwas Puffer habe! Habe ich Schwierigkeiten, richtig zu priorisieren, kann ich die Stories in Sprints packen und auf einen Zeitstrahl heften. Bleibe ich nicht in meinem Zeitgerüst, muss ich Dinge ins Backlog zurückschieben.
Referenz-Buzzwords: Storymapping, Kano, Magic Estimation, Dark Matter, Scope Creep

Neugierig auf ein Storymapping mit Mayflower? Wir bieten Power Storymapping zum Schnuppern auf Meetup an. Oder direkt einen Termin mit Micha Trieba vereinbaren.