Was vorher fertig sein muss
Eine User Story oder ein Backlog Item liegt als Entwurf mit Titel, Beschreibung und vorlaeufigen Akzeptanzkriterien vor.
Die Story ist auf Example-Mapping-Reife (mit zu wenigen Beispielen) oder benoetigt Beispiele zur Klaerung.
Was vor Start vorliegen muss
Story im Backlog-Tool; Whiteboard oder Miro mit Spalten (Akzeptanzkriterien, Beispiele, Fragen); Verlinkung zu Designs, APIs, Datenmodellen; Timer.
Drei Amigos: ein Vertreter Business/Product (Was und Warum), ein Vertreter Development (Wie), ein Vertreter Test/QA (Was kann brechen). Maximal vier Personen, sonst wird es Story-Refinement.
Story-Entwurf inkl. Akzeptanzkriterien; relevante Designs, Mockups, API-Spezifikationen; bekannte Edge Cases; Definition of Ready.
20-45 min pro Story
Timer setzen. Story-URL teilen. Regel: jeder spricht aus seiner Perspektive, kein Lifestyle-Talk. Ergebnis ist Story-Update mit klaren Akzeptanzkriterien, Beispielen und offenen Fragen.
Die eine Frage, die diese Methode beantwortet
Sind Was, Wie und Was-kann-brechen so klar, dass die Story ohne weiteres Refinement umgesetzt werden kann?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Story-Walkthrough | 5-10 min | Product erlaeutert die Story, das Outcome und das Why. Akzeptanzkriterien werden vorgelesen. Erste Verstaendnisfragen aus Dev und QA werden gesammelt. | Wenn die Story-Beschreibung mehr als 5 min Erklaerung braucht, ist sie nicht refinement-fertig. Story zerlegen oder zurueck zum PO. |
2Phase 2: Beispiele und Edge Cases | 10-15 min | Pro Akzeptanzkriterium konkrete Beispiele (Given-When-Then) sammeln. QA fragt aktiv nach Edge Cases, Fehlerfaellen, Boundary-Werten. Dev pruegt auf Umsetzbarkeit. | Drei Amigos arbeiten parallel an einer Story-Ebene. Wenn nur PO spricht, kippt die Methode zurueck in Briefing. Aktive Fragen erzwingen. |
3Phase 3: Offene Fragen und Risiken | 5-10 min | Liste offener Fragen am Board. Annahmen kennzeichnen. Risiken (technisch, business) markieren. Definition of Ready abgleichen. | Wenn mehr als 3 offene Fragen kritisch sind, ist die Story nicht ready. Lieber zurueck zum PO und nicht in den Sprint nehmen. |
4Phase 4: Story-Update | 5-10 min | Story aktualisieren: aktualisierte Akzeptanzkriterien, Beispiele, offene Fragen, evtl. Definition of Done-Add-Ons. Sub-Task fuer offene Fragen mit Owner. | Ohne Story-Update verpufft das Treffen. Update direkt im Backlog-Tool, nicht nur muendlich. Wer das Update macht, vorher festlegen. |
Was am Ende rauskommt
Aktualisierte Story im Backlog-Tool mit klaren Akzeptanzkriterien, Given-When-Then-Beispielen, Edge-Case-Liste, offenen Fragen und Definition-of-Done-Ergaenzungen. Ergaenzt um Verweise auf Designs und Spezifikationen.
Story-Aenderungen via Backlog-Tool nachverfolgt. Drei-Amigos-Datum, Beteiligte und Hauptergebnis als Kommentar oder Custom Field. Bei groesseren Aenderungen Vorgaengerakzeptanzkriterien archivieren.
Kompakte Arbeitsvorlage für Three Amigos mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Three Amigos Arbeitsvorlage
## Ziel
Kurze Klärung einer Story aus Business-, Development- und Test-Perspektive.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Clarified Story:
- Test Examples:
- Open Questions:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Three Amigos - Story WS-1247 „Workspace-Filter nach Auslastung“
**Beteiligte**: PO @anna, Dev @ben, QA @lisa. Dauer 35 min.
**Outcome**: Nutzer findet Workspaces mit gewuenschter Auslastung schneller.
**Aktualisierte Akzeptanzkriterien**
1. Im Suchfilter erscheint Option „Auslastung“ mit Werten Niedrig (<30%), Mittel (30-70%), Hoch (>70%).
2. Auslastungswert wird aus Buchungen der letzten 7 Tage berechnet.
3. Filter ist kombinierbar mit Standort- und Preisfiltern.
4. Filter funktioniert auf Mobil und Desktop.
**Beispiele**
- Given: Suche in Berlin mit Filter „Niedrig“. When: Auswahl. Then: nur Workspaces mit <30% Auslastung in den letzten 7 Tagen.
- Edge: Workspace existiert <7 Tage. Auslastung wird basierend auf verfuegbaren Tagen normalisiert.
- Edge: Keine Treffer. Hinweis-Banner mit Vorschlag, Filter zu lockern.
**Offene Fragen**
- Was passiert mit Workspaces, die in den letzten 7 Tagen geschlossen waren? -> Klaerung mit Product, Sub-Task WS-1247-Q1, Owner @anna, bis 19.05.
**Definition-of-Done-Erweiterung**
- Performance: Filter erhoeht Suchlatenz um max 50 ms p95.
- Analytics: Click-Event auf Filterwert getrackt.
**Status**: Story ready fuer Sprint 48 nach Klaerung WS-1247-Q1.Symptome erkennen, gegensteuern
PO erklaert 20 min, Dev und QA nicken, keine Fragen.
Facilitator (oder rotierende Rolle) erzwingt aktive Fragen pro Akzeptanzkriterium. Wenn QA still bleibt, gezielt Edge-Case-Frage stellen.
Sechs Stories werden behandelt, jede oberflaechlich, niemand zustaendig.
Three Amigos ist pro Story, nicht pro Backlog. Bei mehreren Stories separate Slots. Maximal eine Story pro Termin.
Liste mit Fragen existiert, niemand klaert sie bis zum Sprint.
Pro offene Frage Sub-Task mit Owner und Frist. Story bleibt im Status „blocked“ bis Klaerung.
Treffen war hilfreich, Story im Backlog unveraendert.
Story-Update als letzter Schritt verpflichtend. Wer es macht, am Beginn festlegen. Tool-Link sichtbar waehrend des Termins.
Diskussion abstrakt, Edge Cases werden vergessen.
Mindestens drei Given-When-Then-Beispiele pro Story. QA forciert Edge Cases. Wenn keine Beispiele moeglich, Story zu vage.
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.