Collaborative Modeling: Domain Storytelling as a Catalyst for Product Backlogs

14 min readAug 3, 2020

User stories with less effort: Guiding stakeholders and creating a product backlog for future software development with Domain Storytelling.

Almost every new project starts with unique challenges caused by people meeting for the first time in this constellation, for example, stakeholders discussing with technicians, software developers and supporting departments like compliance, workers council or revision department. This article demonstrates a pragmatic approach on how to guide the involved groups through this challenging situation and on how to establish a specific product backlog as a foundation for the future implementation of the project. The approach is based on Domain Storytelling, which allows to develop new scenario diagrams pretty easily. Finally, the user stories can be derived from the diagrams directly with less effort to the initial product backlog.

1. The neglected question: “What are the requirements of the new project?”

Typically, the boundaries for the scope of future projects are based on the particular product vision and goals of the product owner. The requirements are derived from goals and are deconstructed until they appear implementable. They can then be documented in the product backlog. However, one important question is if these requirements are actually valuable for the product.
This process is problematic and difficult, due to the involvement of multiple stakeholders and experts, each with diverging technical and domain knowledge. The visual orientated interview and modelling technique, Domain Storytelling, is a practical approach to unite subject matter experts, e.g. product owners, product managers, business analysts, with software developers based on the context language. Domain Storytelling promotes interaction and direct feedback during the modulation process and is the central idea of Collaborative Modelling [CoMo].

Domain Storytelling

The method is a visual storytelling technique, highlighting how people (and software systems) work together. Essentially three types of symbols are used, which are represented as icons and arrows:

Actors are people and IT systems acting as part of a story. Typically indicated with a role name (e.g. airside bus dispatcher). Actors use work objects to conduct activities. Often things you can touch and see, like the “bus”. Sometimes also an objectified concept, such as an “assignment”.

Activities describe what the actors do and are expressed by arrows. The consecutive numbering of the arrows indicates the sequence of the activities. The activities are the verbs in our stories “e.g. reports…”

Icons and arrows are explained by short texts in such a way that a “visually derived” sentence is created. For the label, we use terms from the domain language. The result is documented as a diagram using simple pictograms.

2. Initial Situation

Our scenario is based on the airport domain and is about people who want to start their holiday trip with a flight. We chose this scenario because almost everyone has experienced this process and has waited as a passenger for an airside bus, which transports guests from a terminal building to the airplane on the apron.

Key aspects of this situation are:

The guests of an airline — the passengers — should be picked up at the gate by an airside bus from a specific provider (for example ground handling) and brought on schedule to the outgoing plane on the apron.
The staff at the gate order a bus by phone or their IT solution.
The provider’s airside bus dispatcher allocates an assignment to an available bus driver, to pick up the passengers on time, and drive them safely to the plane where they board via the stairs.
In case of any problems during this process, the airside bus driver will contact the dispatcher, so they can take actions to solve this problem.

While the dispatchers of the buses can rely on a straightforward IT solution, the bus drivers still depend on radio equipment and pen and paper for work documentation.

2.1 The domain: Airport

We will choose an airside bus app as a specific example for the usage of Domain Storytelling. We are going to show how user stories or epics can be derived and added to the product backlog, by using cooperation diagram requirements.

In the next step we will use Domain Storytelling to sort our product backlog. We will use a well-defined minimum viable product to sort the backlog to achieve an initial and useful prioritization for the implementation.
In this lightweight process, beside the sorted product backlog filled with user stories, multiple self-explaining professional diagrams will emerge. These illustrations can be used to promote communication especially with the goal of clarifying the project as well as steps in the near future. The purpose of the exchange is not only clarification between the project team and stakeholders (like workers council or data protection supervisors). So, it promotes the clarification between stakeholders.

2.2 The scenario as a cooperation diagram

We modelled a cooperation diagram for the given scenario and its actual situation as followed:

The consecutively numbered arrows define a typical order of activities. This existing situation is the focal point of the interaction between the drivers and dispatchers of the airside buses. On inspecting the second arrow “record a request for an airside bus”, we are able to recognize a typical structure starting with actor = “dispatcher (of an airside bus)”, subject = “request for an airside bus”, and activity “register”.

2.3 Domain Storytelling “registration of a request for an airside bus”

We will focus on following one single step to demonstrate our promoted approach.

User story: As an airside bus dispatcher, I register an airside bus request using the airside bus dispatcher software, so that the software can automatically create and dispatch an assignment for an airside bus and the assignment can be recaptured later.

We explain with this example how epics and specific user stories can be derived from the Domain Storytelling cooperation diagram. During modeling, the specific domain language should be kept in mind.

Domain language

A request for an airside bus in our case contains the following information:

Outbound Flight Number
Registration (“license plate” of the plane)
Aircraft type
Position (gate at the terminal); Target position (plane position on the apron)
Off block time (the estimated time at which the aircraft will commence movement associated with departure)
Number of PAX (passengers)
Destination (verification of the flight’s destination for PAX).

This information can be found in the acceptance criteria of the user story “register an airside bus request”.

2.4 Obstacles in today’s process

In the next step, we show approaches for potential for improvement to develop a better target state but starting from the current situation. Interviews and workshops with the people involved in this process reveal various obstacles in day-to-day work:

Various misunderstandings caused by the challenges of radio traffic (like lost information about position changes of planes, mandatory passport control or just the break time of the drivers)
Complicated handling of problematic situations due to limits of analog radio
Use of multiple documents on the bus, which must be filled out manually
Re-recording in the control center of poorly readable notes into the IT system
Conflicts (e.g. with quality assurance or gate personnel) caused by limited information based on incomplete or not yet available data

As we take another look at the current process, some problems immediately become visible.

A. The airside bus driver works as radio operator and typist

B. The dispatcher reading / interpreting sometimes poorly handwritten notes and registering them into the system

C. The dispatcher as a decision maker, with lack of information about the current situation, like availability of airside bus drivers.

3. The design of the new target process

Usually, the identified challenges and the overview of the current process are sufficient to develop ideas for improvement of the overall situation. However, in order not to go beyond the scope of this article by complexity, we focus on the challenges A and B. We will also set some important details aside, such as the formulation of key performance indicators of project goals or acceptance criteria of user stories.

Based on the vision and the project goals, we are going to design the target process as a domain storytelling cooperation diagram.

3.1 Vision

The vision of a client or product owner could be:

The airside bus driver can fulfill his assignment paperless, binding and without any radio transmissions

The standard process is digitalized and automated, challenges can be faced individually by the airside bus dispatcher

3.2 (Measurable) goals

Possible sub-objectives and delimitations of the new project may include:

The newly created app (mobile app) stringently leads the airside bus driver through the process starting with the confirmation of the assignment until completion combined with the transmission of the generated data
The dispatcher receives information through the system about the status of the assignment
All data generated is digital, neither pen nor paper are needed anymore

Delimitations from the goals

The dispatcher’s workplace (desktop / server side) is not the center of this project
Billing preparation is also not a focal point of this project

3.3 The new target process

The paperless office — an old dream of IT — along with automated workflow documentation seems to be feasible today. The bus driver’s workplace is becoming paperless by using a tablet with an airside bus mobile application. To increase the readability of critical information for the bus driver and thus also the acceptance of the new solution, a bigger tablet screen will be used instead of a smaller smartphone display.

The dispatcher is also able to see the current bus assignment as an extension for the existing dispatching application. Radio communication can thus be reduced significantly.

With the focus on the bus driver activities (construction site A) and an aspect of the work of the dispatcher (construction site B), two important actors in the process are made happier with better IT support.

This also increases the commitment of those directly involved in the change process.

3.4 The Domain Story Modeler

To make the collaborative modeling process as simple as possible, the diagrams combined with the scenarios should be told as a story in different stages to all participants. This keeps the focus only on the current actor and on the activities currently under consideration.

The supporting tool is the Domain Story Modeler [MOD].

The diagrams can be displayed in the modeler step by step. Individual activities can be explained, and questions can be discussed and answered in a purposeful manner.

3.5 Creating epics and user stories

If we look at the cooperation diagram of the target process step by step by the consecutive order of activities, many requirements for the new project immediately come into focus:

In terms of the role of the airside bus driver, these are activities 04, 07, 08, 10 and 11. They can now systematically be used as a base for user stories and incorporated into the initial product backlog.

For the role of the airside bus dispatcher, activity 13 is added.

In addition, the interfaces (06, 12) for data exchange between the dispatching software and the new airside bus driver mobile app must be implemented.

3.6 The product backlog

Writing down the initial product backlog is now more of a diligence work than rocket science.

For a better overview, only activities in the sample scenario for which IT support is planned are included in the backlog.

If an activity in the diagram is only roughly modeled (e.g. epics), we can easily select it in the cooperation diagram and create a separate scenario of its own to derive more concrete user stories.

3.7 Enabling user feedback, refining the product backlog and creating a more light-weight MVP.

Now that we have created a basic product backlog, domain storytelling is a good way to clarify the possible implementation sequence while refining the product backlog even before development has started. We initiate a feedback dialogue with the airside bus drivers as early as possible. Therefore, we focus on the visualization of the airside bus assignment on the tablet via mockups. In this process, we get initial valuable user feedback.

Based on these responses we could create a first prototype also for testing the size and usage of the device itself. Equipped with information regarding the users’ preferred tablet specs, the project team experimented with different mounting solutions as well as tablets.

Furthermore, the user stories of the MVP in the backlog allowed us to discuss the forecasted effort of the implementation with the development team. This additional information helped the PO to re-negotiate certain user stories and even more reduce their scope. This allowed us to create a more light-weight MVP, shipping running software even faster and thus gain quicker first valuable insights.

E.g. user authentication was initially planned via Microsoft Active Directory which could be quickly identified as being too complex. As a light-weight alternative the development team proposed a simple authentication solution using just the vehicle ID.

For better understanding, the activities in the scenario are numbered consecutively in an order of a typical sequence. Compared to the initial product backlog, individual activities (documented as user stories) have been reduced in scope with regard to the MVP. For example, we have significantly reduced scope of the login story and implemented the functionality without the Active Directory integration but only vehicle ID of the airside bus.

3.8 A Mockup for the airside bus driver — the airside bus assignment

As mentioned before, we developed a mockup to display the airside bus assignment on A4 paper for the activity 03. Based on the mockup, we clarify further details on acceptance criteria for all user stories. Here are some examples for mockups:

Discussing mock-ups and their underlying user benefits with the airside bus drivers already let us to one key finding: Displaying only the assignment information, without any option to step forward in the target process, already was creating a huge benefit for the drivers. One of the main causes for problems, the necessity for analog radio communication, was dramatically reduced. With this learning we were able to further adjust the MVP.

Discussing requirements with stakeholders normally leads to further expansion of the backlog and usually the MVP. In our case we were able to further reduce requirements for the MVP.
The product backlog for MVP focuses then only on the following stories:

3.9 Minimum viable product “airside bus app 2.0”

The in scope dramatically minimized MVP, with the clear focus on receiving feedback from working software, reduced the risk to disappoint the airside bus drivers and dispatchers. Neither the drivers nor the dispatchers had been in touch with agile product development, especially not with MVPs nor their limited scope before. A reduced choice of requirements can easily result in mistrust caused by not yet delivered features.

Actually, the term MVP is used and interpreted in different ways by different groups. The previous mentioned reduced MVP is honestly a really “dogmatic” one. The focus lays only on performing experiments (and of course getting feedback) as early as possible with real users of the planned solution. It is up to the product owner to release the software based on this hand on approach to production or only conduct tests with well selected users. In this case the term MVP would be understood in a slightly different way with the focus not to lose the users’ trust in the software.

How to exactly define the MVP is a complex task for the product owner, especially by dealing with diverse peer groups. This is an optimization problem with no best but with some feasible solutions.

In our case a hybrid, iterative approach was chosen. The scope of the “dogmatic” MVP was implemented first. Then the solution was tested only with selected users coached in this approach. The resulting feedback and still remaining requirements were used for an “enhanced” MVP. The additional focus was to gain the trust of the dispatchers and airside bus drivers by providing almost all identified critical functionalities of the target process.

While implementing the “dogmatic” MVP, the remaining user stories were refined by the development team, the product owner and subject matter experts. Based on the already existing and discussed activity diagram, acceptance criteria were identified and defined directly as a joint activity. Still features like vehicle control checks, requesting breaks or cancellation of assignments are out of scope.

3.10 The airside bus mobile app in action

If you would like to experience the implemented solution in real-life, you should buy a cheap enough ticket (otherwise your flight might make use of a jet bridge instead of airside buses) for your next flight from or to a bigger northern German airport and take look over the shoulder of the airside bus driver.

Then one of the following drafts might seem somewhat familiar.

4. The whole procedure as a recipe

We can summarize the most important steps from the project idea to the initial product backlog as a “cooking recipe”:

Analyzing the business domain with the help of domain storytelling in the current process and identifying current obstacles
Defining a concrete vision and deriving related goals
Developing a target (“to be”) process with domain storytelling
Deriving Epics and user stories from the target activity diagram
Developing a MVP from the target activity diagram
Establishing an initial product backlog and sort items based on business value

5. Conclusion

The previously described procedure is suitable for almost all kind of projects. Domain Storytelling diagrams speed up the required familiarization process to clarify most of the basic aspects and challenges of a new project. It also helps to create a common understanding between the various stakeholders. In the scenarios key stakeholders can immediately recognize their involvement which helps to establish the necessary commitment. The feedback from these key stakeholders will be incorporated into the scenario diagrams as a joint activity.

As well in already ongoing larger projects, which are being implemented by means of the very successful methodology Domain-Driven Design [DDD], the process pattern can be applied as well. Discussions about a minimum viable product are supported, concrete specifications for new functionality can be documented with minimal effort.

In the project there are often specialist departments that are integrated only by mainly technical interfaces (e.g. billing). Alternatively, they play a role as control bodies such as auditing, data protection or the works council. They can be integrated in a lean and transparent way by using and discussing the diagrams as well.

If any other project documentation is required, such as information for the works council or maybe a procedure description for data protection, the diagrams are often used as a basis for further detailed descriptions in case they are even still required.