User Story Mapping

Die Technik für besseres Nutzerverständnis in der agilen Produktentwicklung

Jeff Patton, Petra Hildebrandt

• Verlag: O'Reilly Media
• Jahr: 2015
• eBook-ISBN: 9783958750692
• Auflage: 1
• Thema: Computer Science
• Thema: Project Management

"User Story Mapping" ist in den USA längst ein Bestseller. Die von Jeff Patton entwickelte Methode knüpft an bewährte Ansätze aus der Agilen Entwicklung an und erweitert sie. Die Idee: Die Produktentwicklung wird detailliert am Arbeitsfluss der Nutzer ausgerichtet und in Story Maps kontinuierlich dokumentiert und illustriert. Dadurch entsteht im gesamten Team - bei Entwicklern, Designern und beim Auftraggeber - ein deutlich verbessertes gemeinsames Verständnis vom Gesamtprozess und vom zu entwickelnden Produkt. Gleichzeitig wird die Gefahr reduziert, sich in unwichtigen Details zu verzetteln oder gar ein Gesamtprodukt zu entwickeln, das dem Nutzer nicht hilft.

Kapitel 1. Das große Ganze

»Ich liebe agiles Development! Alle paar Wochen haben wir mehr funktionierende Software fertig. Aber ich habe das Gefühl, ich habe den Überblick verloren.«

Wenn ich jedes Mal eine Zehncentmünze bekäme, wenn ich so etwas von einem Teammitglied aus der agilen Softwareentwicklung zu hören bekomme, hätte ich ... nun ... eine Menge Zehncentstücke. Ich höre es oft. Vielleicht habt ihr selbst auch schon mal sowas geäußert. Nun, ich habe eine gute Nachricht für euch: Agile und storybasierte Prozesse einzusetzen, bedeutet nicht, dass ihr den Blick auf das große Ganze opfern müsst. Ihr könnt immer noch gesunde Diskussionen über das komplette Produkt führen und immer noch alle paar Wochen Fortschritte verzeichnen.

Da ihr euch geduldig das Kapitel »Hier geht's los« durchgelesen habt, kann ich den ganzen Krempel mit den Stories hier weglassem und euch direkt zeigen, wie Story Maps eines der größten Probleme der agilen Entwicklung lösen. Wenn ihr bereits damit vertraut seid, wie man Stories in agilen Projekten schreibt, könnt ihr nach diesem Kapitel eventuell schon durchstarten.

Das Wort mit »A«

Da ihr dieses Buch lest, wisst ihr wahrscheinlich, dass Story Mapping eine Methode ist, mit der man in agilen Prozessen mit User Stories arbeiten kann. An dieser Stelle findet ihr in jedem anderen Buch, das sich mit agiler Entwicklung befasst, das »Manifesto for Agile Software Development« abgedruckt, dieses Ding, das im Jahr 2001 von 17 Typen aufgesetzt wurde, die von den damals vorherrschenden Trends zu kontraproduktiven Prozessen angenervt waren. Ich bin froh, dass sie es geschrieben haben, und ich bin froh, dass die Auswirkungen davon so viele Menschen erreicht haben.

Aber ich muss euch leider enttäuschen – ich werde das Manifest hier nicht nochmal abdrucken und mich darüber auslassen, wieso es so wichtig ist. Ich denke, das wisst ihr bereits. Und wenn ihr es noch nie gelesen habt, solltet ihr das tun.

Den Platz, den das Manifest hier eingenommen hätte, fülle ich stattdessen mit einem lustigen Katzenbild.^[4] Warum? Weil erwiesenermaßen lustige Katzenbilder im Internet sehr viel mehr Aufmerksamkeit kriegen als das je irgendein Manifest könnte.

Und was, fragt ihr euch vielleicht, haben Katzenbilder jetzt mit agilen Prozessen zu tun? Gar nichts. Aber der Begriff »agil« hat definitiv etwas mit diesem Buch zu tun, und mit Stories, und der Evolution des Story Mapping.

<Hier die Flashback-Musik einspielen…>

Im Jahr 2000 arbeitete ich bei einem Startup in San Francisco, und die Firma hatte Kent Beck beauftragt (den Typ, der Extreme Programming kreiert und als Erster den Gedanken der Stories beschrieben hat), als Berater den Softwareentwicklungsprozess in Gang zu bringen. Ich spule ganz schön weit zurück, aber worum es mir geht, ist, dass die Idee der Stories schon ziemlich alt ist. Wenn ihr gerade damit beginnt, Stories einzusetzen, könnt ihr keinen Early-Adopter-Status mehr kriegen, das wäre vor einem Jahrzehnt oder so der Fall gewesen. Kent und die anderen Pioniere des Extreme Programming wussten, dass all diese Methoden zum Abarbeiten von Anforderungen in der Vergangenheit nicht so richtig gut funktioniert hatten. Kents einfache Idee war, dass wir alle zusammenkommen und unsere Geschichten erzählen sollten; dass wir durch das Gespräch ein gemeinsames Verständnis schaffen konnten, um gemeinsam zu besseren Lösungen zu gelangen.

Stories erzählen, nicht Geschichten schreiben

Als ich zum ersten Mal den Begriff Story hörte, fand ich ihn doof. Das gebe ich zu. Es schien nicht richtig, die wichtigen Dinge, die Leute wollen, zu trivialisieren, indem man sie Geschichten bzw. Stories nennt. Aber ich bin ein langsamer Lerner – das habe ich ja schon bei dem Thema gemeinsames Verständnis erwähnt. Ich habe eine Weile gebraucht, bis ich das wirklich kapiert habe:

Der Begriff »Story« drückt aus, wie wir sie benutzen (sollen), und nicht, was wir aufschreiben sollen.

Auch bevor ich wirklich begriff, wieso Stories so genannt werden, war mir klar, dass ich eine Handvoll Stories – einen Satz oder einen kurzen Titel – auf Karten oder Klebezettel schreiben konnte. Ich konnte sie rumschieben und nach Prioritäten anordnen, um zu entscheiden, was wirklich wichtig war. Wenn ich entschieden hatte, dass etwas wichtiger war als etwas anderes, konnten wir darüber diskutieren. Das war supercool. Wieso hatte ich nicht schon früher Kram auf Karteikarten geschrieben und so organisiert?

Das Problem war, dass diese eine Karte etwas sein konnte, wofür ein Entwickler nur ein paar Stunden brauchte, oder aber ein paar Tage, oder ein paar Wochen, oder einen Monat – wer wusste das schon? Ich nicht, jedenfalls nicht, ehe wir darüber nicht gesprochen hatten.

Ich hatte eine sehr unschöne Auseinandersetzung, als ich bei meinem ersten agilen Projekt mit Stories arbeitete. Wir begannen eine Unterhaltung über eine Story und ich fand heraus, dass meine Story zu groß war. Ich hatte gehofft, sie in der nächsten Iteration abgehandelt zu haben. Die Entwickler, mit denen ich sprach, teilten mir mit, dass das nicht drin war. Ich hatte das Gefühl, etwas Falsches gemacht zu haben. Die Entwickler identifizierten einen kleinen Teil, über den wir sprechen konnten und der in der nächsten Iteration erreicht werden konnte. Aber ich war frustriert, dass wir nicht über das große Ganze sprechen konnten. Ich wollte ehrlich eine Vorstellung davon bekommen, welchen Zeitaufwand diese große Sache, die ich wirklich brauchte, benötigen würde. Ich hatte gehofft, dass die Diskussion mir eine Antwort darauf geben würde, aber das tat sie nicht.

Die ganze Geschichte erzählen

2001 verließ ich das Team, in dem ich gearbeitet hatte, und begann, die Sache anders anzugehen. Mein Team und ich versuchten, Stories zu schreiben, die das große Ganze abdeckten. Wir arbeiteten daran, das Produkt, das wir entwickelten, im Ganzen zu verstehen und gemeinsam Kompromisse auszuhandeln. Wir benutzten den Stapel Karteikarten mit Story-Titeln dazu, unsere Gedanken zu sortieren und das große Ganze in die kleinen Teile aufzubrechen, die wir als Nächstes produzieren konnten. 2004 schrieb ich meinen ersten Artikel über diese Idee. Den Begriff Story Mapping habe ich allerdings erst 2007 geprägt.

Es stellte sich heraus, dass der Name, den etwas hat, einen großen Unterschied ausmacht. Nachdem die Methode einen griffigen Namen hatte, konnte ich sehen, wie sie sich ausbreitete. Damals glaubte ich, es sei eine ganz großartige Erfindung – bis ich auf andere Leute traf, die ganz ähnliche Dinge machten, oder sogar das Gleiche. Ich entdeckte ein Muster (Pattern).

Die Bezeichnung Pattern hörte ich in diesem Kontext das erste Mal von meiner Freundin Linda Rising: Wenn du jemandem von einer tollen Idee erzählst und er sagt: »Ja, so ähnlich machen wir d...

Inhaltsverzeichnis

• Cover
• Titel
• Widmung
• Inhalt
• Vorwort
• Über dieses Buch
• Hier geht's los
• 1. Das große Ganze
• 2. Planen, (um) weniger zu produzieren
• 3. Planen, (um) schneller zu lernen
• 4. Planen, (um) rechtzeitig fertig zu werden
• 5. Ihr wisst schon, wie es geht
• 6. Die wahre Geschichte der Stories
• 7. Bessere Stories erzählen
• 8. Nicht alles steht auf der Karte
• 9. Die Karteikarte ist nur der Anfang
• 10. Wir backen uns eine Story
• 11. Steine brechen
• 12. Steinebrecher
• 13. Beginnt mit Chancen
• 14. Mit Discovery gemeinsames Verständnis aufbauen
• 15. User-Discovery für validiertes Lernen
• 16. Verfeinern, Definieren, Produzieren
• 17. Stories sind genau genommen wie Asteroiden
• 18. Lernt aus jedem Build
• Das Ende. Oder?
• Danksagung
• Literatur
• Stichwortverzeichnis
• Kolophon
• Impressum