Storytelling is an ancient and proven strategy to create and pass along knowledge, and thus it is not surprising that stories and scenarios are also widely used in the domains of business process management and software development. Fog et al. [9] highlight the importance of storytelling for processes of shared understanding and sensemaking in companies: "The stories we share with others are the building blocks of any human relationship. Stories place our shared experiences in words and images. They help shape our perception of ''who we are'' and ''what we stand for''. Likewise, stories are told and flow through all companies" [9]. The use of stories in the context of management tools is considered in [19]. In agile software development, 'epics' and 'user stories' are employed to support developers in understanding (user) requirements and organizing their implementation work [4]. User-centred design and requirements engineering approaches recommend to create personas representing user groups and scenarios describing their current and envisaged activities for evoking discussions among stakeholders about problems in the 'system-as-is' and alternative (software) solutions for the 'system-to-be' [17], [2]. More recent tool support for applying storytelling include Davis et al.'s [5] tool for mobile storytelling that is also applicable for business-process management and the enhancement of stories by AI concepts as suggested in [16].
It is commonly assumed that the description of concrete scenarios or settings helps stakeholders in collaborative reasoning and decision making. However, storytelling is only effective if it is used in a creative and integrated way with (semi-)formal specifications or modelling artifacts. For example, storyboards and process models are explored in the study by Simões et al. [18] to overcome the dominant procedural perspective of the workflow paradigm. The study also reveals, though, that the quality of the stories suffers if participants are too entrenched in the established way of abstract process-based thinking and modelling. Created stories do not tell the existing reality and lack of contextual richness [18].
An effective use of stories and scenarios not only requires appropriate conceptual mappings between involved artifacts but those concepts and mappings must be operationalised in corresponding tool support. Floruț and Buchmann [8] provide the example of epics and user stories in agile development where the conceptual understanding is "oversimplified by tooling decisions". While, at the conceptual level, epics are seen as larger user stories which are difficult to manage and require further slicing they are often treated in tracking tools as a simple set of user stories and merely serve reporting purposes [8].
This position paper suggests the development of a classification framework that allows us to characterise in a more systematic way different approaches to use stories and scenarios for business process management and other modelling artifacts. Such framework could help us to better understand the potential role and purpose of stories in managing the complexity of modelling problems. It could help us to expose and remedy existing confusions in terms and to address the above mentioned challenges.
In previous work [6], we propose an integrated use of personas and use cases. Both kinds of models cross-pollinate each other and become more detailed and more expressive. In a similar way, the combination of use-case slices with behavior models of Subject-Oriented Business Modelling (S-BPM) is discussed in [10]. In a recent paper [11], we elaborate those different usages of stories in more detail. Based on our experience and a classification exercise for agile artifacts (epics, user stories), we suggest in this paper five candidate dimensions of the framework (scope, form, focus, level of abstraction, intended use) by discussing some existing approaches of using stories and scenarios and identifying possible applications.
This section presents initial ideas for a framework to classify the diverse understandings and uses of stories in the domains of business process management and related software development processes. In order to ground the suggested ideas, we start with a simple example demonstrating the combined use of stories and other modelling artifacts for business modelling. Then, the understanding of stories in agile development is considered in more depth. Finally, dimensions for the classification framework are introduced.
The example illustrates the combined use of artifacts from different domains for business modelling. For more details, we would like to refer the reader to [6], [10], [11]. Let us assume that a software system has to be developed for the University of Prague that supports the management of business trips. The three roles Employee, Manager and Agent are identified and can be represented as pools in BPMN [1]. We only take a closer look at the role Employee and assume that it comprises four sub-groups that are represented by the personas Jindrich Stanek, Petr Sevcik, Patrik Schick and Ladislav Krejci. For each persona, a story is created that shows the specific motivations and needs of the represented sub-group of employees when it comes to business trips. For reasons of brevity, personas and stories are not described in detail here. In the following, only an overview is provided.
• Story 1: Jindrich Stanek is a Senior Manager at the University of Prague. He does not want to be involved in the booking process of train tickets and hotels. He delegates this task to an agent. • Story 2: Petr Sevcik is a Software Developer at the University of Prague. He is interested in trains and wants to book a hotel after having the train tickets. • Story 3: Patrik Schick is a Journalist at the University of Prague. He tries to combine his business duties with visits to cultural event. Therefore, Patrik books a hotel according to events and afterwards he books the train tickets.
• Story 4: Ladislav Krejci is a Junior Manager at University of Prague. He is not allowed to travel.
The stories are used in the example to inspire BPMN modelling ideas and facilitate decision making. The BPMN diagram in Figure 1 shows activities in the pool 'Employee' that are related to the role of the same name. The pool is annotated by four thick arrows representing the stories and indicating how they 'informed' the development of the model. Additionally, the diagram groups the four stories in two groups (depicted by green arrows and dashed purple arrows) that can be considered as slices to support agile process management. Slices were originally introduced in Use Case 2.0 [13], [14] to support the implementation of use cases within agile processes with short development cycles. The combined use of BPMN diagrams with artifacts such as personas and stories from usercentred design and slices from Uses Case 2.0 can enhance business process modeling. If personas and stories provide more contextual information and a more differentiated view of (people acting in) roles corresponding business-process models become more expressive by covering more situations. The stories and slices in the example annotate the BPMN diagram but do not change the notation itself. In the integration approach of personas and use cases in [6], we not only annotate use case models but adapt the specification template by Cockburn [3] and suggest a new relationship (<<automate>>) for use-case diagrams.
Stories in the above example are about 'concrete' characters who are explicitly specified as personas. User stories and epics in agile methodologies have a different character. User stories are textual descriptions capturing "fundamental elements of a requirement: who is it for, what functionality is it to be developed, and why is it essential" [7] which can be implemented within an agile sprint. They are typically written down as a sentence that is structured according to the following template.
An example for the above business trip management system:
In role Employee, I want to receive the permission of a business trip, so that the trip can be booked.
User stories describe a feature from the user's perspective but at the abstract level of roles. In [11], an extended template of user stories is suggested which optionally includes a persona. It can support the discussion when and why certain features are necessary to be implemented. In role <role> [as <persona>], I want <feature>, so that <reason>.
Epics are high-level requirements [12] and represent larger or vague features [7]. According to Tucker [20], epics are large step changes in cooperate capability. They have to be refined to features (services that fulfils a user need -the normal path) and further to user stories (something of value a team can complete in an iteration). Tucker and de Mendoza [21] propose a semi-structured notation for epics.
The <solution> Is a <something -the "how"> That <provides the value> Unlike <competitor, current solution or non-existing solution> This <does something better-the "why">
The template consists of two parts, the first one describing the context and the goals of the epic and the second one specifying how the success of the implementation of the epic is evaluated. It is influenced by the user story template and at a similar level of abstraction. The semi-structured notation may be valuable for reporting purposes. It is less appropriate, though, to foster the creativity of stakeholders. According to Hollis and Maiden [12], agile processes require creative activities especially in the envisioning phase and in epic processes to discover low-level requirements. 'Motivational stories' in the form of narratives or storyboards which provide a contextual background for the planned business process (including the software system(s) to be developed) may help to create and establish a shared system vision and to come up with high-level requirements or epics in the envisioning phase. Similar to problem scenarios and activity scenarios in [17], motivational stories should introduce the stakeholders, their goals, motivations, some tasks they have to perform etc. However, details of business processes should be avoided at this stage. More detailed 'epic stories' in natural language should support the generation of alternative solutions to 'decompose' epics into user stories and shared decision making. The characters in the stories can be based on personas.
Figure 2 shows a slightly adapted UML class diagram from [7] that models agile requirements concepts and their relationships. It is extended by the above discussed mappings to personas and stories with 'concrete' actors and situations or settings. The diagram also indicates that acceptance criteria are assigned to user stories. They are "conditions of satisfaction that complement user stories" [7]. In this context, Jacobson et al. [13], [14] propose to combine user stories with use case slices. A more detailed consideration of this relationship is beyond the scope of this paper.
We propose to analyse and describe the use of stories and scenarios in terms of scope, form, focus, level of abstraction, and intended use.
Many approaches in user-centred design and requirements engineering distinguish between models of the current or existing situation (system-as-is) and models the envisaged or future situation (system-to-be). In the scenario-based approach in [17], problem scenarios describe current practices while activity scenarios, information scenarios and interaction scenarios refer to possible futures.
Stories and scenarios can be in a narrative form (e.g., as text, storyboard, video) or in the form of a (semi-)structured text or sentence following a template.
A story or scenario can describe one or more actors, their activities in certain settings, personal motivations, goals, relationships etc. (e.g., problem scenarios and activity scenarios in [17] or motivational stories in Figure 2). It can also focus on a certain system feature (as in user stories in agile approaches), on the interaction steps between a user and a system or steps in a business process (e.g., interaction scenarios in [17] or usage narratives in [3]).
Elements of a story or scenario such as actors, activities or artifacts can be generic or more specific. For example, actors are described in terms of roles (such as in user stories) or by fictive persons.
The intended use of a story or scenario can be described by (explicit or implicit) mappings to other modelling artifacts (e.g., personas, user stories and epics in Figure 2, claims in [17], use cases, BPMN models). Simple mappings just link a story to another artefact and often indicate that it is used for inspiration. More complex mappings link elements or parts of a story to parts of other artefact(s) and indicate a more systematic use to develop or validate them (e.g., the BPMN diagram in Figure 1).
Stories and scenarios vary widely in scope, form, content, level of abstraction, and intended use. The proposed classification framework can help to position and reflect upon existing approaches to employ stories. For example, scenarios in the user-centred design approach by Rosson and Carroll [17] cover current and future situations (scope). They are mostly textual narratives and differ in their focus. All of them are 'concrete' scenarios describing specific situations of characters which can be mapped to personas. However, there is a lack to more formal modelling artifacts. User stories and epics in agile development are more generic descriptions (semistructured sentences and text respectively) which focus to a large extent on features of an envisaged technical system. User stories are refined by acceptance criteria that are used for implementation and testing. The envisioning process of the system and the exploration of highlevel requirements is here less supported by stories. The framework may support a better integration of stories with other modelling artifacts. It is not always clear whether the actual understanding and use of storytelling lead to the desired outcomes. Does it enable, for example, end-users and other stakeholders to participate in business process modelling as argued by Simões et al. [18]? This position paper provides an example of the cross-pollination of stories, personas and business models (see [11] for more details). In the future, more empirical studies such as [18] are needed to confirm assumptions on an integrated use of stories and other modelling artifacts and to back up the classification framework. Future work also includes the creation of stories at different levels of abstraction (e.g., by using story-splitting patterns [15]).