„Grandma, tell us about the good old days” – Who among us doesn’t still have that inner child eager to hear stories from someone who has lived through them? Someone we trust to have a deep understanding of what they’re talking about. An expert, who can speak freely from ample experience, and who is pleased rather than annoyed by numerous questions for details, happily repeating themselves when necessary. But what if grandma isn’t around? A person with domain expertise or a group of experts will do just as well.
The best part of the whole thing for people like me is that there are hardly any fixed rules or preparations.
What do you need for “Domain Storytelling”?
For Domain Storytelling you basically need:
- A sheet of paper and painting tools (or maybe a whiteboard, Miro, egon.io, or something similar)
- Curious architects or developers
- And at least one grandma. Or, as mentioned earlier, a domain expert as an alternative
Now, the first question arises: what is a domain? At this point, I will defer and hope that my colleagues will soon write a blog post on this topic. For Domain Storytelling, the domain is simply the subject or the area of work of the storytellers that you want to understand thoroughly.
What else do you need? Domain-Driven Design? That’s definitely not a prerequisite for this method. It can be used wonderfully to explore the domain and requirements independently of an application’s solution design.
A brief introduction to the notation should also not be overlooked.
So, grandma tells the story and the interested listeners “take visual notes” according to the scheme: Who (actor) does what (activity) with what (work object) – optionally also with whom (other actors), including comments. Actors can be individuals, groups, and software systems.
Before we really get started, there are a handful of points or questions that I like to keep in mind.
Front Sound System?
Absolutely not. For “storytelling,” active listening, visual representation, and rephrasing are all part of the story. After all, it’s not just about entertainment, but about “listening to understand.”
Flow
Even if the storyteller is fully immersed in their flow, the story only continues once everyone has nodded and understood what has been visualized. Open details that are not immediately relevant to the main thread of the story can temporarily remain unresolved. — What are sticky notes for? 😉
Fragen == evil?
Certainly not – asking questions is essential in storytelling! Questions reflect interest and a desire to delve deeper and should not be perceived as challenging the storyteller. The principle is to appreciate and comprehend; not to critique. Those without questions are either experts themselves or may simply think they are.
Beginning and End of the Story
Define the framework of the story in advance. In a completely new domain for some of the participants (though not for the storytellers), this can also happen during the storytelling, by consensus within the team.
Digressing
That’s perfectly acceptable and sometimes leads to surprising insights. It’s also not easy to maintain a consistent altitude and avoid getting too caught up in details.
During storytelling, it’s easy to become immersed in note-taking tools or notations. In those moments, it’s crucial to adopt pragmatic approaches and refocus on the domain’s essence. Both storytellers and listeners should feel comfortable gently pulling back when needed.
Unfortunately, that has happened to us before – but as they say, every mistake is a chance to learn, not a problem.
Tools of the Trade? Absolutely, and Practise makes Perfect
There are many resources describing how to visually and textually capture a domain story. Nevertheless, the key is to tailor your method. In our team, we’ve had various – sometimes opposing – experiences. Just like in any craft, the best tool is only good for the right purpose.
And how many craftspeople are ideal? In my view, anywhere from two to a maximum of six participants is acceptable but I lean towards fewer for greater efficiency.
Keyword tools: we favor using egon.io, particularly for replaying the story later. However, before using it, it’s crucial to ensure the toolkit is equipped with the appropriate icons. And one disadvantage annoys us as a team which, likes to model together, is the current lack of collaborative functionality.
Help, I’m Drawing a Spider Web!
If the story stretches out and involves numerous actions originating from or involving one actor, the narrative can resemble a spider web. Alternatively, we’ve experimented with resetting actions from left to right or top to bottom or even splitting them after a maximum of three actions.
In my experience, the right approach depends on what should be the focus and how many actors are involved. I prefer small, interconnected webs, ideally with a bit of domain separation already established.
Introducing a new actor or a media break often serves as a convenient separator.
Main Path and Side Tracks?
This is a pitfall I’ve stumbled into several times, even when I was aware of the theory and had discussed it with a colleague. One tends to tell and model (initially) one version of the story, much like grandma does. Typically, this is the “happy path,” unless one specifically aims to understand a different scenario.
That’s easier said than done, and sometimes it’s okay to cheat a bit – for example, by having a picture alongside. As a “techie,” one tends to think quite frequently in alternative sequences.
Once Upon a Time? Present or Future?
Pitfall number two – at least when you forget to clarify this question beforehand: are you telling and modeling the current state (IS status) or ideal processes for the future? A typical architect’s answer might be, “It depends” – but you should stick to one or the other in a story. However, I find it much more appropriate to model the current state (IS status) with this method. It’s not always suitable for designing a potential target solution, unless the storyteller has a clear vision. In that case, this method can also facilitate straightforward questioning of backgrounds and details.
When depicting the current state, it’s not always straightforward to capture the interaction involving or with software system actors at the appropriate level of detail. What is considered “appropriate” can range from “field X on form page Y” to “System X.”
Knowledge Transfer or Documentation?
Or is the truth somewhere in between? Ideally with the voice track of a participant. And not for a long time. Implementing a new story? Then, a corresponding domain story image can be attached.
Be an Expert
Every cook should taste their own dishes. So why not act as your own expert?
We tested this whole process as a team during the onboarding of a new team member and documented the results for future new colleagues. The domain? In this case, it was the general path from requirement through our Product Owner to the go-live of a new feature in our project.
During the storytelling session, we decided to wrap up the story after the first chapter and scheduled a second round. However, having seven experts and two newcomers for the second chapter proved to be less than ideal. Adding to the challenge, we had already spent two hours that morning discussing architecture. This made both the storytelling and listening sessions quite sluggish.
My conclusion: Domain Storytelling is another tool to let images and words speak. However, when operating at a relatively high level and fortunate to have multiple domain experts on board, I would lean towards Event Storming for the sake of collective intelligence. On the other hand, if I’m looking to delve into details from someone, I’m happy to focus on a part of the event chain and transition to Domain Storytelling, possibly in a smaller group.
During a team day, we invited our back office to act as the “grandma” to improve our internal tools. If interested, you can read more details about it here.
