Meine Session planen

# Session Brief: Example Mapping

## Ziel
Artefakt: Example Map

## Arbeitsfrage
Welche konkreten Beispiele zeigen, dass diese Story fertig ist, und welche Regel verbindet sie miteinander?

## Kontext
Story-Titel und Akzeptanzentwurf; aktuelle Implementierung des nächstliegenden Flows; bekannte Sonderfälle aus Production; verlinkte Designs; geschätzter Liefer-Slice.

## Setup
- Format: Methoden-Session
- Dauer: 25-45 min pro Story
- Modus: Workshop
- Teilnehmende: 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.
- Owner: Ein Facilitator (meist Product Owner oder BA), eine Person aus Entwicklung, eine Person aus QA oder Test
- Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
- Ergebnislogik: Artefakt fertigstellen

## Beteiligungslogik
Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

## Ergebnislogik
Die Session arbeitet direkt auf Example Map hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
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.

## Vorbereitung
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.

## Agenda
1. 0-5 min (5 min)
   Owner: Facilitator
   Aktion: Story vorlesen und im Wortlaut auf die gelbe Karte. Kontext, Ziel und out-of-scope kurz benennen. Keine Lösungsdiskussion, nur Verständnisfragen. Hinweis: Wenn schon hier Diskussion über Implementierung startet, Timer pausieren und zurück auf Wert und Nutzer lenken. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Example Map

2. 5-20 min (15 min)
   Owner: Facilitator
   Aktion: Beispiele sammeln: konkrete Eingaben und erwartete Ausgaben mit Datum, Betrag, Status. Jedes Beispiel als grüne Karte mit klar beobachtbarem Ergebnis. Hinweis: Beispiele wie „normaler Fall“ sind unbrauchbar. Verlangen: welcher Nutzer, welche Daten, welches Ergebnis. Negativbeispiele explizit einfordern. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Acceptance Criteria

3. 20-30 min (10 min)
   Owner: Facilitator
   Aktion: Regeln aus den Beispielen ableiten: blaue Karte über die zugehörigen Beispiele. Eine Regel pro Cluster von Beispielen mit gleichem Verhalten. Hinweis: 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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Open Questions

4. 30-40 min (10 min)
   Owner: Facilitator
   Aktion: Rote Karten für offene Fragen sichten. Pro Frage entscheiden: vor Umsetzung klären (Owner und Frist) oder als Annahme dokumentieren mit Risiko. Hinweis: Mehr als fünf rote Karten signalisieren: Story ist nicht ready. Nicht trotzdem starten, sonst kommt sie durch QA zurück. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Example Map

5. 40-45 min (5 min)
   Owner: Owner
   Aktion: Story-Splitting prüfen: liegt eine Regel klar erst nach dem Release, wird sie als eigene Story herausgeschnitten und priorisiert. Hinweis: Ein Beispiel-Map mit über 8 Regeln ist meist mehrere Stories. Splitten ist kein Scheitern der Methode, sondern ihr Hauptnutzen. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Acceptance Criteria

6. Artefakt veröffentlichen (10 min)
   Owner: Owner
   Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.
   Output: Example Map

## Abschluss
- Ergebnisartefakt aktualisieren: Example Map
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.

# Example Map: Example Mapping

## Arbeitsfrage
Welche konkreten Beispiele zeigen, dass diese Story fertig ist, und welche Regel verbindet sie miteinander?

## Kontext
Story-Titel und Akzeptanzentwurf; aktuelle Implementierung des nächstliegenden Flows; bekannte Sonderfälle aus Production; verlinkte Designs; geschätzter Liefer-Slice.

## Beteiligte
- Owner: Ein Facilitator (meist Product Owner oder BA), eine Person aus Entwicklung, eine Person aus QA oder Test
- Teilnehmende: 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.

## Input
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.

## Vorlage
# 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 gesetzt

## Fertigstellungscheck
- Example Map ist vollständig genug für Review:
- Ablageort:
- Version / Status:
- Review durch:
- Nächster Schritt:

## Nächster Schritt
- Ergebnis prüfen
- offene Fragen markieren
- Review oder Entscheidung terminieren