What needs to be finished first
A concrete, representative business case is selected and aligned with the domain experts, and contains typical actors and handoffs.
The most important actors in the story are identified and the right people from the relevant areas are present in the room.
What needs to be ready before start
Whiteboard or digital board (Miro with Domain Storytelling template, egon.io); pictograms for actors (stick figures) and work objects (documents, databases, letters); numbered arrows (1-15) for activities; camera for snapshots.
One facilitator who draws the story and asks follow-up questions; one to two domain experts as storytellers; one to three developers or additional stakeholders as listeners and clarifiers; one scribe for glossary.
Selected story in one sentence; known actors; relevant documents or systems appearing in the story; open questions from previous sessions.
1-2 h
Use the board horizontally, with the first actor on the left. Explain notation (Actor, Work Object, numbered arrows, annotations). Rule: draw the story in one pass, then refine it. The storyteller speaks, the facilitator draws.
The one question this method answers
How does this business case really run today, who is involved when, with what, and where do friction and translation errors occur?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Confirm story selection | 5 min | Read the preselected story aloud. Clarify granularity (coarse-grained, fine-grained, as-is, to-be). Demonstrate notation on the first step as an example. | Avoid mixed variants. A story is either as-is or to-be, never both. Otherwise the diagram describes a non-existing state. |
2Phase 2: Draw story (first pass) | 30-45 min | Domain expert tells story linearly, facilitator draws in parallel. Per activity: Actor + numbered arrow + Work Object + recipient actor where applicable. No interruptions for detail debates in this pass. | Use annotations for branches ('sometimes', 'when X'). More than 15-20 arrows indicate too fine a granularity; split the story. |
3Phase 3: Refinement and follow-up questions | 20-30 min | Second pass with clarifying questions. Mark unclear handoffs, exceptions, and workarounds. Mark pain points in red annotations. Extract glossary terms. | Pain points are the most valuable result. If none emerge, the facilitator asks specifically about exceptions, manual rework, and escalations. |
4Phase 4: Extract language and rules | 15-20 min | Collect ubiquitous language terms (actor names, work object names, domain verbs). Capture implicit rules from the story as short sentences (for example, 'An order is canceled if payment does not arrive within 7 days'). | If the same word has different meanings in different activities, capture this explicitly. It is usually a context shift signal. |
5Phase 5: Snapshot and follow-up | 10 min | Photo or export the diagram. Prioritize pain points and assign owners. Plan follow-up stories (neighbor processes, to-be version, exceptions). | A story is not enough by itself. Plan at least three stories per domain; otherwise the picture covers only one slice and conclusions are biased. |
What comes out at the end
Domain story diagram (image or egon.io file) with numbered activities, glossary appendix with domain terms, and pain point list with owners and follow-up questions. Stored in the domain wiki or architecture repository.
One file per story with date, storyteller, and story title. New version for follow-up workshops; keep older versions (they show change over time). Consolidate glossary across stories in a separate file.
Compact working template for Domain Storytelling with context, input, output artifacts, and next step.
A visual method for modeling business processes as concrete stories.
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
Storyteller: @sabine (Customer Service Lead)
Story (12 activities):
Pain Points:
Glossary excerpt: refund, replacement shipment, return label, incoming goods, damage description, dispute.
Recognize symptoms and steer against them
Storyteller starts with 'Normally the customer would ...' instead of 'Mrs. Meyer did this on Monday ...'.
Facilitator interrupts and requires a concrete case with real names or at least a real date. Generic stories are idealized and do not occur in reality.
During the story, the storyteller switches between 'this is how it is' and 'this should be'.
Keep as-is and to-be strictly separate. Draw current story first; use to-be as a separate story in the same or a follow-up workshop.
30+ activities in one story, each click is drawn.
Raise granularity: capture only handoffs between actors and essential value-creation steps. Clicks belong in UX documentation, not Domain Story.
Story runs smoothly with no friction and no exceptions.
Facilitator asks specifically: what is going wrong? When is escalation needed? What workarounds exist? A friction-free story is unrealistic.
Story is told by someone who does not perform the process (for example a manager instead of an operator).
Pause the workshop and bring in the right person. Hearsay produces polished or invented stories. If not available, defer.
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.