Was vorher fertig sein muss
Eine User Story oder ein Backlog-Item liegt als Ausgangspunkt vor, mindestens als „Als ... möchte ich ... damit ...“-Satz mit Owner.
Product, Development und QA sind verbindlich für die Session zugesagt, jeder mit Entscheidungsmandat im jeweiligen Bereich.
Was vor Start vorliegen muss
Whiteboard oder Miro-Board mit vier Farben Stickies (gelb Story, blau Regel, grün Beispiel, rot offene Frage); Timer; Link zum Backlog-Item; bekannte Edge Cases aus Support oder Logs.
Ein Facilitator (meist Product Owner oder BA), eine Person aus Entwicklung, eine Person aus QA oder Test. Optional: Domain Expert für Spezialfälle. Maximal sechs Personen, sonst wird die Diskussion zäh.
Story-Titel und Akzeptanzentwurf; aktuelle Implementierung des nächstliegenden Flows; bekannte Sonderfälle aus Production; verlinkte Designs; geschätzter Liefer-Slice.
25-45 min pro Story
Story-Karte gelb in die Mitte. Darunter horizontale Bahnen für Regeln (blau). Pro Regel rechts Beispiele (grün). Rote Stickies werden gesammelt, nicht sofort beantwortet. Timer auf 30 min, danach Entscheidung über Verlängerung oder Vertagung.
Die eine Frage, die diese Methode beantwortet
Welche konkreten Beispiele zeigen, dass diese Story fertig ist, und welche Regel verbindet sie miteinander?
Marker: Minute
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
10-5 min | 5 min | Story vorlesen und im Wortlaut auf die gelbe Karte. Kontext, Ziel und out-of-scope kurz benennen. Keine Lösungsdiskussion, nur Verständnisfragen. | Wenn schon hier Diskussion über Implementierung startet, Timer pausieren und zurück auf Wert und Nutzer lenken. |
25-20 min | 15 min | Beispiele sammeln: konkrete Eingaben und erwartete Ausgaben mit Datum, Betrag, Status. Jedes Beispiel als grüne Karte mit klar beobachtbarem Ergebnis. | Beispiele wie „normaler Fall“ sind unbrauchbar. Verlangen: welcher Nutzer, welche Daten, welches Ergebnis. Negativbeispiele explizit einfordern. |
320-30 min | 10 min | Regeln aus den Beispielen ableiten: blaue Karte über die zugehörigen Beispiele. Eine Regel pro Cluster von Beispielen mit gleichem Verhalten. | Wenn ein Beispiel zu keiner Regel passt, ist es entweder Edge Case (neue Regel) oder out-of-scope (eigene Story). Nicht in bestehende Regel pressen. |
430-40 min | 10 min | Rote Karten für offene Fragen sichten. Pro Frage entscheiden: vor Umsetzung klären (Owner und Frist) oder als Annahme dokumentieren mit Risiko. | Mehr als fünf rote Karten signalisieren: Story ist nicht ready. Nicht trotzdem starten, sonst kommt sie durch QA zurück. |
540-45 min | 5 min | Story-Splitting prüfen: liegt eine Regel klar erst nach dem Release, wird sie als eigene Story herausgeschnitten und priorisiert. | Ein Beispiel-Map mit über 8 Regeln ist meist mehrere Stories. Splitten ist kein Scheitern der Methode, sondern ihr Hauptnutzen. |
Was am Ende rauskommt
Beispiel-Map als Foto oder Miro-Snapshot plus strukturierte Aufnahme im Backlog-Item: Story, Liste Regeln mit zugehörigen Beispielen in Given-When-Then, offene Fragen mit Owner und Antwortfrist.
Map-Snapshot beim Closing der Session ins Backlog-Item. Nachträgliche Beispiele aus Test oder Production als Edit am Ende anhängen mit Datum und Quelle. Bei Story-Split eigene Items erzeugen, Ursprung verlinken.
Kompakte Arbeitsvorlage für Example Mapping mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Example Mapping Checklist
- [ ] Ziel und Kontext geklärt
- [ ] Input-Material gesammelt
- [ ] Beteiligte und Rollen benannt
- [ ] Durchführung nach Run Sheet vorbereitet
- [ ] Ergebnisartefakte erstellt
- [ ] Example Map aktualisiert
- [ ] Acceptance Criteria aktualisiert
- [ ] Open Questions aktualisiert
- [ ] Offene Fragen dokumentiert
- [ ] Nächster Schritt mit Owner und Datum gesetztKonkret gefülltes Szenario
## Story
Als eingeloggter Kunde möchte ich einen bestellten Artikel innerhalb von 14 Tagen retournieren, damit ich Fehlkäufe rückabwickeln kann.
## Regel 1: 14-Tage-Frist ab Zustelldatum
- Bestellung 4711 zugestellt am 01.05.2026, Retoure am 14.05.2026 -> akzeptiert.
- Bestellung 4712 zugestellt am 01.05.2026, Retoure am 16.05.2026 -> abgelehnt mit Hinweis „Frist abgelaufen“.
## Regel 2: Personalisierte Artikel ausgeschlossen
- Standardartikel SKU-123 -> retournierbar.
- Gravur-Artikel SKU-987 -> nicht retournierbar, Hinweis „personalisiert“.
## Offene Fragen
- Was passiert bei Teilretoure einer Mengenposition? Owner: @lisa, Antwort bis 20.05.
- Wie zählt die Frist bei Lieferung an Packstation? Owner: @ben, Antwort bis 20.05.
## Split-Entscheidung
Regel „Retoure-Kosten bei Wertgrenze“ wird als eigene Story PRD-58 ausgelagert.Symptome erkennen, gegensteuern
Grüne Karten enthalten Sätze wie „normaler Fall“ oder „mit Fehler“ ohne konkrete Daten.
Pro Beispiel echte Werte fordern: Kundennummer, Betrag, Status, Datum. Wer kein Beispiel mit Daten formulieren kann, hat die Regel nicht verstanden.
Facilitator schreibt Regeln zuerst, Beispiele werden danach passend gesucht.
Reihenfolge erzwingen: erst Beispiele sammeln, dann Regeln daraus ableiten. So fallen Lücken und Sonderfälle auf, die in der Theorie unsichtbar bleiben.
Session driftet in Detail-Recherche, eine offene Frage frisst 20 min.
Rote Karten parken. Nach 30 min entscheiden: klären (Owner, Frist) oder annehmen (mit Risikohinweis). Klärung passiert ausserhalb der Session.
Map hat 10+ Regeln, Beispiele explodieren, Diskussion endet nicht.
Splitten statt fortsetzen. Pro Regelcluster eine eigene Story. Ursprüngliche Story als Epic markieren, Mapping pro Sub-Story neu.
Negativbeispiele und Edge Cases tauchen erst im Test auf, Map ist optimistisch.
Mindestens eine testorientierte Person verpflichtend. Ohne QA wird die Methode zu Backlog-Refinement light und verfehlt den Hauptnutzen.
Map endet auf Whiteboard, im Ticket steht weiter der alte Akzeptanztext.
Im Anschluss direkt Given-When-Then aus Beispielen ins Ticket. Story-Status erst auf ready, wenn Übertragung erfolgt ist.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.