User Story Mapping

Jeff Patton

Peter Economy

Petra Hildebrandt

User Story Mapping

Inhaltsverzeichnis

Widmung

Vorwort

Vorwort von Martin Fowler

Vorwort von Alan Cooper

Vorwort von Marty Cagan

Über dieses Buch

Wieso ich?

Wenn du Schwierigkeiten mit Stories hast, ist dieses Buch für genau Dich

Wer sollte dieses Buch lesen?

Ein paar Konventionen in diesem Buch

Die Überschriften in den einzelnen Kapiteln weisen euch den Weg durch das Thema.

Wie dieses Buch aufgebaut ist

Story Mapping aus 3.000 Metern Höhe

User Stories verinnerlichen

Bessere Backlogs

Bessere Builds

Hier geht's los

Stille Post

Gemeinsames Verständnis ist erschreckend einfach zu erreichen

Vergesst perfekte Dokumentation

Gute Dokumente sind wie Urlaubsfotos

Dokumentiert, um euch zu erinnern

Über das Richtige reden

Jetzt und später

Es geht nicht um Software

Okay, es geht nicht nur um Menschen

Produziert weniger

A wie Anforderungskatalog

Das ist alles

1. Das große Ganze

Das Wort mit »A«

Stories erzählen, nicht Geschichten schreiben

Die ganze Geschichte erzählen

Gary und die Tragödie des flachen Backlogs

Talk and Doc

Umreißt eure Idee

Beschreibt eure Kunden und User

Erzähl die Stories deiner User

Details und Möglichkeiten erforschen

2. Planen, (um) weniger zu produzieren

Mapping hilft großen Gruppen, gemeinsames Verständnis herzustellen.

Mapping hilft euch, die Löcher in eurer Geschichte zu entdecken

Es ist immer zu viel (zu tun)

Definiert das Minimum für ein Minimum Viable Product Release

Definiert eine Release Roadmap

Priorisiert Outcomes, nicht Features

Es ist Magie – wirklich.

Die Sache mit dem MVP

Das neue MVP ist gar kein Produkt!

3. Planen, (um) schneller zu lernen

Diskutiert die Chancen

Validiert das Problem

Benutzt Prototypen, um etwas zu lernen

Was User Wollen

Lernt aus euren Builds

Iteriert bis zum MVP

Wie man es falsch macht

Validiertes Lernen

Minimiert eure Experimente. Wirklich.

Zusammenfassung

4. Planen, (um) rechtzeitig fertig zu werden

Redet mit dem Team

Die Kunst des gekonnten Schätzens

Plant, Stück für Stück zu produzieren

Macht nicht aus jedem Slice ein Release

Das andere Geheminis gekonnter Schätzungen

Managt euer Budget

Was würde da Vinci tun?

Iterativ UND inkrementell

Strategien: Eröffnungs-, Mittel- und Endspiel

Markiert eure Entwicklungsstrategie in einer Map.

Es geht um das Risiko.

Wie geht es weiter?

5. Ihr wisst schon, wie es geht

1. Schreibt eure Story auf – einen Schritt nach dem anderen

Tasks: das, was wir tun

Meine Tasks sind nicht Eure Tasks.

Ich bin nur ein bisschen detailverliebter

2. Organisiert eure Story

Fehlende Details ergänzen

3. Entdeckt alternative Stories

Bleibt im Fluss

4. Komprimiert die Map und erzeugt einen Backbone

5. Gruppiert Tasks, die euch helfen, einen bestimmten Outcome zu erzielen

Fertig! Ihr habt alle wichtigen Konzepte gelernt!

Do Try This at Home (oder bei der Arbeit)

Die Map dreht sich ums Jetzt, nicht ums Später

Probiert es wirklich aus

Mit Software ist es schwieriger

Die Map ist nur der Anfang

6. Die wahre Geschichte der Stories

Kents verstörend einfache Idee

Einfach ist nicht leicht

Ron Jeffries und die 3 Cs

1. Karte (Card)

2. Konversation (Conversation)

3. Bestätigung (Confirmation)

Worte und Bilder

Das war's schon.

7. Bessere Stories erzählen

Connextras Tolles Template

Template-Zombies und der Schneepflug

Checkliste: Worüber ihr euch wirklich unterhalten solltet

Macht Urlaubsfotos

Das ist eine Menge Zeug

8. Nicht alles steht auf der Karte

Unterschiedliche Leute, unterschiedliche Konversationen

Wir brauchen eine größere Karteikarte

Strahler und Kühltruhen

Dafür ist das Werkzeug nicht gedacht

Gemeinsames Verständnis herstellen

Erinnern

Tracking

9. Die Karteikarte ist nur der Anfang

Habt eine klare Vorstellung davon, was ihr konstruiert

Entwickelt eine mündliche Tradition des Geschichtenerzählens

Inspiziert das Ergebnis eurer Arbeit

Es geht nicht um Euch

Entwickelt, um zu lernen.

Es ist nicht immer Software

Plant, zu lernen, und lernt, zu planen

10. Wir backen uns eine Story

Ein Rezept kreieren

Den großen Kuchen aufteilen

11. Steine brechen

Auf die Größe kommt es immer an

Stories sind wie Steine

Epen sind große Steine, die manchmal benutzt werden, um Menschen damit zu schlagen

Themen organisieren Story-Gruppen

Vergesst diese Begriffe und konzentriert euch darauf, Stories zu erzählen

Beginnt mit Chancen (Opportunities)

Entdeckt eine Minimum Viable Solution

Vertieft euch in die Details jeder einzelnen Story im Delivery-Prozess

Redet weiter, während ihr produziert

Evaluiert jedes Stück

Evaluiert mit Usern und Kunden

Evaluiert mit Business-Stakeholdern

Evaluiert auch nach dem Release weiter

12. Steinebrecher

Wertvoll – benutzbar – realisierbar

Ein Discovery-Team benötigt für den Erfolg viele andere Personen

Die drei Amigos

Produkt-Owner als Produzenten

Es ist kompliziert

13. Beginnt mit Chancen

Führt Konversationen über Chancen

Tiefer graben, wegwerfen oder darüber nachdenken

Chance sollte kein Euphemismus sein

Story Mapping und Chancen (Opportunities)

Seid wählerisch

14. Mit Discovery gemeinsames Verständnis aufbauen

Bei Discovery geht es nicht um das Schreiben von Software

Vier essenzielle Schritte der Discovery

1. Umreißt die Idee (Framing)

2. Versteht eure Kunden und User

Skizziert einfache Personas

Legt Organisationsprofile an – Orgzonas

Mappt, wie die User heute arbeiten

3. Stellt euch eure Lösung vor

Mappt eure Lösung

Worte und Bilder

Validiert Vollständigkeit

Validiert technische Bedenken

Spielt »Was-ist«

Feiert noch nicht

4. Minimieren und Planen

Es ist immer zu viel

Das Geheimnis der Priorisierung

Discovery-Aktivitäten, Diskussionen und Artefakte

Discovery dient der Herstellung von gemeinsamem Verständnis.

15. User-Discovery für validiertes Lernen

Wir liegen meistens falsch

Die schlechte alte Zeit

Einfühlen, Fokussieren, Ideen Sammeln, Prototypen Bauen, Testen

Wie man etwas Gutes versaut

Kurze Zyklen validierten Lernens

Wie Lean Startup Thinking das Produktdesign verändert

Beginnt mit Raten

Benennt eure riskanten Annahmen

Designt und erstellt einen kleinen Test

Messt, indem ihr euren Test mit Kunden und Usern macht

Überdenkt eure Lösung und eure Annahmen

Stories und Story Maps?

16. Verfeinern, Definieren, Produzieren

Karteikarten, Konversationen, mehr Karten, noch mehr Konversationen ...

Schneiden und Polieren

Der Story-Workshop

Sprint- oder Iterationsplanung?

Menschenmengen kollaborieren nicht

Aufteilen und Ausdünnen

Benutzt eure Story Map während der Delivery

Benutzt eine Map, um Fortschritte zu visualisieren

Benutzt einfache Story Maps in Story-Workshops

17. Stories sind genau genommen wie Asteroiden

Zerbrochene Steine wieder zusammenfügen

Übertreibt es nicht mit dem Mapping

Zerbrecht euch nicht den Kopf über Kleinkram

18. Lernt aus jedem Build

Review im Team

Review mit anderen aus eurem Unternehmen

Genug

Lernt von Usern

Lernt aus euren Releases

Outcomes nach Zeitplan

Benutzt eine Map, um zu evaluieren, ob ihr bereit für den Release seid

Das Ende. Oder?

Danksagung

Literatur

Stichwortverzeichnis

Kolophon

Copyright

Widmung

Für Stacy, Grace und Zoe, meine größten Unterstützerinnen, die all meinen Mühen einen Sinn geben.

Und im Angedenken an Luke Barrett, einen geschätzten Kollegen und Mentor. Er hat mein Leben verändert, so wie das ungezählter anderer.

Vorwort

Vorwort von Martin Fowler

Zu den positiven Auswirkungen des Aufstiegs der agilen Softwareentwicklung gehört die Verbreitung des Konzepts, eine große Menge Anforderungen in kleinere Stücke aufzuteilen. Diese Stücke – Stories – erlauben viel bessere Einblicke in den Fortschritt eines Entwicklungsprojektes. Wenn ein Produkt Story für Story entsteht und jede Implementation einer Story vollständig in das Softwareprodukt integriert ist, kann jeder sehen, wie das Produkt wächst. Dadurch, dass sie Stories verwenden, die aus Usersicht Sinn ergeben, können Entwickler ihr Projekt steuern, indem sie festlegen, welche Stories sie als Nächstes bearbeiten werden. Die bessere Sichtbarkeit fördert eine stärkere Mitwirkung von Userseite – Sie müssen nicht mehr ein Jahr oder länger darauf warten, dass Sie sehen können, was das Entwicklerteam so getrieben hat.

Die Zerstückelung hat aber auch negative Konsequenzen. Dazu gehört, dass man schnell den Überblick darüber verlieren kann, was die Software als Ganzes tun soll. Man kann ein Durcheinander an Stücken herausbekommen, die nicht in ein zusammenhängendes Ganzes passen. Oder man baut ein System, das den Usern nicht wirklich etwas nutzt, weil einem zwischen all den Details der Sinn für das, was im Kern benötigt wird, abhanden gekommen ist.

Story Mapping ist eine Methode, mit der der Gesamtzusammenhang hergestellt werden kann, den ein bloßer Haufen von Stories oft vermissen lässt.

Und das war's auch schon – die Beschreibung dieses Buches in einem Satz. Dieser Satz trägt in sich ein großes Versprechen. Der Blick auf das große Ganze hilft dabei, mit Usern effektiv zu kommunizieren, er hilft allen Beteiligten, zu vermeiden, unnütze Features zu produzieren, und er dient als Orientierungshilfe für eine in sich stimmige User Experience. Wenn ich mit meinen Kollegen bei ThoughtWorks darüber spreche, wie sie ihre Stories entwickeln, nennen sie Story Mapping regelmäßig als Schlüsselmethode. Häufig haben sie die Methode in Workshops mit Jeff gelernt, denn er hat die Methode entwickelt und kann sie am besten kommunizieren. Dieses Buch gibt mehr Menschen die Möglichkeit, die Methode direkt an der Quelle zu erlernen.

Aber dieses Buch ist nicht nur etwas für Leute, die einen Titel wie »Business-Analyst« auf der Visitenkarte oder ihrem Online-Profil stehen haben. Eine der größten Enttäuschungen für mich war in diesem Jahrzehnt, in dem agile Methoden immer mehr Anwendung fanden, dass viele Programmierer Stories als eine Kommunikations-Einbahnstraße vom Analysten zu ihnen ansehen. Von Anfang an waren Stories als Zündfunken für Konversationen gedacht. Wenn man sich tatsächlich effektive Softwarelösungen für bestimmte Tätigkeiten ausdenken will, muss man diejenigen, die die Software schreiben, als lebenswichtige Ideengeber für die Einsatzmöglichkeiten betrachten, denn es sind die Programmierer, die am besten wissen, was Software leisten kann. Programmierer müssen verstehen, was ihre User zu erreichen versuchen, und sollten kollaborativ Stories entwickeln, die diese Bedürfnisse der User abbilden. Ein Programmierer, der Story Mapping beherrscht, ist besser in der Lage, den Kontext des Users zu erkennen, und kann dabei helfen, die Software zu umreißen – und somit seine Arbeit besser zu machen.

Als Kent Beck (auf den der Gedanke der »Story« zurückgeht) seine Ideen zur Softwareentwicklung erarbeitete, bezeichnete er Kommunikation als Schlüsselwert für effektive Teams. Stories sind die Bausteine der Kommunikation zwischen den Entwicklern und denen, die ihre Arbeit benutzen werden. Story Maps organisieren und strukturieren diese Bausteine und verbessern damit den Kommunikationsprozess – der den wohl wichtigsten Part der Softwareentwicklung darstellt.

Vorwort von Alan Cooper

In Mary Shelleys berühmtem Science-Fiction-Roman Frankenstein erschafft der wahnsinnige Dr. Frankenstein eine Kreatur aus verschiedenen Stücken toter Menschen und erweckt diese Kreatur mit der damals neuartigen Technologie der Elektrizität zum Leben. Natürlich wissen wir, dass das eigentlich nicht möglich ist. Man kann kein Leben erschaffen, indem man zufällige Körperteile zusammennäht.

Und doch ist es das, was Softwareentwickler immer wieder versuchen: Sie erweitern eine Software um gute Features, eins nach dem anderen, und dann wundern sie sich, wieso so wenige User ihr Produkt gut finden. Der Kern des Problems liegt darin, dass Entwickler ihre Konstruktionsmethode als Design-Tool benutzen, die beiden aber nicht untereinander austauschbar sind.

Es ist absolut sinnvoll, dass Programmierer die Software Feature für Feature produzieren. Das ist eine hervorragende Strategie, die sich jahrelang bewährt hat. Was sich allerdings auch über die Jahre gezeigt hat, ist, dass der Ein-Feature-nach-dem-anderen-Ansatz – setzt man ihn als Designmethode für das Verhalten und den Umfang eines digitalen Produkts ein – zu einem Frankenstein'schen Monster(-Programm) führt.

Wenn sie auch eng verwandt sind, so unterscheiden sich die Praxis des Softwaredesigns und die der Erstellung ebendieser Software doch deutlich voneinander und werden üblicherweise von verschiedenen Personen mit unterschiedlichen Skills absolviert. Zahllose Stunden damit zuzubringen, User zu beobachten und Verhaltensmuster zu mappen, wie das die Interaktionsdesigner tun, würde die meisten Programmierer in den Wahnsinn treiben. Umgekehrt wäre stundenlanges Brüten über Algorithmen eine viel zu einsiedlerische Tätigkeit für die meisten Designer.

Aber wenn diese beiden unterschiedlichen Ansätze – Design und Entwicklung – zusammenarbeiten, kommt eine elektrische Spannung auf, die das Potenzial besitzt, ein lebendes, atmendes Produkt zu erschaffen. Teamarbeit haucht dem Monster Leben ein und bringt die Leute dazu, es zu lieben.

Zwar ist die Idee der Zusammenarbeit weder neu noch sonderlich aufschlussreich, aber es ist dennoch sehr schwer, sie tatsächlich effektiv umzusetzen. Die Arbeitsweise der Entwickler – ihr Tempo, ihre Sprache und ihr Rhythmus – unterscheidet sich sehr von der der Interaktionsdesigner.

Die Fachleute beider Gebiete sind stark, kompetent und innerlich diszipliniert, aber sie haben beide die gleiche Schwäche: Es ist wirklich schwer, ein Designproblem in Programmierersprache auszudrücken, und es ist ebenso schwer, ein Entwicklungsproblem in der Sprache der Designer zu formulieren. Die beiden Schwesterdisziplinen haben keine gemeinsame Sprache. Und genau dort, auf der Kreuzung zwischen den beiden Disziplinen, finden wir Jeff Patton.

Jeffs Methode des Story Mapping ist für Entwickler gut verständlich, und sie ist ebenso gut verständlich für die Designer. Story Mapping ist der Rosetta-Stein des digitalen Zeitalters.

Trotz gegenteiliger Behauptungen ist die agile Entwicklung kein sonderlich gut geeignetes Designwerkzeug. Es handelt sich um eine Art, über Entwicklung nachzudenken, die designfreundlich ist – was eine gute Sache ist –, aber für sich genommen, führt sie nicht zu einem Produkt, das die Nutzer toll finden. Auf der anderen Seite kann man oft erleben, dass gute, wohldokumentierte Designs in die Hände von Entwicklern gelegt werden, die dann – agil oder nicht – die inneren Werte dieses Designs in der Umsetzung vollständig plätten.

Pattons Story-Mapping-Ansatz ist ein Brückenschlag über diesen Abgrund. Beim Interaktionsdesign geht es darum, die Wahrheit des Users zu finden und als Erzählung abzubilden. In der Softwareentwicklung geht es darum, diese Erzählung in kleine, funktionale Stücke zu zerlegen und diese wiederum zu implementieren und zu integrieren. Es passiert ganz schnell, dass in diesem komplexen Prozess der Wesenskern der Erzählung flöten geht. Ja, die Funktionen wurden implementiert, aber der Patient stirbt auf dem OP-Tisch.

Indem es die User Stories als Landkarte auslegt, behält das Design seine narrative Struktur, kann aber dennoch für eine effektive Implementation dekonstruiert werden. Die Geschichte des Designers, die eine formalisierte Fassung der User Story ist, bleibt durch die gesamte Entwicklung hindurch intakt.

Die klassische Welt der Konzerne hat bewiesen, dass es nahezu unmöglich ist, mit Teams von zwei- oder dreihundert Leuten Produkte herzustellen, die jemand wirklich richtig gut findet. Die Startup-Community wiederum hat bewiesen, dass ein Team aus vier oder fünf Personen sehr wohl kleine Produkte machen kann, die die Leute mögen. Aber selbst solche Produkte werden irgendwann groß und verlieren diesen inneren Funken. Die Herausforderung, der wir uns stellen müssen, ist, große Software zu erschaffen, die die Leute lieben. Große Software bedient große Gruppen von Nutzern, die komplexe, kommerziell relevante Aufgaben damit verrichten. Es ist unglaublich schwer, solche Software so zu gestalten, dass ihre Benutzung Spaß macht und leicht zu erlernen ist.

Die einzige Methode, auf die wir große Software produzieren können, die kein Frankenstein'sches Monster ist, ist, indem wir lernen, das Softwaredesign und die Entwicklung miteinander zu vereinen. Und niemand weiß das besser als Jeff Patton.

Vorwort von Marty Cagan

Ich hatte das große Glück, mit vielen der besten Technologieteams der Welt arbeiten zu dürfen. Mit Menschen, die die Produkte erschaffen haben, die wir jeden Tag benutzen und gern haben. Teams, die im Wortsinn die Welt verändert haben.

Man hat mich auch hinzugezogen, um Firmen zu helfen, bei denen es nicht so gut lief. Startups, die Bodenhaftung bekommen mussten, ehe ihnen das Geld ausging. Größere Firmen, die versuchten, ihre frühen Innovationen zu replizieren. Teams, die es nicht schafften, etwas Wertvolles zum Unternehmen beizutragen. Führungskräfte, die darüber frustriert waren, wie lange es dauerte, bis aus einer Idee Realität wurde. Techniker, die über ihre Produkt-Owner verärgert waren.

Ich habe dabei gelernt, dass es einen wesentlichen Unterschied dazwischen gibt, wie die besten Firmen ihre Technologie-Produkte erschaffen, und wie der Rest es macht. Und damit meine ich nicht kleine Unterschiede. Ich meine alles, angefangen davon, wie sich Führungskräfte verhalten, über das Empowerment von Teams und die Art und Weise, wie Teams zusammenarbeiten, bis hin zur Unternehmenskultur und der Art und Weise, auf die Produktentwicklung, Design und Technik gemeinsam daran arbeiten, effektive Lösungen für ihre Kunden zu erschaffen.

Dieses Buch trägt den Titel User Story Mapping, aber ihr werdet schon bald merken, dass es um sehr viel mehr geht als nur diese einfache, aber wirkungsvolle Technik. Dieses Buch reicht bis in den Kern der Frage hinein, wie Teams zusammenarbeiten, kommunizieren und schlussendlich gute Dinge finden, die es sich lohnt zu produzieren.

Viele von euch hatten noch nie die Gelegenheit, aus der Nähe mitzuerleben, wie ein starkes Produktteam arbeitet. Alles, was ihr möglicherweise kennt, ist das, was eure jetzige oder vorige Firma tut. Deswegen möchte ich versuchen, hier einen kleinen Eindruck davon zu vermitteln, wie stark sich die besten Teams vom Rest unterscheiden.

Mit einer dankbaren Verneigung vor Ben Horowitz’ Good Product Manager, Bad Product Manager habt ihr hier einen flüchtigen Einblick in einige der entscheidenden Unterschiede zwischen starken Produkt-Teams und schwachen Teams:

Gute Teams haben eine überzeugende Vision ihres Produktes, die sie mit der Leidenschaft eines Missionars verfolgen. Schlechte Teams sind Söldner.

Gute Teams beziehen ihre Inspiration und Produktideen aus Scorecard-KPIs, aus der Beobachtung sich abmühender Kunden, aus der Analyse der Daten, die Kunden bei der Nutzung des Produktes generieren, und aus der gewohnheitsmäßigen Anwendung neuester Technik bei der Problemlösung. Schlechte Teams holen bei Kunden und Sales-Abteilungen Anforderungen ein.

Gute Teams wissen, wer ihre Key Stakeholder sind, sie kennen die Begrenzungen, innerhalb deren diese Stakeholder operieren, und sie sind darauf ausgerichtet, Lösungen zu erschaffen, die nicht bloß für die Kunden und Nutzer funktionieren, sondern auch innerhalb der Beschränkungen des jeweiligen Business. Schlechte Teams holen bei Stakeholdern Anforderungen ein.

Gute Teams sind in den zahlreichen Techniken ausgebildet, mit denen man schnell Produktideen austesten kann, um zu bestimmen, welche es sich wirklich zu entwickeln lohnt. Schlechte Teams halten Meetings ab, um priorisierte Roadmaps zu erzeugen.

Gute Teams brainstormen liebend gern mit klugen Köpfen aus dem gesamten Unternehmen. Schlechte Teams sind beleidigt, wenn jemand von außerhalb ihres Teams es wagt, vorzuschlagen, dass sie irgendetwas tun sollten.

In guten Teams arbeiten Produktentwicklung, Design und Technik Seite an Seite, und sie begrüßen das Geben und Nehmen zwischen Funktionalität, User Experience und der Technik, die diese ermöglicht. Schlechte Teams hocken in ihren jeweiligen Funktionsbereichen und erwarten, dass die anderen ihre Dienste in Form von Dokumenten und angesetzten Meetings anfordern.

Gute Teams testen konstant neue Ideen aus, um Innovation zu ermöglichen, aber auf eine Weise, die den Unternehmensgewinn und die Marke schützt. Schlechte Teams warten immer noch auf die Erlaubnis, einen Test durchzuführen.

Gute Teams bestehen darauf, dass sie über die nötigen Fähigkeiten verfügen, um erfolgreiche Produkte zu machen, wie zum Beispiel ein starkes Interaktionsdesign. Schlechte Teams wissen nicht mal, was Interaktionsdesigner sind.

Gute Teams sorgen dafür, dass ihre Techniker Zeit haben, die Discovery-Prototypen täglich zu testen, damit sie ihre Einsichten dazu beitragen können, wie das Produkt besser werden kann. Schlechte Teams führen den Technikern die Prototypen während der Sprint-Planung vor, damit sie eine Einschätzung abgeben können.

Gute Teams setzen sich jede Woche direkt mit Endnutzern und Kunden auseinander, um diese besser zu verstehen und die Reaktionen der Kunden auf ihre neuesten ideen zu erleben. Schlechte Teams denken, sie seien der Kunde.

Gute Teams wissen, dass viele ihrer Lieblingsideen am Ende nicht für den Kunden funktionieren werden, und dass selbst die, die es schaffen könnten, mehrere Iterationen brauchen werden, um an den Punkt zu gelangen, an dem sie das gewünschte Ergebnis liefern. Schlechte Teams machen nur das, was auf der Roadmap eingezeichnet ist, und sind zufrieden damit, Termine einzuhalten und die Qualität zu sichern.

Gute Teams begreifen, wie wichtig Geschwindigkeit ist, und dass eine schnelle Iteration der Schlüssel zur Innovation ist. Sie wissen, dass die Geschwindigkeit aus dem Einsatz der richtigen Techniken resultiert, nicht aus Zwangsarbeit. Schlechte Teams beklagen sich, sie seien so langsam, weil ihre Kollegen nicht hart genug arbeiteten.

Gute Teams gehen Verpflichtungen mit hoher Integrität ein, nachdem sie eine Anfrage evaluiert und sichergestellt haben, dass sie eine lebensfähige Lösung anbieten können, die tatsächlich für den Kunden und sein Business funktioniert. Schlechte Teams beklagen sich, ihr Unternehmen sei verkaufsorientiert.

Gute Teams instrumentieren ihre Arbeit, damit sie sofort herausfinden können, wie ihr Produkt benutzt wird, und auf diesen Daten basierende Anpassungen vornehmen können. Schlechte Teams betrachten Analysetools und Reporting als »nice-to-have«.

Gute Teams integrieren und releasen fortlaufend, denn sie wissen, dass ein gleichbleibender Strom kleinerer Releases für eine erheblich stabilere Lösung für ihren Kunden sorgt. Schlechte Teams testen manuell am Ende einer schmerzlichen Integrationsphase und releasen dann alles auf einmal.

Gute Teams machen sich einen Kopf über ihre Referenzkunden. Schlechte Teams machen sich einen Kopf über ihre Mitbewerber.

Gute Teams feiern, wenn sie signifikante Auswirkungen auf die KPIs ihres Business erzielen. Schlechte Teams feiern, wenn sie endlich irgendwas abliefern.

Mir ist klar, dass ihr euch vielleicht fragt, was das alles mit Story Maps zu tun hat. Ich glaube, ihr wärt überrascht. Und genau deswegen bin ich ein Fan von Story Maps.

Ich habe nur wenige agile Experten getroffen, die ich für qualifiziert halte, einem Produktteam dabei zu helfen, sich so sehr zu verbessern, dass es das leisten kann, was seine Firma braucht und verdient. Jeff Patton ist einer davon. Ich habe erlebt, wie er mitten in der Produkt-Discovery mit Teams in den Schützengraben stieg und die Ärmel hochkrempelte. Ich stelle ihn gern Firmen vor, denn er ist effektiv. Teams mögen ihn, weil er Ahnung hat, aber ein bescheidener Typ ist.

Die Tage, in denen Produktmanager Anforderungen zusammenstellten und dokumentierten, in denen Designer sich abmühen mussten, um auch nur einen Hauch Lippenstift auf den Look auftragen zu können, und in denen sich die Techies im Keller verschanzten und Code tippten, sind bei den besten Teams lange vorbei. Und es ist an der Zeit, dass sie auch in eurem Team vorbei sind.

Über dieses Buch

Live in it, swim in it, laugh in it, love in it / Removes embarrassing stains from contour sheets, that’s right / And it entertains visiting relatives, it turns a sandwich into a banquet.

—Tom Waits, »Step Right Up«

Dieses Buch sollte eigentlich nur ganz kurz werden, eine Broschüre quasi.

Ich begann damit, über eine simple Verfahrensweise zu schreiben, die ich Story Mapping nannte. Ich erstelle – wie eine Menge anderer Leute auch – einfache Maps, die es erleichtern, mit anderen zusammenzuarbeiten und nachzuempfinden, wie es sich anfühlt, ein Produkt zu benutzen.

Story Mapping sorgt dafür, dass wir uns auf die Benutzer (User) und ihre Erfahrungen (User Experience) konzentrieren. Das Ergebnis ist eine bessere Konversation und schlussendlich ein besseres Produkt.

Das Erstellen einer Map ist ganz einfach. Zusammen mit den anderen Beteiligten erzähle ich die Geschichte (Story) eines Produkts und schreibe jeden wichtigen Schritt, den ein User absolviert, auf Klebezettel, die ich von links nach rechts anordne. Dann schauen wir uns diese Schritte noch einmal komplett an, sprechen über die Details jedes einzelnen Schrittes und notieren diese auf weiteren Klebezetteln, die wir vertikal unter dem jeweiligen Schritt anbringen. Damit erhalten wir eine einfache, rasterähnliche Struktur, die die Story von links nach rechts erzählt, und die damit verbundenen Details von oben nach unten auflistet. Das geht ganz fix und macht Spaß. Mithilfe dieser Details verfügen wir dann auch über ein besseres Backlog der Stories bei unseren agilen Entwicklungsprojekten.

Wie schwierig konnte es wohl sein, ein Buch darüber zu schreiben?

Nun, es stellte sich heraus, dass auch ganz einfache Dinge ausgesprochen kompliziert sein können. Und zu beschreiben, warum man eine Story Map anlegen sollte, was dabei vorgeht und auf wie viele verschiedene Weisen man sie benutzen kann, hat eine ganze Menge Seiten gefressen. Da war doch etwas mehr an dieser simplen Verfahrensweise dran, als ich gedacht hatte.

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!