O'Reilly logo

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

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

Book Description

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, dass dem Nutzer nicht hilft.

Table of Contents

  1. Widmung
  2. Vorwort
    1. Vorwort von Martin Fowler
    2. Vorwort von Alan Cooper
    3. Vorwort von Marty Cagan
  3. Über dieses Buch
    1. Wieso ich?
    2. Wenn du Schwierigkeiten mit Stories hast, ist dieses Buch für genau Dich
    3. Wer sollte dieses Buch lesen?
    4. Ein paar Konventionen in diesem Buch
      1. Die Überschriften in den einzelnen Kapiteln weisen euch den Weg durch das Thema.
    5. Wie dieses Buch aufgebaut ist
      1. Story Mapping aus 3.000 Metern Höhe
      2. User Stories verinnerlichen
      3. Bessere Backlogs
      4. Bessere Builds
  4. Hier geht's los
    1. Stille Post
    2. Gemeinsames Verständnis ist erschreckend einfach zu erreichen
    3. Vergesst perfekte Dokumentation
    4. Gute Dokumente sind wie Urlaubsfotos
    5. Dokumentiert, um euch zu erinnern
    6. Über das Richtige reden
    7. Jetzt und später
    8. Es geht nicht um Software
    9. Okay, es geht nicht nur um Menschen
    10. Produziert weniger
    11. A wie Anforderungskatalog
    12. Das ist alles
  5. 1. Das große Ganze
    1. Das Wort mit »A«
    2. Stories erzählen, nicht Geschichten schreiben
    3. Die ganze Geschichte erzählen
    4. Gary und die Tragödie des flachen Backlogs
    5. Talk and Doc
    6. Umreißt eure Idee
    7. Beschreibt eure Kunden und User
    8. Erzähl die Stories deiner User
    9. Details und Möglichkeiten erforschen
  6. 2. Planen, (um) weniger zu produzieren
    1. Mapping hilft großen Gruppen, gemeinsames Verständnis herzustellen.
    2. Mapping hilft euch, die Löcher in eurer Geschichte zu entdecken
    3. Es ist immer zu viel (zu tun)
    4. Definiert das Minimum für ein Minimum Viable Product Release
    5. Definiert eine Release Roadmap
    6. Priorisiert Outcomes, nicht Features
    7. Es ist Magie – wirklich.
    8. Die Sache mit dem MVP
    9. Das neue MVP ist gar kein Produkt!
  7. 3. Planen, (um) schneller zu lernen
    1. Diskutiert die Chancen
    2. Validiert das Problem
    3. Benutzt Prototypen, um etwas zu lernen
    4. Was User Wollen
    5. Lernt aus euren Builds
    6. Iteriert bis zum MVP
    7. Wie man es falsch macht
    8. Validiertes Lernen
    9. Minimiert eure Experimente. Wirklich.
    10. Zusammenfassung
  8. 4. Planen, (um) rechtzeitig fertig zu werden
    1. Redet mit dem Team
    2. Die Kunst des gekonnten Schätzens
    3. Plant, Stück für Stück zu produzieren
    4. Macht nicht aus jedem Slice ein Release
    5. Das andere Geheminis gekonnter Schätzungen
    6. Managt euer Budget
      1. Was würde da Vinci tun?
    7. Iterativ UND inkrementell
    8. Strategien: Eröffnungs-, Mittel- und Endspiel
    9. Markiert eure Entwicklungsstrategie in einer Map.
    10. Es geht um das Risiko.
    11. Wie geht es weiter?
  9. 5. Ihr wisst schon, wie es geht
    1. 1. Schreibt eure Story auf – einen Schritt nach dem anderen
      1. Tasks: das, was wir tun
      2. Meine Tasks sind nicht Eure Tasks.
      3. Ich bin nur ein bisschen detailverliebter
    2. 2. Organisiert eure Story
      1. Fehlende Details ergänzen
    3. 3. Entdeckt alternative Stories
      1. Bleibt im Fluss
    4. 4. Komprimiert die Map und erzeugt einen Backbone
    5. 5. Gruppiert Tasks, die euch helfen, einen bestimmten Outcome zu erzielen
    6. Fertig! Ihr habt alle wichtigen Konzepte gelernt!
    7. Do Try This at Home (oder bei der Arbeit)
    8. Die Map dreht sich ums Jetzt, nicht ums Später
    9. Probiert es wirklich aus
    10. Mit Software ist es schwieriger
    11. Die Map ist nur der Anfang
  10. 6. Die wahre Geschichte der Stories
    1. Kents verstörend einfache Idee
    2. Einfach ist nicht leicht
    3. Ron Jeffries und die 3 Cs
      1. 1. Karte (Card)
      2. 2. Konversation (Conversation)
      3. 3. Bestätigung (Confirmation)
    4. Worte und Bilder
    5. Das war's schon.
  11. 7. Bessere Stories erzählen
    1. Connextras Tolles Template
    2. Template-Zombies und der Schneepflug
    3. Checkliste: Worüber ihr euch wirklich unterhalten solltet
    4. Macht Urlaubsfotos
    5. Das ist eine Menge Zeug
  12. 8. Nicht alles steht auf der Karte
    1. Unterschiedliche Leute, unterschiedliche Konversationen
    2. Wir brauchen eine größere Karteikarte
    3. Strahler und Kühltruhen
    4. Dafür ist das Werkzeug nicht gedacht
      1. Gemeinsames Verständnis herstellen
      2. Erinnern
      3. Tracking
  13. 9. Die Karteikarte ist nur der Anfang
    1. Habt eine klare Vorstellung davon, was ihr konstruiert
    2. Entwickelt eine mündliche Tradition des Geschichtenerzählens
    3. Inspiziert das Ergebnis eurer Arbeit
    4. Es geht nicht um Euch
    5. Entwickelt, um zu lernen.
    6. Es ist nicht immer Software
    7. Plant, zu lernen, und lernt, zu planen
  14. 10. Wir backen uns eine Story
    1. Ein Rezept kreieren
    2. Den großen Kuchen aufteilen
  15. 11. Steine brechen
    1.  
    2. Auf die Größe kommt es immer an
    3. Stories sind wie Steine
    4. Epen sind große Steine, die manchmal benutzt werden, um Menschen damit zu schlagen
    5. Themen organisieren Story-Gruppen
    6. Vergesst diese Begriffe und konzentriert euch darauf, Stories zu erzählen
    7. Beginnt mit Chancen (Opportunities)
    8. Entdeckt eine Minimum Viable Solution
    9. Vertieft euch in die Details jeder einzelnen Story im Delivery-Prozess
    10. Redet weiter, während ihr produziert
    11. Evaluiert jedes Stück
    12. Evaluiert mit Usern und Kunden
    13. Evaluiert mit Business-Stakeholdern
    14. Evaluiert auch nach dem Release weiter
  16. 12. Steinebrecher
    1. Wertvoll – benutzbar – realisierbar
    2. Ein Discovery-Team benötigt für den Erfolg viele andere Personen
    3. Die drei Amigos
    4. Produkt-Owner als Produzenten
    5. Es ist kompliziert
  17. 13. Beginnt mit Chancen
    1. Führt Konversationen über Chancen
    2. Tiefer graben, wegwerfen oder darüber nachdenken
    3. Chance sollte kein Euphemismus sein
    4. Story Mapping und Chancen (Opportunities)
    5. Seid wählerisch
  18. 14. Mit Discovery gemeinsames Verständnis aufbauen
    1. Bei Discovery geht es nicht um das Schreiben von Software
    2. Vier essenzielle Schritte der Discovery
      1. 1. Umreißt die Idee (Framing)
      2. 2. Versteht eure Kunden und User
        1. Skizziert einfache Personas
        2. Legt Organisationsprofile an – Orgzonas
        3. Mappt, wie die User heute arbeiten
      3. 3. Stellt euch eure Lösung vor
        1. Mappt eure Lösung
        2. Worte und Bilder
        3. Validiert Vollständigkeit
        4. Validiert technische Bedenken
        5. Spielt »Was-ist«
        6. Feiert noch nicht
      4. 4. Minimieren und Planen
        1. Es ist immer zu viel
        2. Das Geheimnis der Priorisierung
    3. Discovery-Aktivitäten, Diskussionen und Artefakte
    4. Discovery dient der Herstellung von gemeinsamem Verständnis.
  19. 15. User-Discovery für validiertes Lernen
    1. Wir liegen meistens falsch
    2. Die schlechte alte Zeit
    3. Einfühlen, Fokussieren, Ideen Sammeln, Prototypen Bauen, Testen
    4. Wie man etwas Gutes versaut
    5. Kurze Zyklen validierten Lernens
    6. Wie Lean Startup Thinking das Produktdesign verändert
      1. Beginnt mit Raten
      2. Benennt eure riskanten Annahmen
      3. Designt und erstellt einen kleinen Test
      4. Messt, indem ihr euren Test mit Kunden und Usern macht
      5. Überdenkt eure Lösung und eure Annahmen
    7. Stories und Story Maps?
  20. 16. Verfeinern, Definieren, Produzieren
    1. Karteikarten, Konversationen, mehr Karten, noch mehr Konversationen ...
    2. Schneiden und Polieren
    3. Der Story-Workshop
    4. Sprint- oder Iterationsplanung?
    5. Menschenmengen kollaborieren nicht
    6. Aufteilen und Ausdünnen
    7. Benutzt eure Story Map während der Delivery
    8. Benutzt eine Map, um Fortschritte zu visualisieren
    9. Benutzt einfache Story Maps in Story-Workshops
  21. 17. Stories sind genau genommen wie Asteroiden
    1. Zerbrochene Steine wieder zusammenfügen
    2. Übertreibt es nicht mit dem Mapping
    3. Zerbrecht euch nicht den Kopf über Kleinkram
  22. 18. Lernt aus jedem Build
    1. Review im Team
    2. Review mit anderen aus eurem Unternehmen
    3. Genug
    4. Lernt von Usern
    5. Lernt aus euren Releases
    6. Outcomes nach Zeitplan
    7. Benutzt eine Map, um zu evaluieren, ob ihr bereit für den Release seid
  23. Das Ende. Oder?
  24. Danksagung
  25. Literatur
  26. Stichwortverzeichnis
  27. Kolophon
  28. Copyright