What needs to be finished first
Business, testing and engineering collaborate in refinement or can be brought together for the workshop.
What needs to be ready before start
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).
One facilitator (tester or BA); Product Owner or domain expert; engineer with implementation knowledge; optional tester for edge-case search.
Story description with acceptance criteria; existing business rules (for example from docs, legal texts); domain glossary; list of known special cases.
60-90 min per feature
One section per story in the document. Table with columns rule, example input, expected output, note. Gherkin template as optional structure. Glossary visible.
The one question this method answers
Which concrete examples describe the business logic unambiguously enough to serve as executable tests?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 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"). | If rules are not stable, the story is not ready for Specification by Example. Negotiate rules with PO first, then examples. |
2Phase 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. | Choose meaningful values (for example EUR 99.99, EUR 100.00, EUR 100.01 instead of only 50, 100, 200). Meaningless values hide boundaries. |
3Phase 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. | Testers drive this phase. If no edge cases are found, the story was understood too superficially. Boundary search is the method's core. |
4Phase 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. | If examples are not automatable, the step was cut short. Gold standard: examples become executable acceptance tests. Manual tests are a valid fallback. |
What comes out at the end
Example table or Gherkin feature file in repo, linked to story in ticket system. Glossary in wiki. Automated tests in test directory referencing the examples.
Examples in code repo, same branch as implementation. Rule changes via pull request, examples versioned together. Glossary versioned in wiki.
Compact working template for Specification by Example with context, input, output artifacts, and next step.
Concrete examples serve as an executable specification.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Short notes along the runsheet.
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Story: As a tax advisor, I want to automatically receive a discount when my client count exceeds the tier.
Rules
Examples (Gherkin)
Feature: Client discount calculation
Scenario Outline: Discount by client count
Given tax advisor Sabine has <Clients> active clients
When the monthly price is calculated
Then the discount is <Discount>% and the final price is <FinalPrice> EUR
Examples:
| Clients | Discount | FinalPrice |
| 1 | 0 | 29.00 |
| 10 | 0 | 29.00 |
| 11 | 10 | 26.10 |
| 50 | 10 | 26.10 |
| 51 | 20 | 23.20 |
| 100 | 20 | 23.20 |
| 101 | 30 | 20.30 |
| 500 | 30 | 20.30 |
Edge Cases
Glossary updates: "Active client" = status "active" in table mandanten, not paused or deleted.
Recognize symptoms and steer against them
Only happy-path examples, tests are green, but production edge cases cause bugs.
Tester actively drives edge-case search. At least 30% edge cases per story. Use checklist of typical edge patterns (null, max, empty, invalid).
Examples use 1, 10, 100 without relation to business rules, boundaries are not checked.
Choose values around boundaries (99.99, 100.00, 100.01). For each rule boundary, at least 3 values: before, on, after boundary.
Examples describe UX behavior without clear input-output logic, tests remain manual.
Keep examples at logic level, not UI. If UI behavior is meant, define separate UI tests. Specification by Example is logic specification.
Only PO and engineer present, tester missing. Edge cases remain untreated, coverage weak.
Enforce Three Amigos principle. If tester is unavailable, postpone workshop or add asynchronous tester review. Do not finalize without tester.
Examples in wiki are maintained, test code in repo is not in sync, documentation drifts from reality.
Single source of truth: examples in code repo next to tests. Wiki examples only as generated output from test definitions.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.