methodatlas
Session Builder

Plan my session

Plan a concrete work block with agenda, roles, preparation, and a copyable result artifact.

Method session60-90 min per featureWorkshopBeispieltabelle

Session: Specification by Example

The plan translates the method into a concrete facilitated work block. Your inputs flow directly into the session brief and work artifact.

Derived automatically

Method session with 3-6. The plan uses the existing method logic and the runsheet.

Runsheet
Participation logic
Team round, shared work and alignment

Use the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.

Outcome logic
Finish artifact

The session works directly toward Beispieltabelle. After the session, the artifact should be shareable, reviewable, or reusable.

  1. 1

    Phase 1: Clarify story and rules

    10-15 min

    Present story or feature. Name 1-5 rules per story that describe the logic (for example "discount from EUR 100 order value"). Hint: If rules are not stable, the story is not ready for Specification by Example. Negotiate rules with PO first, then examples.

    FacilitatorBeispieltabelle
  2. 2

    Phase 2: Happy-path examples

    15-20 min

    Formulate at least one happy-path example per rule: concrete input values, expected output. Examples in table or Given-When-Then. Hint: Choose meaningful values (for example EUR 99.99, EUR 100.00, EUR 100.01 instead of only 50, 100, 200). Meaningless values hide boundaries.

    FacilitatorAcceptance Tests
  3. 3

    Phase 3: Boundaries and edge cases

    15-25 min

    Actively search boundaries: null values, maximum values, empty lists, invalid inputs, parallel conditions. One example per edge case. Hint: Testers drive this phase. If no edge cases are found, the story was understood too superficially. Boundary search is the method's core.

    FacilitatorBeispieltabelle
  4. 4

    Phase 4: Hand examples over as acceptance tests

    10-15 min

    Convert examples into test-framework format (Gherkin, JSON, CSV). Engineering implements tests before code. Tester reviews coverage. Hint: If examples are not automatable, the step was cut short. Gold standard: examples become executable acceptance tests. Manual tests are a valid fallback.

    OwnerAcceptance Tests
  5. 5

    Publish artifact

    10 min

    Check the artifact for completeness, define location, set version or status, and name review recipients.

    OwnerBeispieltabelle
Usable artifact

Session Brief

For invitations, boards, tickets, PR descriptions, or workshop notes.

session-brief.md

Session Brief: Specification by Example

Goal

Artifact: Beispieltabelle

Working Question

Which concrete examples describe the business logic unambiguously enough to serve as executable tests?

Context

Story description with acceptance criteria; existing business rules (for example from docs, legal texts); domain glossary; list of known special cases.

Setup

  • Format: Method session
  • Duration: 60-90 min per feature
  • Mode: Workshop
  • Participants: One facilitator (tester or BA); Product Owner or domain expert; engineer with implementation knowledge; optional tester for edge-case search.
  • Owner: One facilitator (tester or BA)
  • Participation mode: Team round, shared work and alignment
  • Outcome logic: Finish artifact

Participation Logic

Use the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.

Outcome Logic

The session works directly toward Beispieltabelle. After the session, the artifact should be shareable, reviewable, or reusable.

Input

Shared document or Confluence page with table structure; story or feature description; known rule sets from domain; examples from previous executable specifications; test framework reference (Gherkin, Cucumber, SpecFlow).

Preparation

One section per story in the document. Table with columns rule, example input, expected output, note. Gherkin template as optional structure. Glossary visible.

Agenda

  1. Phase 1: Clarify story and rules (10-15 min) Owner: Facilitator Action: Present story or feature. Name 1-5 rules per story that describe the logic (for example "discount from EUR 100 order value"). Hint: If rules are not stable, the story is not ready for Specification by Example. Negotiate rules with PO first, then examples. Output: Beispieltabelle

  2. Phase 2: Happy-path examples (15-20 min) Owner: Facilitator Action: Formulate at least one happy-path example per rule: concrete input values, expected output. Examples in table or Given-When-Then. Hint: Choose meaningful values (for example EUR 99.99, EUR 100.00, EUR 100.01 instead of only 50, 100, 200). Meaningless values hide boundaries. Output: Acceptance Tests

  3. Phase 3: Boundaries and edge cases (15-25 min) Owner: Facilitator Action: Actively search boundaries: null values, maximum values, empty lists, invalid inputs, parallel conditions. One example per edge case. Hint: Testers drive this phase. If no edge cases are found, the story was understood too superficially. Boundary search is the method's core. Output: Beispieltabelle

  4. Phase 4: Hand examples over as acceptance tests (10-15 min) Owner: Owner Action: Convert examples into test-framework format (Gherkin, JSON, CSV). Engineering implements tests before code. Tester reviews coverage. Hint: If examples are not automatable, the step was cut short. Gold standard: examples become executable acceptance tests. Manual tests are a valid fallback. Output: Acceptance Tests

  5. Publish artifact (10 min) Owner: Owner Action: Check the artifact for completeness, define location, set version or status, and name review recipients. Output: Beispieltabelle

Closeout

  • Update result artifact: Beispieltabelle
  • Define location, version, and review recipients.
  • Define owner, next step, and review date.
Usable artifact

Work artifact

Pre-filled starting point based on the matching template.

work-artifact.md

Beispieltabelle: Specification by Example

Working Question

Which concrete examples describe the business logic unambiguously enough to serve as executable tests?

Context

Story description with acceptance criteria; existing business rules (for example from docs, legal texts); domain glossary; list of known special cases.

Participants

  • Owner: One facilitator (tester or BA)
  • Participants: One facilitator (tester or BA); Product Owner or domain expert; engineer with implementation knowledge; optional tester for edge-case search.

Input

Shared document or Confluence page with table structure; story or feature description; known rule sets from domain; examples from previous executable specifications; test framework reference (Gherkin, Cucumber, SpecFlow).

Template

Specification by Example Working Template

Goal

Concrete examples serve as an executable specification.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Execution

Short notes along the runsheet.

Output artifacts

  • Example table:
  • Acceptance Tests:

Assumptions and open questions

  • ...

Decision / next step

Owner, date, and success signal.

Completion Check

  • Beispieltabelle is complete enough for review:
  • Location:
  • Version / status:
  • Review by:
  • Next step:

Next Step

  • Review result
  • Mark open questions
  • Schedule review or decision
Template base

Specification by Example Working Template

View templateCompact working template for Specification by Example with context, input, output artifacts, and next step.
markdown

specification-by-example-working-template.md

Compact working template for Specification by Example with context, input, output artifacts, and next step.

Specification by Example Working Template

Goal

Concrete examples serve as an executable specification.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Execution

Short notes along the runsheet.

Output artifacts

  • Example table:
  • Acceptance Tests:

Assumptions and open questions

  • ...

Decision / next step

Owner, date, and success signal.

Ready to use when
  • Working question, owner, and target artifact are visible.
  • The result fits Beispieltabelle.
  • Examples in code repo, same branch as implementation. Rule changes via pull request, examples versioned together. Glossary versioned in wiki.
  • Open questions are noted as follow-ups.
  • The next review or decision point is scheduled.
ProfileRunsheet