This position paper considers ways to manage the complexity of business-process models by applying artifacts from different domains such as personas and stories. We especially look at how stories can support the description of business processes and how personas support the creation of stories and finally of business-process models. A conceptual model of discussed artifacts is provided as UML class diagram. Additionally, dimensions of a framework (scope, form, focus, level of abstraction and intended use) are discussed that allow the characterization of different approaches to use stories and scenarios.
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 [
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 [
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 [
• 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.
Legend and
Story Slice 2 Slice 1 Jindrich: Story1 Petr: Story2 Patrik: Story3
Ladislav: Story4
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 [
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” [
In role <role> I want <feature>, so that <reason> 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 [
In role <role> [as <persona>], I want <feature>, so that <reason>.
Epics are high-level requirements [12] and represent larger or vague features [
For <customer> Who <do something> 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”> Business Outcomes <the measurable benefits that the business can anticipate if the epic hypothesis is proven to be correct.> Leading Indicators <the early measures that will help to predict the business outcome hypothesis.> NFRs <Non-functional requirements associated with the epic.>
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 [
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 [
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 [
Computer Interaction. Academic Press (2002). [18] D. Simões, P. Antunes, J. Cranefield, Enriching Knowledge in Business Process Modelling: A Storytelling Approach, Intelligent Systems Reference Library Vol. 95, p. 241-267 (2016). doi: 10.1007/978-3-662-47827-1_10. [19] K. Thier, Storytelling in organizations. Management for Professionals. Springer Nature, (2018). doi: 10.1007/978-3-662-56383-0_1. [20] B. Tucker, What makes a good Epic? https://www.ivarjacobson.com/publications/whenepic-done, last accessed August 9th (2024). [21] B. Tucker, K. de Mendoza, Better epics in SAFe, https://www.ivarjacobson.com/writingbetter-epics-in-safe, last visited August 9th (2024).