User Story Mapping: INVEST & Wie man Stories aufteilt

Ein flaches Backlog ist eine nach Priorität sortierte Liste. Es sagt Ihnen, was als Nächstes gebaut werden soll, aber nicht, wie die Teile zusammenpassen, und es macht es leicht, zehn polierte Funktionen zu liefern, die für den Nutzer nichts Ganzes ergeben. Eine User Story Map behebt das, indem sie Stories entlang der Reise eines Nutzers anordnet, sodass Sie das gesamte Produkt sehen und einen ersten Release schneiden können, der von Anfang bis Ende funktioniert.

Dieser Leitfaden behandelt, wie man eine Story Map erstellt, wie man den obersten Abschnitt in einen MVP-Umfang umwandelt, wie man jede Story mit INVEST prüft und welche Aufteilungsmuster große Stories in sprintgerechte Größen umwandeln. Wenn Sie zunächst die Grundlagen benötigen, beginnen Sie mit wie man User Stories schreibt.

Was eine User Story Map ist

Story Mapping wurde von Jeff Patton eingeführt, zunächst in einem Artikel aus dem Jahr 2005, „It's all in how you slice it“, dann in seinem Beitrag aus dem Jahr 2008 The new user story backlog is a map, und später in seinem Buch User Story Mapping (O'Reilly, 2014). Siehe auch seine story mapping resources und den Agile Alliance glossary entry.

Eine Karte hat zwei Richtungen:

• Von links nach rechts ist die Erzählung: die großen Aktivitäten, die ein Nutzer in der richtigen Reihenfolge durchläuft, und die Schritte innerhalb jeder Aktivität. Diese oberste Zeile wird als Backbone bezeichnet.
• Von oben nach unten sind Priorität und Detailgrad: Unter jedem Schritt befinden sich die Stories, die ihn ermöglichen, wobei die wichtigsten oben und Alternativen, Sonderfälle und Nice-to-haves unten stehen.

Horizontale Linien über die Karte unterteilen sie in Release-Slices. Alles oberhalb der ersten Linie ist das erste Release; es sollte jede Aktivität im Backbone abdecken, auch wenn nur dünn.

Wie man eine Story Map in 6 Schritten erstellt

Sie können dies an einer Wand mit Haftnotizen oder auf einem digitalen Whiteboard tun. Laden Sie die Personen ein, die den Umfang festlegen und die, die ihn umsetzen: Produkt, Design, mindestens einen Entwickler und idealerweise jemanden, der mit Kunden spricht. Eine erste Karte für ein kleines Produkt dauert in der Regel eine Arbeitssitzung von einigen Stunden.

1. Das Problem rahmen

Schreiben Sie auf, für wen das Produkt ist, welches Problem es löst und welches Ergebnis Ihnen zeigt, dass das erste Release funktioniert hat. Halten Sie es auf drei Sätze am oberen Rand der Karte. Jeder spätere Schnitt wird an diesem Ergebnis gemessen.

2. Den Backbone kartieren

Fragen Sie: „Was tut der Nutzer zuerst, und dann was?“ und schreiben Sie jede Aktivität auf eine Karte, von links nach rechts. Verwenden Sie Verben: „Einen Gassi-Geher finden“, nicht „Suchen“. Zerlegen Sie dann jede Aktivität in Schritte. Erzählen Sie die Geschichte laut, während Sie vorgehen; Lücken werden offensichtlich, wenn jemand sagt: „Moment, wie sind sie hierher gekommen?“

3. Die Details erkunden

Fügen Sie unter jedem Schritt die Stories hinzu, die es funktionieren lassen: Optionen, Alternativen, Fehlerfälle, Admin-Bedürfnisse. Filtern Sie noch nicht. Hier zahlt sich die Karte aus, denn Menschen bemerken fehlende Teile, wenn sie die gesamte Reise auf einmal sehen können.

4. Den Walking Skeleton finden

Der Walking Skeleton (ein Begriff von Alistair Cockburn) ist die dünnste Version des Produkts, die von Anfang bis Ende funktioniert. Wählen Sie die eine Story unter jedem Schritt, ohne die ein Nutzer nicht auskommt, und verschieben Sie sie nach oben. Wenn ein Schritt nichts Wesentliches hat, fragen Sie, ob er überhaupt zum Backbone gehört.

5. Releases aufteilen

Zeichnen Sie horizontale Linien, um Stories in Releases zu gruppieren. Geben Sie jedem Slice einen Namen, der das Ergebnis angibt, wie „Besitzer können einen Spaziergang buchen und bezahlen“, statt „Release 1“. Jeder Slice sollte für sich genommen nutzbar sein und eine Frage zum Produkt beantworten.

6. Den ersten Slice planen und die Karte lebendig halten

Schreiben Sie Akzeptanzkriterien für die Stories im ersten Slice (unser User-Story-Vorlage hat drei Formate), prüfen Sie jede mit INVEST, teilen Sie die zu großen auf und verschieben Sie sie in den Sprint-Backlog. Halten Sie die Karte sichtbar und aktualisieren Sie sie nach jedem Release; sie ist ein Planungswerkzeug, kein einmaliges Workshop-Ergebnis.

Beispiel: eine Story Map für eine Hundegassi-App

Hier ist eine verdichtete Karte für einen Marktplatz, der Hundebesitzer mit lokalen Gassi-Geher verbindet. Die Spalten sind der Backbone; jede Zeile ist ein Release-Slice.

Beachten Sie, was das Skeleton weglässt: keine Live-Verfolgung, keine Bewertungen, keine In-App-Nachrichten, und die Genehmigung von Gassigängern erfolgt manuell. Aber ein Besitzer kann trotzdem von der Registrierung zu einem abgeschlossenen, bezahlten Spaziergang kommen, was ausreicht, um zu testen, ob Menschen bereit sind, einen Fremden mit ihrem Hund spazieren zu schicken.

Wie die Map in einen MVP-Umfang übergeht

Der oberste Slice einer guten Map ist Ihr MVP-Umfang. Verwenden Sie diese Prüfungen, bevor Sie sich dafür entscheiden:

• Es deckt jede Aktivität im Backbone ab. Ein Produkt, das Buchungen, aber keine Bezahlung ermöglicht, ist kein MVP; es ist nur eine halbe Demo.
• Es bedient einen primären Nutzer und eine Hauptreise. Sekundäre Rollen (Admins, Partner) erhalten das Minimum, das den Ablauf aufrechterhält, oft ein Spreadsheet oder ein manueller Schritt.
• Es testet eine spezifische Annahme. Schreiben Sie die Frage, die der Slice beantwortet, daneben, zum Beispiel „Werden Besitzer vor dem Treffen mit dem Gassigänger bezahlen?“
• Manuelle Arbeit im Hintergrund ist erlaubt. Gassigänger manuell zu genehmigen oder Zusammenfassungen selbst zu senden, ist für die ersten Nutzer in Ordnung und zeigt, was sich lohnt zu automatisieren.
• Es passt zu Ihrem Budget und Zeitplan. Wenn nicht, kürzen Sie Stories innerhalb jeder Spalte (teilen Sie sie auf, unter Verwendung der Muster unten), anstatt ganze Spalten zu streichen.

Für Gründer ohne technischen Mitgründer ist die Map auch das nützlichste Dokument, das Sie einem Entwicklungsteam übergeben können: Sie zeigt das gesamte Produkt, das erste Release und die Begründung für den Schnitt auf einer Seite. Unser Leitfaden zu einen MVP als nicht-technischer Gründer erstellen deckt ab, was als Nächstes zu tun ist.

Die INVEST-Checkliste

Sobald Stories auf der Map sind, prüfen Sie jede im ersten Slice anhand von INVEST, dem Akronym, das Bill Wake 2003 in INVEST in guten Stories und SMART-Aufgaben.

Unabhängigkeit ist das schwierigste Kriterium, das vollständig erfüllt werden kann, und es ist in Ordnung, es als Ziel statt als Regel zu behandeln. Klein und Testbar sind die Kriterien, bei denen man streng sein sollte.

Wie man User Stories aufteilt

Teile Stories vertikal auf: Jedes Stück sollte weiterhin etwas liefern, das ein Nutzer sehen kann, durch jede Schicht des Systems. Aufteilen nach Schicht („Datenbank bauen“, „API bauen“, „Bildschirm bauen“) erzeugt Stücke, die nichts liefern, bis alle drei fertig sind, was den Zweck zunichte macht. Diese Muster, gesammelt in der Humanizing Work-Anleitung zum Aufteilen von User Stories von Richard Lawrence und Peter Green, decken die meisten Fälle ab.

Workflow-Schritte

Teile einen mehrstufigen Prozess in seine Schritte auf oder baue zuerst die einfache End-to-End-Version und füge später Schritte hinzu. „Spaziergang buchen“ wird zu: einen Slot anfragen; Walker akzeptiert; Eigentümer erhält eine Bestätigung. Später: Walker schlägt eine andere Zeit vor.

Variationen der Geschäftsregeln

Wenn eine Story mehrere Regeln hat, liefere zuerst die häufigste aus. „Stornierungs-Rückerstattungen“ wird zu: volle Rückerstattung, wenn 24 Stunden vorher storniert; teilweise Rückerstattung innerhalb von 24 Stunden; keine Rückerstattung, nachdem der Spaziergang begonnen hat.

Datenvariationen

Beginne mit einer Art von Daten und füge die anderen hinzu. „Suche nach Ort“ wird zu: Suche nach Postleitzahl; dann nach aktuellem Standort; dann durch Zeichnen eines Bereichs auf einer Karte.

Zuerst der Happy Path, dann die Unhappy Paths

Baue den Haupterfolgspfad, behandle dann Fehler als separate Stories, sortiert nach Häufigkeit und Schadensumfang. „Mit Karte bezahlen“ wird zu: erfolgreiche Zahlung; Karte abgelehnt; Zahlungsanbieter nicht verfügbar.

Operationen

„Hunde verwalten“ verbirgt Erstellen, Ansehen, Bearbeiten und Löschen. Oft werden für die erste Veröffentlichung nur Erstellen und Ansehen benötigt.

Schnittstellen- oder Plattformvariationen

Liefere zuerst auf einer Plattform oder mit einer Eingabemethode aus. Web vor Mobile oder Englisch vor anderen Sprachen, wenn es deine ersten Nutzer zulassen.

Zuerst die einfache Version, Performance später

Erst funktionieren lassen, dann schnell machen. Eine Walker-Liste, die für 50 Walker in drei Sekunden lädt, ist für eine Pilotstadt in Ordnung; optimisiere, wenn die Zahlen es rechtfertigen, als eigene Story.

Spike

Wenn eine Story aufgrund einer Unbekannten nicht geschätzt werden kann („Können wir den Live-Standort im Hintergrund auf beiden Telefonplattformen abrufen?“), spalte eine kurze, zeitlich begrenzte Untersuchung ab. Das Ergebnis des Spikes ist Wissen und eine besser geschätzte Story, keine ausgelieferte Funktionalität.

SPIDR: eine kurze Version zum Merken

Mike Cohn gruppiert die wichtigsten Aufteilungstechniken unter dem Akronym SPIDR: Spikes, Paths, Interfaces, Data und Rules (Fünf einfache, aber leistungsfähige Wege, User Stories aufzuteilen). Wenn eine Story zu groß ist und du nicht sicher bist, wo du anfangen sollst, gehe die fünf in dieser Reihenfolge durch.

Häufige Fehler beim Story Mapping

• Funktionen statt Nutzeraktivitäten abbilden. Ein Rückgrat aus „Login, Dashboard, Einstellungen“ beschreibt Bildschirme, nicht eine Reise.
• Die erste Scheibe nur eine Spalte tief bauen. Das Feinschliffen der Registrierung, bevor eine Buchung existiert, lässt einen ohne etwas zum Testen zurück.
• Die Karte zu detailliert gestalten. Wenn man Akzeptanzkriterien an die Wand schreibt, ist man vom Mapping zum Refinement übergegangen.
• Mapping ohne Entwickler im Raum. Scheiben, die ohne sie gezeichnet werden, verbergen oft teure Geschichten an der Spitze.
• Die Karte als abgeschlossen betrachten. Nach jeder Release-Version sollte man das Gelernte auf die Karte übertragen und die nächste Scheibe neu zuschneiden.

Für gut strukturierte Geschichten, die Sie für Ihre eigene Karte anpassen können, siehe unsere Beispielen für User Stories.

Werkzeuge für Story Mapping

Eine Wand und Haftnotizen funktionieren immer noch am besten für die erste Sitzung, bei der alle in einem Raum sind. Für Remote-Teams bieten allgemeine Whiteboards wie Miro und FigJam Story-Map-Vorlagen, und spezialisierte Werkzeuge wie StoriesOnBoard synchronisieren Karten mit Backlog-Trackern. Jira und ähnliche Tracker können Geschichten nach Epics gruppiert anzeigen, was das Rückgrat liefert, aber man braucht in der Regel ein Plugin oder ein Whiteboard, um Release-Scheiben zu sehen. Wählen Sie das Werkzeug, das Ihr Team offen halten wird; eine Karte, die niemand aktualisiert, ist innerhalb eines oder zweisprints nutzlos.

Häufig gestellte Fragen

Haben Sie eine Karte oder nur eine Idee und brauchen die erste Scheibe gebaut? Wir können Ihnen helfen, einen MVP-Umfang zuzuschneiden, der von Anfang bis Ende funktioniert, und ihn in kurzen Sprints auszuliefern. Siehe unsere monatlichen Entwicklungspläne.