Scenario casting helps all project participants cast their concerns, questions, and ideas into an orientation scenario, gradually disentangling the processes of the domain and supporting them with tailor-made software.

Case Study: The up-and-coming company UrbanBioKontor delivers boxes of organic produce to end consumers in large cities. To make the offer even more attractive, products will come from small regional producers, from private chicken farmers to urban gardeners. The products from these very small producers are of exceptional quality and are particularly popular with customers.The company is also discussing using its own organic label instead of using an existing official organic label.

Paulina's task

Over the years, the company's complex software landscape has become outdated and unsuitable for its needs. The monolithic core system has since eroded into a Big Ball of Mud (BBoM) over time, a highly interconnected, difficult to comprehend and modify system, known as the antithesis of Domain-Driven Design. This BBoM is surrounded by small satellite systems.

This project uses standard software for payment, accounting, and dunning. Unfortunately, the software landscape's poor customizability prevents the company from achieving its strategic goal of including small producers in the boxes.

Based on this information, management made the decision to modernize the existing software landscape comprehensively. The goal is to build a modern cloud-based solution made up of loosely coupled, independent systems according to Domain-Driven Design (DDD) principles. Ideally, the company should continue to use existing software parts and purchase software instead of developing it in-house. The modernization project will be implemented gradually over the next two years without interrupting day-to-day operations.

While there are numerous subject matter experts in various departments and branches of the company, few actually have IT project experience. And the IT teams are currently only working on the existing software landscape, for example. To ensure the success of the modernization project, developers should be involved from the start to help establish project teams.

The entire company, especially the project manager Paulina, are facing an enormous task and many questions are left unanswered. Where do we start? How do we get staff in many different departments to come together? How do we prevent failures? How can we achieve relevant results quickly? Paulina wants to start with a scenario casting – and we will join her.

Paulina has had good experiences using scenario casting in previous projects and she knows it can provide concrete answers to the questions above. It also creates a common understanding for people who don’t normally work together - but who suddenly have a lot to do in the new project.

What is a scenario?

A scenario is an exemplary technical situation that can gradually change through technical events, such as intentional actions by actors. scenarios represent a multitude of similar processes and provide a rich basis for understanding problems, designing a solution, and subsequently accepting the solution.

A scenario is always:

• Realistic– It could happen exactly as described, possibly in the future.
• Coherent & Conclusive– Without gaps or jumps in logic.
• Concrete & Detailed– The more concrete and clear, the more valuable for understanding the problem (other details = a different scenario).

Actors can be represented well in situations by using personas. A well-crafted scenario always provides a concrete, clear context in which a problem can be understood–even by a lay person.

The scenario-based approach uses scenarios to identify requirements, make design decisions and develop test scenarios. The basic idea is that scenarios say more than just abstract or technical documents. Modern scenario-based methods promote interaction and constructive discourse among project participants, helping them to achieve a common understanding of the problems to be solved by software.

Scenario-based design allows for a solution on a small scale within a scenario. This approach facilitates the creation of practical and relevant solutions for processes that align with the scenario. By analyzing additional scenarios, the solution can be further generalized and expanded. This process is valid as long as the problems identified in the scenarios are genuine.

By adopting a scenario-based approach, we maintain a firm foundation within the problem space, even when the scope of the problem remains unclear. This enables us to employ incremental expansion stages that are both targeted and efficient, limiting the analysis effort to specific scenarios. Conversely, ideas for solutions that venture into uncharted territories of the problem space often run the risk of missing their intended purpose.

The first iteration - Paulina's project kick-off

Paulina wants to use the project kick-off meeting to not only present the project goals and bring the project participants together, but also to start working directly on the project. She’s invited staff to the company's headquarters so that those involved in the project can get to know each other in person. Later, the workshops will be held online as the company is spread out geographically and many developers work from home.

Several technical experts and IT staff alike suggested to Paulina that they should present their ideas and requests for the new software at the kick-off meeting. It’s a daunting task to coordinate, but Paulina is confident that the team’s many years of experience are enough preparation.

Nearly all project participants are present for the kick-off with the exception of two experts from purchasing. Management is there to start the meeting with an overview of the project goals and schedule.

Paulina takes charge of the meeting to explain the project’s general procedures. She stresses to participants that the project will be implemented in iterative stages, launching each stage as soon as possible. "Each expansion stage should deliver added technical value," she emphasizes, "This allows us to see whether we are gradually moving in the right direction in the project. So it's important that we focus and identify a technical added value for the next expansion stage. To accomplish this, we need to develop a strategy for how we can gradually modernize our existing software landscape."

Scenario casting - agility begins in the problem space

DDD distinguishes between the problem space, which encompasses the domain and its challenges, and the solution space, which includes all aspects of the solution, including UX, architecture, implementation, and non-software aspects to the solution (e.g., shipping).

Good design in the solution space begins in the problem space. Design thinking distinguishes between two phases of orientation: collecting ideas (diverging) and focusing on specific ideas (converging). When translated to the problem and solution spaces, this results in an image known as "Double Diamond", which asks what’s the right problem and what’s the right solution? (Fig. 1).

Fig. 1: The Double Diamond design model

In DDD, understanding the problem space is essential for designing the solution space. We create a model of the problem space and translate it into a technical model, such as mapping subdomains to systems or modules and domain language to code. There are many different interpretations of how to implement DDD technically, which are not covered here.

With the help of scenario casting (box: "Scenario casting method profile"), we explore the problem space step-by-step or orientation scenario-by-scenario - and build a solution iteratively in parallel, ensuring that it supports the orientation scenarios.

Scenario casting method profile

Scenario casting is:

• A scenario-based, iterative-incremental approach.
• A lightweight, communicative, visual, and very intensive workshop format.
• Committed to the domain and the project participants.

What are the most important goals?

• Ensure a thorough understanding of the domain across the entire project lifecycle.
• A transparent approach using shared strategic decisions.
• Maintain a consistent technical focus for all participants to ensure alignment at the project’s start.
• An iterative-incremental project lifecycle with technically meaningful expansion stages.
• Scenario casting uses concepts of Domain-Driven Design and is suitable for a low-threshold introduction to this software development concept.

What does the name mean?

Scenario casting = (1) Selecting scenarios in the sense of a casting show; (2) Casting small examples "into a mold" and merging them into larger orientation scenarios

How does the method work?

Scenario casting is regularly carried out to plan the next technically meaningful expansion stage. In the scenario casting workshop, questions, ideas and concerns of the project participants are (1) collected in a brainstorming session, presented from a technical point of view and clustered in terms of content in a scenario backlog, (2) prioritized and (3) combined to form clear orientation scenarios. Continuously maintained scenario backlogs and iteratively created orientation scenarios precisely define the technicality to be supported and serve as representative illustrative objects for the next expansion stage.

Who are the participants?

Project participants represent a selection of domain experts and at least at the beginning is a large group. All participants work actively, partly in parallel, online or on-site; workshops are moderated.

What methodological knowledge do the participants need?

The participants don’t need any prior methodological knowledge to be able to actively participate, a short introduction before each scenario casting step is sufficient. Although, prior knowledge of agile methods and DDD is helpful for better comprehension from the start. The moderator should be familiar with scenario casting and have a keen interest in the project and domain. They don’t need to have any technical expertise or hold a role in the project, so they can be solely responsible for moderation.

What materials are needed?

On-site: Sticky notes (yellow, green, red, light blue) (Fig. 7), and plenty of wall space. Online: A virtual whiteboard that supports collaborative work in real time.

How much time does it take?

For the first scenario casting, 1 to 3 workshops of 2-4 hours each are required. For later scenario castings, a single workshop of around 2 hours is usually sufficient. The scenario casting is followed by collaborative modeling workshops, e.g. domain storytelling, or event storming, to narrate and detail the orientation scenarios.

How was the method developed?

Scenario casting was developed collaboratively with dozens of teams in e-commerce, logistics, and statutory accident insurance pilot and transformation projects starting in 2018. These projects were significantly larger than the simple case example described here. Website: https://scenario-casting.org

The main goal is to build the architectural structures on a large and small scale based on representative details, which will be refined as the domain is better understood. In our example, if Paulina's team successfully supports vegetable crate delivery with software, then the delivery of fruit and vegetarian crates is almost a no-brainer and it builds a solid foundation for chilled product delivery.

The orientation scenario is the key as it sets the focus for developing the next expansion stage, which is implemented independently in several sprints by agile teams. It also ensures all teams are aligned on the content.

Based on the project idea, scenario casting begins by diverging: the participants brainstorm technical examples for all important aspects in the project to create a comprehensive scenario backlog. Scenario casting gradually converges by clustering, prioritizing and combining the examples until one or more orientation scenarios are created at the end (Fig. 2).

Fig. 2: A scenario casting cycle of two diamonds

Orientation scenarios are central to scenario casting, playing a vital role in solution development and acceptance testing. Serving as a starting point and end point for solution development, they ensure that team increments fit together and meet user needs. Acting as comprehensive acceptance tests, they ensure new features and functionality meet business requirements. From a technical perspective, the team’s products can then be released if possible and desirable.

This marks the start of the next iterative-incremental cycle and we start the development of the next expansion stage again with scenario casting.

Agile approaches in large projects

Some approaches attempt to scale agile procedures by carrying out typical agile team tasks across teams. This threatens to make originally lightweight practices, such as the distribution of tasks, very cumbersome, and the approach no longer feels agile.

The scenario-based approach, on the other hand, offers the opportunity to untangle interconnected business processes and look at individual scenarios (which represent a whole range of similar processes). scenario casting makes use of this opportunity and guides the teams incrementally through the problem space with the help of orientation scenarios. In doing so, the following applies:

• No solutions ideas or features are imposed by scenarios; instead teams work independently to find solutions.
• Work isn’t coordinated across teams, but rather, teams coordinate with each other as needed based on orientation scenarios.
• Teams are not required to provide estimates, instead they can plan work at their own discretion.

By dividing the domain into independent subdomains according to DDD and using this as the basis for the team split, we can minimize dependencies between teams and their products. When combined with scenario casting, this allows teams to focus on an orientation scenario within their subdomain and proceed with classic agile practices in a small, safe framework. However, the shared orientation scenario ensures that teams are still aligned on a larger scale.

Step 1: Paulina gets the team to brainstorm

Paulina now explains the procedure: "I know you all have different questions, ideas, and concerns about this project. We want to collect these points today. Ask yourself the following question: 'In which professional situation does my point come into play?' Think of a specific example and write it down on a yellow sticky note. Each example is a reminder for us so that we don't forget your point in the project."

Paulina demonstrates: "When a new order comes in, I currently have to enter the data in four different systems. In the new software, it should be enough to enter it once. That's important to me! Maybe the customer can even enter the order digitally themselves. So I'm noting the following specific example situation (Fig. 3): 'The Schulz family orders a small vegetable box for the weekend.' That should be enough of a reminder for us to think about improved order processing in the project."

Figure 3: The path to the first sticky note with a specific business example

"Why don't we just write ‘order processing' on the sticky note?" asks a technical expert. "Because then we’d be missing the business context. Order processing encompasses much more than just entering a single small order, which is sufficient for my point - I just don't want to look at anything more or less than my example."

One technical expert chimes in: "It's not uncommon for customers to reorder the same items. That would be the next sticky note: 'The Schulz family orders the same vegetable box from last weekend for next weekend too.'" The first expert counters: "But that order can still be changed!"

The second expert agrees: "That's right, so we'll add 'a liter of milk', then we'll have refrigerated products included too. We have to enter an exact delivery time for these so that they can be received in person. So I'll continue…‘and specify Saturday, 9-10 AM as the delivery time.'" The first expert notes: "We shouldn't do that anymore, because our drivers can barely make that deadline. Let's just say 'in the morning.'" The second technical expert asks: "But what if the family is not home after 10 AM?" No one has a quick solution, but the problem is clear in the example. In the end, the sticky note reads: The Schulz family orders the vegetable box from last weekend for next Saturday and adds a liter of milk, but can only receive the box at home up until 10 AM.

"I can think of a few more example orders, like pickup orders," grins one of the experts. For Paulina, this is the sign that the group has understood the principle. Now everyone can write their own sticky notes.

"Don't skimp on the details. There’s no such thing as 'too specific!'", shouts Paulina. "Every detail can be a good clue to better understand the subject domain!" And: "Please write your name or initials at the top of the sticky notes so that we can ask you questions if necessary."

In just a few minutes, the area around Paulina's two example sticky notes fills up with many more examples (box: "Tips for brainstorming").

Tips for brainstorming

• Find interesting examples that reflect your questions, ideas, concerns, and other points that are important to you.
• Think outside the box - where the "box" is exactly will be clarified later.
• Break down longer examples in a meaningful way - they will be put together later.
• Ignore duplicate examples - they’ll be summarized later.
• Don't be afraid to leave gaps! This is not about diligence and completeness. It's never too late to add examples. We’re taking an iterative and incremental approach.
• Add your name so that questions about your example can be directed to you.
• Trust your expertise and go into the brainstorming session without any baggage.
• Let yourself be inspired by other’s ideas.

Stakeholder Sinan writes: "The new software must be customer-oriented!" Paulina thinks this is too general and asks for a concrete example of customer orientation. "Oh, there are many," says Sinan, "For example, you should also be able to order from your phone." Paulina thinks this is too solution focused. "In what situation is ordering from your phone important?" she asks. "Well, for example, if I look in the fridge and realize that it urgently needs to be restocked. I'm not going to run to the PC!" "Perfect, that's a very clear example!" says Paulina and suggests writing it down on a sticky note. Sinan then comes up with many other concrete examples (Fig. 4).

Figure 4: Freshly brainstormed but not yet clustered technical examples

A half an hour later, only a few new sticky notes were being written, a signal for Paulina to move on to the next phase. “Read through everyone’s sticky notes. If one of your sticky notes matches the content, take it and add it to the others. This will create content clusters.”

The sticky notes are moved and if by magic, the first clusters begin to emerge (Fig. 5). Paulina helps to separate the clusters and sticks green sticky notes to them. "Write the topic of the cluster on the green sticky note, this makes clustering easier," she says. A developer notes that some clusters overlap in terms of content and that some sticky notes fit into several clusters. Paulina is aware of the problem, but knows that perfection is difficult at the beginning and that the clustering will improve with each scenario casting. So she says: "Just put the sticky notes in the clusters where you think they fit best. It doesn't have to be perfect right now."

Figure 5: Scenario backlog clustered by content

After a short time, all yellow sticky notes have been assigned to a cluster. Some assignments were discussed a little more, while others not at all. Paulina now reviews the clusters with everyone, but without looking closely at the individual yellow sticky notes - there are simply too many for that.

“Are the clusters meeting expectations so far? Is anything important missing?” she asks. A few more notes are moved around, but the group is more or less satisfied with the results. Almost 100 examples have come together and been summarized into twelve clusters. Some clusters are very large, while others only include one or two examples. “You can already see where the crux of the problem lies,” says Paulina, pointing to the largest cluster.

She explains: “This entire thing is called a scenario backlog. We’ll take care of all of these topics here!”. With that, Paula ended the kick-off meeting which lasted a good two hours.

What did we achieve during brainstorming?

We have:

• Located the most diverse questions, ideas, and concerns of the participants in the field of expertise through concrete examples, making them “compatible” with each other.
• Compiled an initial scenario backlog with technical examples from the project participant's perspectives.
• Formed initial thematic clusters within the specialist domain (the thematic clusters practically never correspond to the subdomains identified later in the first step!).
• Gained an initial impression of the scope and complexity of the individual thematic clusters.

Step 2: Paulina prioritizes

The second workshop is scheduled for the following week. This time, the group will be joined by colleagues from purchasing who have also added their sticky notes and an additional cluster.

Paulina opens up the second workshop. She’s divided the area with the clustered examples into two new areas with a line: the area above is called "focus" and the area below is called "out of scope" (or "outside of consideration", see box: "Tips for Prioritizing").

Paula explains, “Today we will go through our scenario backlog to make a rough prioritization and focus on a few examples. We’ll do this by hanging sticky notes that we think we should deal with immediately in the upper area, and sticky notes that you think are invalid, irrelevant, or outside of our project below. You can just leave the rest hanging." Paulina emphasizes that the participants can decide independently. "There’s only one rule: If you find that a sticky note has been hung incorrectly by someone else, speak up and we’ll discuss it."

Since Paulina knows that most sticky notes tend to move up, she has drawn the upper focus area to be significantly smaller. She adds: "Please only put the sticky notes in the upper area if you think it’s essential that we examine them now."

Tips for prioritizing

• Relevancy is key! Nothing’s more frustrating than analyzing and implementing irrelevant parts of an orientation scenario. It’s not worth tolerating the irrelevant, no matter how reasonable it may seem in the situation (e.g. because we want to start with something simple and one of the irrelevant examples seems deceptively simple).
• Drama, baby! We usually learn very little from the "happy path". So don’t hesitate to look at cases where everything didn’t go smoothly (from "There are no more eggplants available, so zucchinis are packed in the vegetable box", for example, we learn that certain products are interchangeable).
• Choose a scenario casting strategy (more on this in the box: "Typical scenario casting strategies"). This makes it easier to select suitable examples.
• Discuss the prioritization. In addition to the obvious goal of setting a focus in the scenario backlog, the goal of prioritizing is for the project participants to express and align their ideas about the goal, scope, and strategy of the project. Prioritizing the scenario backlog is a recurring opportunity for this. If prioritizing is difficult, it shows how necessary such a discussion is.
• Less is more! The larger our area of focus, the longer implementation takes - especially at the beginning, when much has to be rebuilt. This can quickly become unagile! A narrow focus makes it easier to get into a process with short feedback cycles.

One expert moves a few special cases to the top and is immediately met with opposition.

"Let's look at the standard cases first!" Paulina suggests focusing on the most representative examples first, like on a "sightseeing tour through the domain", to get a rough overview. The participants think that it’s a good idea and start to select suitable examples.

It’s noticeable that there are many special cases for products that need to be cooled. The experts agree to exclude these cases. "That's a separate, bigger topic". Paulina writes down on a sticky note for prioritization: "Premise: No products that need to be refrigerated". Premises must be regularly checked for their validity.

Typical scenario casting strategies

Exploring a domain with the help of scenarios is similar to exploring a foreign city. The purpose of the visit determines how we best organize our trip. There are many different trips that can be worthwhile to get to know a city:

• Sightseeing tour: A single long scenario that describes the most important technical processes, but does not go into depth. This is often a "happy path", or an ideal, "smooth" process flow. Goal: obtain a rough overview and first impression, identifying the first subdomains, forming teams, creating the first solutions in collaboration.

• Day trips: Short, in-depth scenarios. Goal: to gain a precise understanding of individual process steps (e.g., special cases or problem areas in implementation), to develop the products, to differentiate the interaction of the products, and to connect them to the infrastructure.

• Backpacking: A long, intensive scenario that describes a selection of particularly exciting situations in depth. Goal: to develop a very realistic understanding and feeling for the domain, to create an inspiring foundation for innovative ideas, whereby the domain can be better supported technologically.

• Journey through hell: A scenario that describes particularly difficult situations or constellations. Goal: to understand particularly complicated parts of the domain and to take the fear out of them.

• Site visit: One or more highly branched scenarios within a subdomain. Goal: comprehensive process documentation of a subdomain, for example, to explore the possible use of third-party software; acceptance of finished products/test design.

A domain expert points to an example and asks where products such as cheese and sausage should be classified, as they don’t need to be kept chilled at all times, but stay fresher for longer when refrigerated. The experts are unsure and write this on a red sticky note (similar to the hotspot sticky notes from the event storming), which they attach to the example: "Always refrigerate cheese/sausage?"

Figure 6: Prioritized scenario backlog

In the end, there are a good dozen sticky notes in the focus area (Fig. 6). The "organic label for private producers" cluster has been completely moved to the out-of-scope area. The topic is too large and doesn’t need to be pursued as part of the project. The "Producer contracts" cluster was also removed, as the contracts should continue to be managed with the existing software - something most participants weren’t aware of. "It's good that we talked about it," says Paulina. Two additional invalid examples were also removed, causing two developers to have an “aha” moment.

What have we achieved by prioritizing?

We have:

• Developed an initial strategy for starting the project/next project phase.
• Identified and documented initial technical questions.
• Clarified the project's technical scope.
• Prioritized technical examples in the scenario backlog.

Step 3: Putting everything together (aka fishbones)

Paulina is happy with the results and goes through the individual sticky notes in the focus area with the participants. One sticky note is pushed back into the scenario backlog because it no longer seems important. "That's a lot of examples," one of the developers notes. "Aren't they somehow connected?" "Yes, they are," Paulina answers. "That's why we are now combining them into longer stories."

Figure. 7: Visual legend of the sticky notes in the scenario casting

Paulina takes the sticky notes from the focus area and distributes them above a timeline from left to right (Figure 8). The timeline serves as a guide to order the examples in chronological order. "It’s important that the story we are putting together here is plausible!" Paulina emphasizes (box: "Tips for putting everything together"), because of course some examples can be put in a different order.

Figure 8: Unordered technical examples on a timeline

"What would be a good starting point?" asks Paulina. An expert says, "Here, this one: 'Private producer Meyer offers 20-25 fresh eggs for the weekend'." The expert hangs it at the front of the timeline. "'The Schulz family orders a small vegetable box for the weekend' would also be a good starting point," another expert notes and puts the note further back on the timeline. Additional sticky notes describing the assembly, transportation, and delivery of a box to the customer, as well as other notes on calculating and accepting a price for the producer, are loosely attached to the timeline. Eventually, all sticky notes form three loose clouds around the timeline (Figure 9).

Paulina asks for the theme for each cloud. "The first cloud is 'Private producer offers products', the second is 'Family Orders Box' and the third is 'Daily closing'," suggests a technical expert.

Figure 9: Examples grouped into loose clouds on the timeline

"Now let's go through the clouds," suggests Paulina. "The goal is to form a coherent story from the different examples." Two experts begin to arrange the examples in the second cloud chronologically. One of them ponders aloud: "The Schulz family could order a vegetarian box instead of a vegetable box, then the eggs from producer Meyer could also be included." "Then we could remove the example of the Becker family, who ordered cheese and eggs, right?" asks the other expert. "Yes, we've covered the animal products with the vegetarian box," the first expert replies. "But dairy products are also interesting, because they're always ordered separately and aren't included in the vegetarian box." In the end, the two experts agree on the following example: "The Schulz family orders a small vegetarian box and 200 grams of wild herb cheese for the weekend."

Tips for combining ideas

• Experimentation is the key. Start by combining the examples in an uncreative way, based on causal dependencies. Many variations are possible, just choose one of them.
• Play with the combined scenarios. Scenarios are robust and can be easily divided and recombined.
• Ensure that each scenario has a relevant and meaningful outcome (E.g. “Vegetable box delivered" is how the delivery scenario ends).
• Make sure the scenarios are plausible and realistic. The more typical or illustrative they are, the better. If an example doesn't fit into an existing scenario, create a new one but remember they don’t need to be connected.
• Make the details of the combined examples match so that they fit together and create a coherent story, without changing the intended meaning of the examples. When in doubt, ask (the name of the author is on the sticky note).
• Don’t duplicate examples, as this would mean that we are unnecessarily looking at the same context several times; summarize similar examples. Make sure that no aspects fall by the wayside - if in doubt, ask here too.
• Prioritize: If individual examples or entire scenarios are no longer relevant, move them back to the scenario backlog.

The remaining examples were also adjusted in the first two clouds and put in a final order. In this way, two small stories emerged from the loose clouds (Figure 10). The third cloud "daily closing" remains unsorted, as the participants no longer find the topic interesting in comparison to the other two stories. Paulina later moves it back to the scenario backlog.

Fig. 10: Two combined stories ("fishbones") and a cloud

"Great!” Says Paulina, “We’ve found two stories that contain the most important standard cases. We can now use these as a guide for the rest of the project. That's why we call them orientation scenarios." Paulina smiles: "However, most people call them 'fishbones' because they branch off from the timeline like fishbones- it’s just so catchy!". "Shouldn't we divide the second fishbone into order and delivery?" asks one expert. The others agree, because new actors are involved in delivery. "And we can then combine supply and order," suggests the same expert, but the others don't agree. So we’re left with three orientation scenarios and one loosely connected cloud (author's note: thanks to Jan Crüsemann, who came up with the idea of clearly visualizing orientation scenarios on a branched timeline).

What did we achieve in the combination process?

We have:

• Discussed and clarified initial technical connections.
• Combined all the important technical examples into plausible orientation scenarios.
• Set the focus for the next expansion stage, where the teams will independently bring the orientation scenarios to life.

Storytelling with Paulina

Paulina gives an outlook on the next steps: "Now that we have outlined three central orientation scenarios, we’ll analyze them in more detail. We’ll do this in separate meetings, so that those who aren’t involved in the respective orientation scenario can opt out - so nobody has to worry about missing anything."

Once the orientation scenarios have been implemented, then the next scenario casting will be held to set a new focus for the subsequent sprints.

Paulina's top priority now is to identify the subdomains impacted by the orientation scenarios and assemble teams to develop solutions for each.

The orientation scenario description so far only summarizes the most important aspects without going into detail. Paulina knows it’s not enough to be able to differentiate between subdomains or start agile solution development. That’s why she wants to go into depth with the subject matter experts and explain the orientation scenarios. Paulina uses two main methods for this:

• Domain storytelling describes graphically how actors in a scenario communicate with each other, exchange information and work items, or work with them.
• Event storming describes the business events that have taken place within a scenario on orange sticky notes from left to right.

Both methods are equally suited for gaining a better understanding of the technical relationships in the orientation scenarios, identifying subdomains and filling product backlogs.

Paulina invited them to another workshop to talk about the first orientation scenario. She now goes into detail with the subject matter experts, using the orientation scenario sticky notes as a guide (box: "Tips for narrating orientation scenarios").

Tips for narrating orientation scenarios

• Stick to one story! Scenarios can often branch off in many directions, but by following one branch through, the relationships between the different elements become clearer ("Box delivered" vs. "Customer absent upon delivery"). If a branch is interesting, add it to the scenario backlog.
• "HUG, don't KISS!" Scenarios without specific details are often simpler, but less meaningful ("order checked": unclear what will be checked and with what result). When developing solutions, KISS ("Keep it simple, stupid") helps to avoid unnecessary complexity.
• When it comes to problem analysis, hold back on generalizations - or "hold ur generalizations" (HUG).
• Focus on the concrete instead of abstracting. As orientation scenarios become more detailed and complex, use premises to reduce scope in a technically meaningful way. For example, the premise "Private producers accept the proposed prices" hides the topic of price negotiation while maintaining scenario integrity. Consider the remaining hidden details in further orientation scenarios (keeping them in the backlog until then).

When telling the story, the experts often encounter situations that could develop differently than expected. Paulina suggests capturing alternative storylines on yellow sticky notes like in brainstorming sessions, and adding them to the scenario backlog alongside the narrated orientation scenario. "Everything goes into our scenario backlog!" explains Paulina. "We’ll analyze it as soon as it’s prioritized in one of the next scenario castings." This way the subject matter experts achieve two things: (1) telling an exciting, meaningful story and (2) adding more technical examples to the scenario backlog for later.

The developers understand the vivid and detailed orientation scenario, and have ideas on how to implement it in software. First, Paulina wants to identify the subdomains involved to build teams accordingly. She explains: "To break down our specialist domain into subdomains, we can first break down our orientation scenario into sub-processes. Each sub-process aims to achieve a specific result. And further sub-processes are only started once the previous sub-process has been completed."

Paulina leads the group through the orientation scenario and asks, "At which points have we completed a mission and permanently finished a sub-process?" Subject matter experts easily identify subdomains, as they are familiar with the central results in their processes, which often trigger subprocesses in other subdomains.

Paulina demarcates the sub-processes from each other with lines. On green sticky notes, she notes what mission is fulfilled by each sub-process (see Figure 11).

Figure 11: Narrated and sub-divided orientation scenario plus scenario backlog for newly discovered scenarios

Developers find similar missions and suggest merging them into subdomains. For example, the "Determine next pickup point of the tour" and "Determine next delivery point of the tour" missions in the delivery scenario are merged into the "Determine next destination of the tour" mission and the "Tour coordination" subdomain." Gradually, the subdomains begin to emerge.

“It’s great how, after the scenario casting and orientation scenario workshops reveal everything we need for the solution development,” says one of the developers happily. “I’ve only been involved for a short time, but I’ve been able to understand the orientation scenarios well and why we’re focusing on them,” adds another developer.

After the workshops, the project developers come together in two teams and divide up the subdomains among themselves. They’re now ready to start developing the solution. Paulina sums up the goal of the next sprints: "Let's make sure that the orientation scenarios become reality!"

There’s still a lot to do - but everyone agrees, it no longer feels like an unmanageably large project, but like a task that can be tackled in a few sprints.

To expedite the filling of the product backlogs, Paulina suggests splitting the narrated orientation scenarios further into meaningful user stories: “This is the simplest approach, as each section of a user story can be directly used as its first acceptance test”. One developer agrees, reflecting that a test-driven development (TDD) or behavior-driven development (BDD) approach would be well-suited for this task.

After each sprint, Paulina marks the implemented parts in the orientation scenarios and can track progress across the team. The subject matter experts also appreciate this overview, as it gives them good insight into implementation.

Paulina notices that the payment sub-process implementation seems to be taking longer and speaks to the affected team. Apparently, the third-party payment processing system can’t be easily integrated due to licensing restrictions. The team came up with an easy emergency solution to process payments manually by invoice for the time being. Even though this solution differs from the narrated orientation scenario, which specifies direct debit payments, it would allow the entire orientation scenario to be tested on time. Paulina consults with the experts, who approve of the proposal.

One sprint later, Paulina has marked all the orientation scenarios in green. Now comes the exciting moment to test all three orientation scenarios in an integrative way.

Since the two teams have developed their solutions precisely for this test and were already tested in advance with the orientation scenarios, there are no major problems. Only a few minor things need to be fixed.

Paulina has seen this done differently before and is glad that the teams had a specific, testable example process (the orientation scenario) to work with, rather than an abstract solution idea as a specification. The project's testers are now reviewing alternative test scenarios derived from the orientation scenarios.

The second iteration

Paulina is relieved that the second iteration can begin after just a few sprints. When she first used scenario casting, she wasn’t aware of the different scenario casting strategies and she and the team at the time unconsciously chose a backpacking strategy (box: "Typical scenario casting strategies"). Although the results were very revealing, they were far too extensive to implement in a reasonable time frame. Since then, Paulina's scenario casting has always focused on ensuring that the assembled orientation scenarios can be completed in a short time. This is difficult to estimate in the first iteration, as the teams themselves often don't know how fast they are and often build more than is necessary for the first orientation scenario. Paulina starts the second iteration by tidying up the scenario backlog together with some subject matter experts:

• Completed examples are removed.
• The remaining examples are clustered according to the newly recognized subdomains, where appropriate.
• Empty old clusters are removed.
• The newly discovered scenarios from storytelling are sorted into the clusters.

Paulina schedules the next scenario casting session online and transfers the scenario backlog to a virtual whiteboard for everyone to collaborate.

The group refrains from brainstorming since the scenario backlog is already full and there are no new or significantly changed technical examples. Participants can still add new technical examples to the scenario backlog at any time.

The first iteration revealed that integrating the existing systems, not just the payment system, into the new architecture was challenging. Paulina suggests applying the day trip strategy and taking a closer look at the identified problem areas using shorter scenarios. The group is now taking a closer look at the ordering process, as it’s unclear whether and how small private producers' goods can be imported into the old system. The process of paying via invoice will be examined in order to put the selected emergency solution on a solid footing.

At the end of the scenario casting, which is much shorter this time, there are seven small, largely parallel orientation scenarios that precisely describe the technical nature of the above problem areas. The new orientation scenarios are also narrated again.

And so the group continues its joint journey through the technical expertise of the project.

The project’s roadmap ahead

Initially, projects lack cross-team orientation. Over time, this need decreases, and scenario casting evolves. Orientation scenarios start as overviews and become shorter and more focused, involving fewer teams. Eventually, only neighboring teams or individual teams use scenario casting to define their interfaces or products.

Near the project's end, teams often need to consider only a few, very short but numerous targeted scenarios. These can be chosen directly from the scenario backlog or brainstormed and narrated on the spot. The "fishbone" technique is usually no longer needed or is trivial at this stage.

Scenario casting only becomes helpful again for large groups when there are extensive or far-reaching changes in the domain knowledge, such as due to legal changes.