In February 2024, Agile in the Ether had its first in-person event. I’ve written posts about the day’s first two workshops: building connections and beyond DORA.
For notes on the third workshop, we’re trying something different: a guest post from Ian Ames!
I’ve known Ian for years through the Agile in the Ether community – from discussions at the online meetups, in our hopefully-named #blog-club channel (often renamed #excuse-club as we talk more about reasons why we don’t have time to write), and he’s remotely visited my work to talk about how product prioritisation is triage. Since this event was about lots of the community getting together in person for the first time, we thought it’d be nice to share someone else’s perspective in this series of writeups.
Over to Ian for most of the rest of this post…
Domain storytelling
At Agile in the Ether – Liverpool last month Thorsten introduced us to domain stoytelling, a technique for defining how a service might work. He walked us through a simple scenario of booking a train ticket.
My impressions of the technique were that it could be useful and I wanted to learn more. User story mapping is my go to tool for describing how a service might work, but it doesn’t handle branching scenarios well. UML and sequence diagrams are great for getting into the detail between interactions, but their pretty impenetrable to non-techies. Domain storytelling felt like a useful tool to cross that divide from service design to architecture, as a common language that was easily understood by both parties.
How it works
- Define the user
- Define what they are trying to do (In the scenario we were given, buy a train ticket)
- From the users perspective define the things they interact with to acheive that goal (a ticketing website or station ticket seller) in domain storytelling both are called actors.
- Between these to actors (the user and the thing they are interacting with) write down all of the information that needs to be conveyed as a first step. Label this step 1.
- Do the same but for the response, number this step
- Continue until the goal is reached.
What did I think?
What I liked about the process is that it exposed a level of granularity thats required to build a thing that can sometimes be missing from tools such as story maps. Its easy to skip the detail required to make things work and becomes ‘the tech problem’ when often its a lack of clarity problem. Domain storytelling felt like it could be a useful common language to help cross the divide between user centred design and development to ensure we build the the thing right.
The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do.
– Ted Nelson
The numbering helped understand the order of the flow and felt like a big bonus that can be hard to derive from other methods like sequence diagrams, especially when looking back on them after their first creation.
Explicitly repeating actors at each step, and defining what information is passed between them may seem wasteful compared to a UML diagram, but in order to get to that optimised state its important to be explicit about each time that ‘actor’ is interacted with and what information is passed. I can see how a domain story map would be a good first activity between architects and business folks in order to aid understand to then go on and produce a UML or sequence diagram if needed. It felt like a good translation tool.
What have I learnt since?
As part of the wrapping up of agile in the ether – Liverpool, Neil asked us what we wanted to learn more about, I wrote down “learn more about domain storytelling”. I made a few mistakes on the day, confusing flow and the information within that flow, Sophie set me straight (thanks Sophie!) but I wanted to practice some more. I also wasn’t clear how to handle optional flows (for example adding a bike reservation to a train booking).
The good news is that optional flows can be mapped with dotted lines to represent they’re not always followed. These flows aren’t numbered which could be confusing. I think in this scenario I would draw the line to the option, then map that flow in a separate diagram.
On the day we did the mapping with post-it notes and a whiteboard paper, but there’s a pretty good tool for doing it online, egon.io using it I remapped the train journey scenario, as before I’m not convinced I’ve defined interactions and actors quite right, it’s definitely a process that would work best doing it together.
Next steps
I’ve bought the domain storytelling book to learn more, and I’m interested in trying it out with my team, expect a follow up post!
Back to Neil…
Huge thanks to Ian for sharing his thoughts as part of this blog series – I love how much he’s gone on to practice and learn about since the intro workshop we did on the day. To see that follow up post he mentioned, and posts on lots of other topics, visit his ames.world blog.
I’ve got one more workshop to write up – back soon to reflect on hacking bureaucracy.
Comments
One response to “Agile in the Ether, IRL: Domain storytelling”
Great examples here! Feels complementary to the ideas behind service design blueprinting where you separate out the front/backstage actions and actors that are involved in delivering a service to a user. And it’s telling how quickly you unearth a bunch of complexity behind the seemingly simple train journey that we often take for granted.