methodatlas
Session Builder

Meine Session planen

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

Methoden-Session60-90 min pro FeatureWorkshopBeispieltabelle

Session: Specification by Example

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 Beispieltabelle hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

  1. 1

    Phase 1: Story und Regeln klären

    10-15 min

    Story oder Feature vorstellen. Pro Story 1-5 Regeln benennen, die die Logik beschreiben (z. B. „Rabatt ab 100 EUR Warenwert“). Hinweis: Wenn Regeln nicht stabil sind, ist Story nicht reif für Specification by Example. Vorher mit PO Regeln aushandeln, dann Beispiele.

    FacilitatorBeispieltabelle
  2. 2

    Phase 2: Happy-Path-Beispiele

    15-20 min

    Pro Regel mindestens ein Happy-Path-Beispiel formulieren: konkrete Eingabewerte, erwartete Ausgabe. Beispiele in Tabelle oder Given-When-Then. Hinweis: Werte mit Bedeutung wählen (z. B. 99,99 EUR, 100,00 EUR, 100,01 EUR statt nur 50, 100, 200). Bedeutungslose Werte verschleiern Grenzen.

    FacilitatorAcceptance Tests
  3. 3

    Phase 3: Grenzfälle und Edge Cases

    15-25 min

    Aktiv Grenzfälle suchen: Nullwerte, Maximalwerte, leere Listen, ungültige Eingaben, parallele Bedingungen. Pro Edge Case eigenes Beispiel. Hinweis: Tester treiben diese Phase. Wer keine Edge Cases findet, hat Story zu oberflächlich verstanden. Grenzfall-Suche ist methodischer Kern.

    FacilitatorBeispieltabelle
  4. 4

    Phase 4: Beispiele als Acceptance Tests übergeben

    10-15 min

    Beispiele in Test-Framework-Format überführen (Gherkin, JSON, CSV). Engineering implementiert Tests vor Code. Tester reviewt Coverage. Hinweis: Wenn Beispiele nicht automatisierbar sind, ist Schritt eingespart. Goldstandard: Beispiele werden zu lauffähigen Akzeptanztests. Manuelle Tests sind valider Fallback.

    OwnerAcceptance Tests
  5. 5

    Artefakt veröffentlichen

    10 min

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

    OwnerBeispieltabelle
Nutzbares Artefakt

Session Brief

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

session-brief.md

Session Brief: Specification by Example

Ziel

Artefakt: Beispieltabelle

Arbeitsfrage

Welche konkreten Beispiele beschreiben die Geschäftslogik unmissverständlich, sodass sie als ausführbare Tests dienen können?

Kontext

Story-Beschreibung mit Akzeptanzkriterien; bestehende Geschäftsregeln (z. B. aus Doku, Rechtstexten); fachliches Glossar; Liste bekannter Sonderfälle.

Setup

  • Format: Methoden-Session
  • Dauer: 60-90 min pro Feature
  • Modus: Workshop
  • Teilnehmende: Ein Facilitator (Tester oder BA); Product Owner oder Domainexperte; Engineer mit Implementierungs-Wissen; optional ein Tester für Edge-Case-Suche.
  • Owner: Ein Facilitator (Tester 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 Beispieltabelle hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

Input

Geteiltes Dokument oder Confluence-Seite mit Tabellen-Struktur; Story oder Feature-Beschreibung; bekannte Regelwerke aus Domain; Beispiele aus früheren ausführbaren Spezifikationen; Test-Framework-Referenz (Gherkin, Cucumber, SpecFlow).

Vorbereitung

Pro Story eine Sektion im Dokument. Tabelle mit Spalten Regel, Beispiel-Eingabe, Erwartete Ausgabe, Anmerkung. Gherkin-Vorlage als Optionalstruktur. Glossar sichtbar.

Agenda

  1. Phase 1: Story und Regeln klären (10-15 min) Owner: Facilitator Aktion: Story oder Feature vorstellen. Pro Story 1-5 Regeln benennen, die die Logik beschreiben (z. B. „Rabatt ab 100 EUR Warenwert“). Hinweis: Wenn Regeln nicht stabil sind, ist Story nicht reif für Specification by Example. Vorher mit PO Regeln aushandeln, dann Beispiele. Output: Beispieltabelle

  2. Phase 2: Happy-Path-Beispiele (15-20 min) Owner: Facilitator Aktion: Pro Regel mindestens ein Happy-Path-Beispiel formulieren: konkrete Eingabewerte, erwartete Ausgabe. Beispiele in Tabelle oder Given-When-Then. Hinweis: Werte mit Bedeutung wählen (z. B. 99,99 EUR, 100,00 EUR, 100,01 EUR statt nur 50, 100, 200). Bedeutungslose Werte verschleiern Grenzen. Output: Acceptance Tests

  3. Phase 3: Grenzfälle und Edge Cases (15-25 min) Owner: Facilitator Aktion: Aktiv Grenzfälle suchen: Nullwerte, Maximalwerte, leere Listen, ungültige Eingaben, parallele Bedingungen. Pro Edge Case eigenes Beispiel. Hinweis: Tester treiben diese Phase. Wer keine Edge Cases findet, hat Story zu oberflächlich verstanden. Grenzfall-Suche ist methodischer Kern. Output: Beispieltabelle

  4. Phase 4: Beispiele als Acceptance Tests übergeben (10-15 min) Owner: Owner Aktion: Beispiele in Test-Framework-Format überführen (Gherkin, JSON, CSV). Engineering implementiert Tests vor Code. Tester reviewt Coverage. Hinweis: Wenn Beispiele nicht automatisierbar sind, ist Schritt eingespart. Goldstandard: Beispiele werden zu lauffähigen Akzeptanztests. Manuelle Tests sind valider Fallback. Output: Acceptance Tests

  5. 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: Beispieltabelle

Abschluss

  • Ergebnisartefakt aktualisieren: Beispieltabelle
  • 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

Beispieltabelle: Specification by Example

Arbeitsfrage

Welche konkreten Beispiele beschreiben die Geschäftslogik unmissverständlich, sodass sie als ausführbare Tests dienen können?

Kontext

Story-Beschreibung mit Akzeptanzkriterien; bestehende Geschäftsregeln (z. B. aus Doku, Rechtstexten); fachliches Glossar; Liste bekannter Sonderfälle.

Beteiligte

  • Owner: Ein Facilitator (Tester oder BA)
  • Teilnehmende: Ein Facilitator (Tester oder BA); Product Owner oder Domainexperte; Engineer mit Implementierungs-Wissen; optional ein Tester für Edge-Case-Suche.

Input

Geteiltes Dokument oder Confluence-Seite mit Tabellen-Struktur; Story oder Feature-Beschreibung; bekannte Regelwerke aus Domain; Beispiele aus früheren ausführbaren Spezifikationen; Test-Framework-Referenz (Gherkin, Cucumber, SpecFlow).

Vorlage

Specification by Example Arbeitsvorlage

Ziel

Konkrete Beispiele dienen als ausführbare Spezifikation.

Kontext

Wann und wofür nutzen wir diese Methode?

Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

Durchführung

Kurze Notizen entlang des Runsheets.

Ergebnisartefakte

  • Beispieltabelle:
  • Acceptance Tests:

Annahmen und offene Fragen

  • ...

Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

Fertigstellungscheck

  • Beispieltabelle 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

Specification by Example Arbeitsvorlage

Vorlage ansehenKompakte Arbeitsvorlage für Specification by Example mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
markdown

specification-by-example-working-template.md

Kompakte Arbeitsvorlage für Specification by Example mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

Specification by Example Arbeitsvorlage

Ziel

Konkrete Beispiele dienen als ausführbare Spezifikation.

Kontext

Wann und wofür nutzen wir diese Methode?

Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

Durchführung

Kurze Notizen entlang des Runsheets.

Ergebnisartefakte

  • Beispieltabelle:
  • Acceptance Tests:

Annahmen und offene Fragen

  • ...

Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

Direkt nutzbar, wenn
  • Arbeitsfrage, Owner und Zielartefakt sind sichtbar.
  • Das Ergebnis passt zu Beispieltabelle.
  • Beispiele im Code-Repo, gleicher Branch wie Implementierung. Regel-Änderungen mit Pull Request, Beispiele werden mitversioniert. Glossar im Wiki versioniert.
  • Offene Fragen sind als Follow-up notiert.
  • Der nächste Review oder Entscheidungspunkt ist terminiert.
SteckbriefRunsheet