methodatlas
Session Builder

Meine Session planen

Plane einen konkreten Arbeitsblock mit Agenda, Rollen, Vorbereitung und kopierbarem Ergebnisartefakt.

Methoden-Session20-40 min pro StoryWorkshopAcceptance Criteria

Session: Acceptance Criteria Workshop

Der Plan übersetzt die Methode in einen konkreten moderierten Arbeitsblock. Die Eingaben fließen direkt in Session Brief und Arbeitsartefakt.

Automatisch abgeleitet

Methoden-Session mit 3-6. Der Plan nutzt die vorhandene Methodenlogik und das Runsheet.

Runsheet
Beteiligungslogik
Teamrunde, gemeinsames Arbeiten und Alignment

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

Ergebnislogik
Artefakt fertigstellen

Die Session arbeitet direkt auf Acceptance Criteria hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

  1. 1

    Phase 1: Story-Kurzbeschreibung fixieren

    3-5 min

    Story als Titel und Nutzerwert-Satz an Wand. Klärungsfragen zu Scope. PO bestätigt Verständnis. Hinweis: Wenn nach 5 min Scope unklar, Story zurück in Discovery. Akzeptanzkriterien ohne Scope-Konsens sind nutzlos.

    FacilitatorAcceptance Criteria
  2. 2

    Phase 2: Happy-Path-Kriterien

    5-10 min

    Given-When-Then für den Standardfall. Konkrete Eingabewerte, beobachtbare Ausgabe. Mindestens 2-3 Kriterien pro Story. Hinweis: Vage Kriterien wie „funktioniert“ oder „intuitiv“ ablehnen. Pro Kriterium muss Test-Frage möglich sein: „Wie würde ich das prüfen?“

    FacilitatorStory-Update
  3. 3

    Phase 3: Edge Cases und Sonderfälle

    5-15 min

    Tester treibt Edge-Case-Suche: Nullwerte, Max-Werte, leere Eingaben, parallele Aktionen. Pro Edge Case eigenes Kriterium. Hinweis: Wenn keine Edge Cases entstehen, Story zu oberflächlich verstanden. Mindestens 30% der Kriterien sollten Edge Cases abdecken.

    FacilitatorAcceptance Criteria
  4. 4

    Phase 4: Negative Pfade und Fehlerfälle

    5-10 min

    Was passiert bei ungültiger Eingabe, fehlender Berechtigung, externem Fehler. Erwartete Fehlermeldung oder System-Reaktion als Kriterium. Hinweis: Negative Pfade werden oft vergessen. PO entscheidet, ob Fehlerfall in Story oder als eigene Story. Beide Optionen valide, aber bewusst.

    FacilitatorStory-Update
  5. 5

    Phase 5: Review und Übernahme

    3-5 min

    Kriterien laut vorlesen. Engineer und Tester bestätigen Umsetzbarkeit/Prüfbarkeit. Kriterien ins Story-Werkzeug übertragen. Hinweis: Vorlesen deckt Unklarheiten auf. Bei Widerspruch zwischen Rollen sofort klären, nicht in Sprint mitnehmen.

    OwnerAcceptance Criteria
  6. 6

    Artefakt veröffentlichen

    10 min

    Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.

    OwnerAcceptance Criteria
Nutzbares Artefakt

Session Brief

Für Einladung, Board, Ticket, PR-Beschreibung oder Workshop-Notiz.

session-brief.md

Session Brief: Acceptance Criteria Workshop

Ziel

Artefakt: Acceptance Criteria

Arbeitsfrage

Welche konkreten, prüfbaren Kriterien beschreiben Happy-Path, Edge Cases und negative Pfade dieser Story so eindeutig, dass alle drei Rollen Definition of Done teilen?

Kontext

Story-Beschreibungen mit Nutzerwert; bekannte Constraints (Performance, Compliance, Browser-Support); Definition of Done; ähnliche bestehende Stories als Referenz.

Setup

  • Format: Methoden-Session
  • Dauer: 20-40 min pro Story
  • Modus: Workshop
  • Teilnehmende: Ein Facilitator (PO, Scrum Master oder BA); Product Owner für Scope; mindestens ein Engineer; ein Tester für Edge Cases; optional Domain-Experte bei fachlicher Tiefe.
  • Owner: Ein Facilitator (PO, Scrum Master oder BA)
  • 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 Acceptance Criteria hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

Input

Whiteboard oder Miro-Board mit Spalten pro Story; Story-Karten oder Tickets sichtbar; Given-When-Then-Vorlage als Banner; Stifte; Timer; Definition of Done als Referenz.

Vorbereitung

Pro Story eine Sektion im Board. Given-When-Then-Template sichtbar. Definition of Done als Sidebar. Regel: keine vagen Kriterien (schnell, einfach, schön). Konkrete, prüfbare Aussagen.

Agenda

  1. Phase 1: Story-Kurzbeschreibung fixieren (3-5 min) Owner: Facilitator Aktion: Story als Titel und Nutzerwert-Satz an Wand. Klärungsfragen zu Scope. PO bestätigt Verständnis. Hinweis: Wenn nach 5 min Scope unklar, Story zurück in Discovery. Akzeptanzkriterien ohne Scope-Konsens sind nutzlos. Output: Acceptance Criteria

  2. Phase 2: Happy-Path-Kriterien (5-10 min) Owner: Facilitator Aktion: Given-When-Then für den Standardfall. Konkrete Eingabewerte, beobachtbare Ausgabe. Mindestens 2-3 Kriterien pro Story. Hinweis: Vage Kriterien wie „funktioniert“ oder „intuitiv“ ablehnen. Pro Kriterium muss Test-Frage möglich sein: „Wie würde ich das prüfen?“ Output: Story-Update

  3. Phase 3: Edge Cases und Sonderfälle (5-15 min) Owner: Facilitator Aktion: Tester treibt Edge-Case-Suche: Nullwerte, Max-Werte, leere Eingaben, parallele Aktionen. Pro Edge Case eigenes Kriterium. Hinweis: Wenn keine Edge Cases entstehen, Story zu oberflächlich verstanden. Mindestens 30% der Kriterien sollten Edge Cases abdecken. Output: Acceptance Criteria

  4. Phase 4: Negative Pfade und Fehlerfälle (5-10 min) Owner: Facilitator Aktion: Was passiert bei ungültiger Eingabe, fehlender Berechtigung, externem Fehler. Erwartete Fehlermeldung oder System-Reaktion als Kriterium. Hinweis: Negative Pfade werden oft vergessen. PO entscheidet, ob Fehlerfall in Story oder als eigene Story. Beide Optionen valide, aber bewusst. Output: Story-Update

  5. Phase 5: Review und Übernahme (3-5 min) Owner: Owner Aktion: Kriterien laut vorlesen. Engineer und Tester bestätigen Umsetzbarkeit/Prüfbarkeit. Kriterien ins Story-Werkzeug übertragen. Hinweis: Vorlesen deckt Unklarheiten auf. Bei Widerspruch zwischen Rollen sofort klären, nicht in Sprint mitnehmen. 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: Acceptance Criteria

Abschluss

  • Ergebnisartefakt aktualisieren: Acceptance Criteria
  • Ablageort, Version und Review-Empfänger festlegen.
  • Owner, nächster Schritt und Reviewtermin festlegen.
Nutzbares Artefakt

Arbeitsartefakt

Vorgefüllter Startpunkt auf Basis der passenden Vorlage.

arbeitsartefakt.md

Acceptance Criteria: Acceptance Criteria Workshop

Arbeitsfrage

Welche konkreten, prüfbaren Kriterien beschreiben Happy-Path, Edge Cases und negative Pfade dieser Story so eindeutig, dass alle drei Rollen Definition of Done teilen?

Kontext

Story-Beschreibungen mit Nutzerwert; bekannte Constraints (Performance, Compliance, Browser-Support); Definition of Done; ähnliche bestehende Stories als Referenz.

Beteiligte

  • Owner: Ein Facilitator (PO, Scrum Master oder BA)
  • Teilnehmende: Ein Facilitator (PO, Scrum Master oder BA); Product Owner für Scope; mindestens ein Engineer; ein Tester für Edge Cases; optional Domain-Experte bei fachlicher Tiefe.

Input

Whiteboard oder Miro-Board mit Spalten pro Story; Story-Karten oder Tickets sichtbar; Given-When-Then-Vorlage als Banner; Stifte; Timer; Definition of Done als Referenz.

Vorlage

Acceptance Criteria Workshop Checklist

  • Ziel und Kontext geklärt
  • Input-Material gesammelt
  • Beteiligte und Rollen benannt
  • Durchführung nach Runsheet vorbereitet
  • Ergebnisartefakte erstellt
  • Acceptance Criteria aktualisiert
  • Story-Update aktualisiert
  • Offene Fragen dokumentiert
  • Nächster Schritt mit Owner und Datum gesetzt

Fertigstellungscheck

  • Acceptance Criteria 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
Vorlagenbasis

Acceptance Criteria Workshop Arbeitsvorlage

Vorlage ansehenKompakte Arbeitsvorlage für Acceptance Criteria Workshop mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
checklist

acceptance-criteria-workshop-working-template.md

Kompakte Arbeitsvorlage für Acceptance Criteria Workshop mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

Acceptance Criteria Workshop Checklist

  • Ziel und Kontext geklärt
  • Input-Material gesammelt
  • Beteiligte und Rollen benannt
  • Durchführung nach Runsheet vorbereitet
  • Ergebnisartefakte erstellt
  • Acceptance Criteria aktualisiert
  • Story-Update aktualisiert
  • Offene Fragen dokumentiert
  • Nächster Schritt mit Owner und Datum gesetzt
Direkt nutzbar, wenn
  • Arbeitsfrage, Owner und Zielartefakt sind sichtbar.
  • Das Ergebnis passt zu Acceptance Criteria.
  • Kriterien als Teil der Story versioniert. Bei Änderung nach Sprint-Start Begründung im Story-Kommentar. Kriterien-Templates pro Domäne im Wiki, alle 3-6 Monate prüfen.
  • Offene Fragen sind als Follow-up notiert.
  • Der nächste Review oder Entscheidungspunkt ist terminiert.
SteckbriefRunsheet