User Story Mapping - Die Technik für besseres Nutzerverständnis in der agilen Produktentwicklung

User Story Mapping

Inhalt

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

Kapitel 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

Kapitel 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!

Kapitel 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

Kapitel 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?

Kapitel 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

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

Kapitel 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

Kapitel 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

Kapitel 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

Kapitel 10 – Wir backen uns eine Story

Ein Rezept kreieren

Den großen Kuchen aufteilen

Kapitel 11 – Steine brechen

Auf die Größe kommt es immer an

Stories sind wie Steine

&klein;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

Kapitel 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

Kapitel 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

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

Kapitel 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?

Kapitel 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

Kapitel 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

Kapitel 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

Index

Über den Autor

Kolophon