A Causal Modeling Approach to Agile Project Management and Progress Evaluation

Abstract

Despite widespread adoption, traditional Agile project management practices often fail to ensure successful delivery of enterprise-scale software projects. One key limitation lies in the absence of a conceptually defined structure for the various types of Agile activities and their interactions. As a result, Agile methodologies typically lack formal indicators for evaluating the semantic content and progress status of project activities. Although widely used tools for Agile project management, such as Atlassian Jira, capture operational data, project status assessment interpretation remains largely subjective—relying on the experience and judgment of managers and team members rather than on a formal knowledge model or well-defined semantic attributes. As Agile project activities continue to grow in complexity, there is a pressing need for a modeling approach that captures their causal structure in order to describe the essential characteristics of the processes and ensure systematic monitoring and evaluation of the project. The complexity of the corresponding model must correlate with the causality of processes to avoid losing essential properties and to reveal the content of causal interactions. To address these gaps, this paper introduces a causal Agile process model that formalizes the internal structure and transformation pathways of Agile activity types. To our knowledge, it is the first framework to integrate a recursive, causally grounded structure into Agile management, enabling both semantic clarity and quantitative evaluation of project complexity and progress. The aim of the article is, first, to describe conceptually different Agile activity types from a causal modeling perspective, its internal structure and information transformations, and, second, to formally define the causal Agile management model and its characteristics. Each Agile activity type (e.g., theme, initiative, epic, user story) is modeled using the management transaction (MT) framework—an internal model of activity that comprises a closed-loop causal relationship among management function (F), process (P), state attribute (A), and control (V) informational flows. Using this framework, the internal structure of Agile activity types is normalized and the different roles of activities in internal MT interactions are defined. An important feature of this model is its recursive structure, formed through a hierarchy of MTs. Additionally, the paper presents classifications of vertical and horizontal causal interactions, uncovering theoretically grounded patterns of information exchange among Agile activities. These classifications support the derivation of quantitative indicators for assessing project complexity and progress at a given point in time, offering insights into activity specification completeness at hierarchical levels and overall project content completeness. Examples of complexity indicator calculations applied to real-world enterprise application system (EAS) projects are included. Finally, the paper describes enhancements to the Jira tool, including a causal Agile management repository and a prototype user interface. An experimental case study involving four Nordic EAS projects (using Scrum at the team level and SAFe at the program level) demonstrates that the Jira tool, when supplemented with causal analysis, can reveal missing links between themes and initiatives and align interdependencies between teams in real time. The causal Agile approach reduced the total number of requirements by an average of 13% and the number of change requests by 14%, indicating a significant improvement in project coordination and quality.

1. Introduction

Although Agile project management frameworks are widely adopted, they often fall short in ensuring reliable delivery of enterprise application software. Traditionally, Agile emphasizes iterative development organized into discrete, closed-loop cycles, commonly referred to as sprints [1,2]. Tools built upon this model, such as those aligned with the Scrum framework, typically represent activity types (e.g., user stories, epics, initiatives, themes) in hierarchical structures, but fail to capture the semantic depth of their interactions [3].

A core limitation of existing Agile methods is their lack of a conceptually defined structure. Activity types and their interrelations are neither formally modeled nor equipped with objective indicators to assess internal content or progress. Consequently, project monitoring and evaluation rely heavily on subjective human judgement, often exercised through platforms like Atlassian Jira, rather than on a formal knowledge model or semantic framework. As a result, project status assessments based solely on expert judgment and decision-making that are not linked to a well-defined, structured understanding of processes and causal interactions lack analytical grounding. Such assessments are subjective and may present inaccurate information about the project’s status.

Agile project execution is inherently complex, shaped by human-centric decision flows, multilevel activity hierarchies, and causally interlinked processes. These interactions span vertical management control and horizontal coordination flows, forming a network of dependencies that simple hierarchical schemes cannot represent faithfully. Modeling such complexity requires an approach that reflects the complexity of agile processes, encompasses their causality, preserves their essential properties, and reveals the content of causal interactions.

To address these shortcomings of existing Agile methods, we introduce a modified Agile process model based on a causal modeling approach [3]. In this causality-based model, each Agile activity is formalized as a management transaction (MT)—an autonomous, self-regulating unit defined by its internal structure and causal interactions. This approach enables the classification of both intra-activity interactions and inter-activity dependencies, revealing the semantics of information exchange across Agile layers (theme → initiative → epic → user story). By mapping these causal flows, we preserve essential process attributes and reveal the logic underlying the transformation of information between Agile activities.

This work extends our ongoing research on causal modeling in enterprise application development, refining the method introduced in prior publications, and focusing on the Agile project management domain. The article has two primary aims: first, to conceptualize Agile activity types from a causal modeling perspective, detailing their internal structure and information transformations, and second, to formally define the causal Agile management model and its characteristics, using real-world examples to illustrate its more complex elements.

Particular attention is paid to the recursive nature of interactions between management transactions (MTs) in the presented causal model. MTs are considered causal knowledge units—their structural feature is closed-loop information transformations between elements, reflecting the circular causality characteristic of real Agile project processes. The structure of each MT corresponds to that of a control system with a feedback loop, as defined in control theory. We assume that concepts such as the self-management property of systems and the internal model principle [4] are familiar and therefore will not be discussed in detail in this article.

The resulting formal framework introduces a taxonomy of vertical and horizontal causal interactions within the Agile system. It supports deriving quantitative indicators for project complexity and content status, enabling systematic evaluation of specification completeness and dynamic assessment of activity-level progress. The experimental evaluation was conducted using multi-year data from real-world EAS projects. This article provides summaries and explanations of the obtained experimental results.

The Agile tools environment currently used in practice is empirical, relying solely on expert experience for decision-making. These systems lack a built-in knowledge base and do not incorporate a business domain model that conveys essential process relationships and attributes.

To improve existing tools by transitioning to AI-powered systems, a paradigm shift is necessary—one in which the system incorporates an internal model representing real-world causality. A variant of such an internal model is formally described in the article.

The remainder of this paper is structured as follows. Section 2 analyzes the strengths and limitations of existing Agile process models, elaborates key types of causality, and introduces the management transaction concept. Section 3 formalizes the causal Agile model, develops its hierarchical structure within the Process Space, and classifies vertical and horizontal semantic exchanges. Section 4 presents methods for assessing project complexity and status, grounded in the semantic content of causal interactions, and illustrates them with empirical project data. Section 5 describes the implementation elements of the intelligent Agile project management tool component integrated into Jira and summarizes the results of the experimental evaluation. Finally, Section 6 concludes by summarizing the main contributions of the proposed model and outlining its potential applications for project monitoring and control.

2. Related Works

2.1. Agile Management Models

Agile project management represents a shift in software development practices toward adaptability, feedback-driven iteration, and rapid delivery by self-organizing teams.

Frameworks such as Scrum, Adaptive Software Development (ASD), Dynamic Systems Development Method (DSDM), Crystal, Feature-Driven Development (FDD), and Scaled Agile Framework (SAFe) offer tailored approaches depending on project size, business context, and execution strategy [5,6,7,8,9,10,11,12]. While each Agile framework defines its own scope and implementation style, all share foundational attributes such as iterative and incremental development, cyclical work evaluation (sprints), layered activity hierarchies, and collaborative roles. These methods are based on the values and principles described in the Agile Manifesto [13]. For example,

-

Scrum emphasizes team synergy through daily stand-ups, and 2–4 week iterations with empirical control in the form of planning meetings, iteration reviews, and retrospectives [5];

-

ASD enables rapid adaptation to change through continuous feedback loops [6];

-

DSDM aligns development with business priorities via timeboxed delivery stages [7];

-

Crystal fosters reflective learning and frequent delivery through communication-focused practices [10];

-

FDD applies domain modeling and feature-centric design principles [11];

-

SAFe scales Agile across enterprise teams through defined roles and synchronized release increments [12].

Each framework has its own strengths and challenges in terms of scalability, flexibility, and implementation. Today, the need to scale Agile practices is critical for organizational growth, helping to maintain efficiency and alignment across multiple teams [14,15,16].

SAFe (Scaled Agile Framework) is highly scalable and offers a structured approach, though it requires significant effort in customization and implementation. Nexus builds on the simplicity of Scrum, enhancing collaboration and integration; it is moderately scalable and relatively easy to implement. LeSS (Large-Scale Scrum) emphasizes simplicity and effective communication, offering flexible implementation while maintaining scalability for large organizations. A detailed comparison of these advanced Agile frameworks is beyond the scope of this article, which aims to present a paradigm shift in Agile process modeling. Such detailed comparison of advanced Agile frameworks can be found in [17].

Despite their merits, these frameworks and typical Agile processes place significant reliance on the expertise of team members involved in the project. The cognitive load on Agile teams is substantial, as they must manage multilevel activity hierarchies under dynamic conditions and with limited formal semantic structure. This complexity, combined with rapid iteration cycles, often results in incomplete oversight of critical details, making process management and value delivery prone to errors [18].

The causality-based modeling method proposed by the authors can be integrated with any of these Agile approaches. It offers a way to supplement them with an internal model that is essential for developing AI-powered systems.

To achieve strategic business objectives, Agile software development projects must coordinate and process large volumes of information across diverse activity types.

Table 1. Agile software project management concepts.

Hierarchy Level	Agile Concept	Description	Number of Objects
1	Strategic Business Objective (So)	A concise statement of a long-term business goal, linked to the organization’s vision and mission.	1
2	Theme (Th)	A high-level objective with time and budget constraints that contributes to strategic business goals.	1–5
3	Initiative (I)	A targeted activity supporting the realization of goals at the theme level.	5–15
4	Epic (E)	A broad functionality description aligned with the goals of the associated initiative.	>150
5	User Story (S)	A task expressing a specific business need or problem.	>3000

presents a representative hierarchy of project units, along with their typical distribution, as observed in real-world Agile project implementations.

One of the fundamental shortcomings of typical Agile management practices lies in the limited formalization of activity types and their interrelationships. As a result, tools developed within this paradigm (e.g., Jira) often capture only surface-level details of Agile components, such as user stories, epics, initiatives, and themes, without modeling their semantic content or structural dependencies.

A promising direction for enhancing Agile methodologies involves establishing a systematic and conceptually grounded framework aligned with existing standards. In this context, Agile Model-Driven Development (AMDD), i.e., the Agile adaptation of Model-Driven Development (MDD), is of particular relevance [19]. AMDD introduces structured development cycles, typically spanning 8 to 12 weeks, alongside well-defined project management roles. It integrates Agile principles with a model-based development approach, seeking to combine the flexibility of Agile with the rigor and stability of model-driven software engineering.

At the organizational level, Agile management is distinguished by its self-organizing characteristics, whereby requirements and solutions evolve through collaboration among autonomous teams and iterations of project delivery, called sprints. This self-management fosters flexibility, enabling more rapid delivery of valuable solutions, early identification and resolution of potential issues, and the capacity to adapt to changing needs. Because sprints contain a series of continuous feedback loops, they can be interpreted as discrete self-management cycles.

The hierarchical structure of Agile Scrum is commonly referred to using the acronym TIES, denoting themes, initiatives, epics, and user stories. Links between TIES elements and the overarching strategic business objectives are typically established through informal communication between project leaders and business managers [20]. Notably, the conceptual structure of the Scrum framework is predominantly static and linear, which stands in tension with the principle of self-organizing. An analysis of widely adopted Agile project management tools reveals that they lack any formally defined representation of business context knowledge [21].

As a result, Agile project management tools based on such simplified hierarchical models offer only limited support to project managers and team members. Achieving robust alignment between business and IT requires a more formalized definition of business objectives and Agile process components, particularly including clearly articulated models of information exchange and process transformations throughout the project lifecycle.

To address these limitations, a causal model of Agile processes has been developed. It is grounded in causal dependencies among Agile activities, with their structure formally defined through the management transaction (MT) framework. This framework establishes a hierarchy in which each Agile activity is represented as an autonomous, self-regulating unit [1,2]. Implementing the proposed causal Agile process model requires extending the architecture of existing Agile management tools to incorporate a dedicated knowledge base. This knowledge base should include formally specified strategic goals, clearly defined Agile activity types, and explicit attributes describing vertical and horizontal interrelationships among activities.

Furthermore, the causal Agile management framework facilitates the identification and evaluation of various enterprise management functions, such as software development management, business operations, and financial management, that interact with the development of specific enterprise application systems (EAS). Without a clearly defined internal model of the Agile process and its underlying causal dependencies, it becomes infeasible to deliver AI-supported project management for EAS development, ensure alignment with strategic business goals, or coordinate Agile activities effectively.

2.2. Types of Causality Models

Causal reasoning is a foundational principle in systems theory and enterprise modeling. As outlined in Bunge’s theoretical treatment of causality [22], capturing the causal interactions among entities is essential for understanding their behavior in complex real-world systems. Drawing on these foundational concepts, software engineering applies causal modeling to identify interactions within business processes and to uncover the properties and interdependencies of organizational entities. These insights form the design of the application software that is aligned with business structures and operational needs.

In process modeling, several forms of causality are commonly encountered:

-

Common Cause and Common Effect: In a common cause structure, a single cause (a) produces multiple effects (b, c, …). In contrast, a common effect structure involves multiple causes (a, b, …) converging to produce a single effect (c).

-

Linear Causality: A sequential chain of cause-and-effect relationships. For instance, cause (a) leads to effect (b), which in turn becomes the cause of effect (c), forming a cascading workflow of dependencies.

-

Circular Causality (Transactional): A closed-loop form of causation where two or more events exert mutual influence. Circular causality is characterized by feedback mechanisms that establish a stable and recurring cycle of interactions.

Circular causality is a foundational concept in the scientific analysis of real-world phenomena and plays a particularly important role in enterprise and project management modeling. This systems-based view aligns with Peter Senge’s observation in The Fifth Discipline [23]: “Reality consists of circles, but we see straight lines”.

Circular causality underpins several established enterprise management frameworks, such as Deming’s PDCA cycle (Plan–Do–Check–Act) [24], the feedback-driven structure of Porter’s Value Chain Model [25], Harmon’s business process architecture [26], and the Rummler–Brache model for organizational performance [27]. In control theory, circular causality is explicitly represented through feedback control loops within system architectures [3,4,28].

The topology of circular causality corresponds to a wheel graph (Figure 1). In graph theory, a wheel graph is formed by adding a central vertex, referred to as the Hub, to a cycle graph Cn-1, connecting the Hub to all vertices of the cycle, thereby producing the graph Cn [29].

The conceptual structure of a generalized transaction, as depicted in Figure 1, can be aligned with the architecture of a control system featuring a feedback loop T (Q) = {(S1, …, Sn), (M1, …, Mn), Rs, feedback}, where T denotes the transaction, a single, indivisible logical unit; Q represents the goal (e.g., objective, criterion, requirement, or rule); Si denotes a process element (activity, information transformation, or procedure); Mj denotes a flow component (message, attribute, or data element); and Rs denotes a sequence relationship between processes. Feedback serves as a constraint, ensuring a closed-loop structure among the processes Si, thereby forming a unified circular causality unit.

In systems and application software engineering, the concept of circular causality is abstracted through the notion of a “transaction”. A transaction is typically regarded as a single, indivisible logical unit of work. However, it is, in fact, a complex construct composed of a closed-loop sequence of steps, such as processes, actions, activities, tasks, transformations, or procedures [30,31,32]. The internal process components Si, each with system-specific semantics, may vary depending on the domain of application, for example, transport systems, communication networks, social systems (e.g., cities), enterprises, ecosystems, or biological organisms. In enterprise modeling, this circular causality is formalized as a management transaction (MT), conceptually represented in Figure 2.

Most current work in business process modeling focuses on process mining and workflow optimization [33], model-driven decision-making with generative AI [34], knowledge graphs for diagnostics and semantic modeling [35,36], and decision tables or rule-based systems for control logic [36,37]. While these approaches offer valuable insights into operational efficiency and semantic integration, causal modeling-driven frameworks that incorporate business activity dependencies, recursive decomposition, and strategic goal alignment remain rare [33,34].

The presented approach fills a gap by formalizing causal semantics within Agile hierarchies and linking them to enterprise goals—a space that is ripe for deeper exploration and standardization.

2.3. Causal Model of Enterprise Management Activity

The discovery of causal knowledge is essential for managing the complexity inherent in business processes and for ensuring compatibility with application software systems. Within the enterprise causal modeling method, a management transaction (MT) is defined as a self-managed unit of control and coordination, characterized by a predefined internal structure. The conceptual representation of a management transaction is expressed as MT = MT(Fj, Pi, A, V), where Pi is the basic physical (material) process, Fj the corresponding management function, A the process state attributes (e.g., raw data), and V the controls (or influencing actions applied to process P). The MT structure is illustrated in Figure 2; we will note that the enterprise goal G has an influence as a context, and is therefore marked with a dotted line, but is not included in the formal definition of MT at this conceptual modeling level.

Although G is not a direct component of MT, it is implicitly considered by the analyst and shapes the specification and configuration of the management transaction [3,30].

2.4. Causal Agile Management Model

The causal Agile management model is defined as a hierarchy of management transactions (MTs), depicted in detail in Figure 3 (according to [38]), and aligned structurally with the traditional Agile Scrum hierarchy known as TIES (themes, initiatives, epics, and user stories). The content and interactions of the Agile activity types within TIES are formalized through an MT framework, which functions as a causal knowledge metamodel at the level of Agile tool implementation.

Note. The number of levels in the Agile hierarchy and the semantics of activity types may vary depending on the specific variant of Agile Scrum applied.

Assumption. The interactions between adjacent levels of the Agile hierarchy are conceptually predefined as management transactions (MTs). Thus, each vertical interaction across activity types—such as between themes and initiatives, initiatives and epics, or epics and user stories—is modeled as a management transaction MT(F, P, A, V). In this context, the feedback loop between the management function F and the process P includes two types of information flows: state attributes (A) and control attributes (V).

A key feature of the causal Agile management model is its direct integration of enterprise strategic objectives into the Agile process. These strategic goals are systematically analyzed and decomposed (e.g., using the MODAF StV-1 product), revealing a set of capabilities that reflect user needs. This integration assumes that each named capability corresponds to a top-level Agile activity type, namely, a theme [39]. One of the main advantages of this causal approach is its enhanced precision: defining themes through alignment with formally identified capabilities provides a more objective and traceable mechanism for ensuring consistency between strategic business objectives and Agile project activities—surpassing methods that rely solely on stakeholder experience, intuition, or informal dialogue.

In the next step, the causal Agile management process proceeds by deriving a set of initiatives from each theme, followed by the development of epics from each initiative, and ultimately, the specification of user stories for each epic. A defining characteristic of this model is the formalization (or normalization) of interactions between adjacent hierarchy levels—specifically, between themes and initiatives, initiatives and epics, and epics and user stories—as explicitly defined management transactions. These information flows between layers of the causal Agile hierarchy are aligned with a metamodel structured as a management transaction (MT), ensuring semantic consistency and causal traceability across the process.

We summarize below the key elements and structural characteristics of the causal Agile process (see Figure 3), which form the basis for defining parameters to assess project status at any given point in time:

-

The causal Agile process management model formalizes each activity across all levels of the hierarchy as a management transaction (MT = (F, P, A, V)) (see Figure 2), thereby normalizing the internal structure of diverse Agile activity types.

-

The model exhibits a recursive structure: recursion is introduced through the decomposition of the process element P within an MT. When moving to a lower hierarchical level, the same process element P becomes the core of a newly instantiated management transaction MT = (F, P, A, V) (see Figure 4).

-

While the number of activity types and hierarchy levels can vary across Agile methodologies, this model adopts the Scrum framework, consisting of four primary TIES levels: theme, initiative, epic, and user story.

-

During the initial project scoping phase, the relationships between identified capabilities (C) and the project’s defined themes can be captured using a traceability matrix (see

Table 2. Capabilities–themes traceability matrix.

Capability ID	Theme 1	Theme 2	…	Theme n
C1-<name>	x	-	…
C2-<name>	-	x	…	x
…			…
Cm-<name>	-	-	…	x

). This mapping supports many-to-many relationships: multiple themes may be necessary to implement a single strategic capability, and conversely, a single theme may support multiple capabilities.

-

To support a formal representation of the causal Agile process model, a set of indices is introduced to uniquely identify Agile activities, their states, and their placement within the process hierarchy [3].

-

Each Agile activity is assigned a timestamp (t) and mapped to a specific enterprise management function (r):

-

r ⸦ R, where R = {financial management, IT project management, …}.

-

Additionally, each activity is linked to a concrete physical process (P) via index p.

-

An aggregation level index i (i ⸦ AG, see Figure 6) accounts for the organizational hierarchy (e.g., top-level executives, mid-level departments, lower-level management units, operational level units), providing structural traceability across management layers.

-

An information generalization index j (j ⸦ GE, see Figure 6) captures the degree of abstraction or summarization of information, as required by different decision-making levels, for instance, higher-level dashboards for executives versus detailed data views for operational managers.

In general, each Agile activity is represented as a multi-indexed management transaction, formally described as MT(i, j, t, r, p).

Note: The management transaction framework provides a high-level conceptual model for capturing causal dependencies within enterprise management information systems. While it enables structured reasoning and traceability, it does not represent a fine-grained or exhaustive specification framework. In addition to the management transaction (MT) framework, an extended causal knowledge structure known as the Elementary Management Cycle (EMC) is introduced [3,39]. As proposed in [3,39], this construct is defined as follows EMC = (G, F(IN, DP, DM, RE)), P, A, B, D, V). The EMC framework incorporates internal interactions among ten distinct element types and is conceptualized as a decomposition of the management transaction (MT). It reveals how business goals influence management activity execution and control, thereby enriching the causal traceability of decision-making and operational behavior.

The causal Agile management process is modeled as a system of interactions occurring both within and across levels of the Agile activity hierarchy. These Agile activity interactions are formalized as a set of overlapping management transactions, capturing both intra-level dynamics and inter-level management control.

As mentioned above, a key limitation of conventional Agile approaches is the absence of conceptually defined structures and interaction semantics for activity types and their relationships. To address this, we propose a formal representation of the hierarchical structure of causal Agile management and its associated internal interactions. This formalization enables the systematic definition of both indicators for evaluating the content and quality of Agile project activities and metrics for assessing the current state of the project across its lifecycle. The conceptual structure defined herein serves as a foundation for classifying the theoretically possible interaction types between Agile activities. It also supports the specification of the semantic content of these interactions in alignment with enterprise goals.

We now introduce the following formal notations, which establish the symbolic and structural basis for modeling causal interactions in the Agile process. These notations define the composition, relationships, and semantic characteristics of Agile activities within the causal modeling framework:

-

Let q ∈ Q denote a hierarchical level in the Agile process. For example, a typical Agile TIES hierarchy defines the set Q as comprising four levels: Q = {q1—theme level, q2—initiative level, q3—epic level, q4—user story level}.

-

Let Ψi represent the Agile activity type at a particular level q. In a typical Agile TIES hierarchy the primary activity types are as follows: Ψ1 = theme (Th), Ψ2 = initiative (I), Ψ3 = epic (E), Ψ4 = user story (S).

-

Each Agile activity is uniquely identified by an index n or m, applicable at any hierarchy level. Additionally, every activity is associated with a particular type of enterprise management function, denoted by r (r ∈ R). Example function types include R = {r1—finance management, r2—procurement, r3—quality control, r4—software project management, …}.

-

From the causal modeling perspective, any Agile activity is treated as a management transaction (MT). An MT is a knowledge unit defined by MT = (F, P, A, V), where F is the management function, P the process being managed, A the flow of state attributes, and V the control flow.

Vertical interactions W include both flow types, a control flow V and a state attributes flow A (a feedback). Vertical interactions between adjacent activity levels are formalized as a management transaction MTq(Ψin, Ψjm), where n is an activity of type Ψi at (upper) level q, and m is an activity of type Ψj at lower-level q′. In this way, the management transaction encapsulates the structural and semantic content of vertical interaction between two activities from adjacent levels of the Agile hierarchy and is formally defined as MTq(Ψin, Ψjm) = (F(Ψin), P(Ψjm), Am, Vn), where

-

Ψin is an activity n of type Ψi at hierarchy level q, serving as the management function F(Ψin);

-

Ψjm is an activity m of type Ψj at adjacent lower-level q′, conveying the state of the process P(Ψjm);

-

Am is the flow of state attributes from Ψjm to Ψin, conveying the state of the process P;

-

Vn is the control flow issued by Ψin and directed to Ψjm, influencing the behavior of process P.

Vertical interaction between two activities is considered an internal dynamic of the management transaction (MT), and is characterized by two directional flows:

-

Top-down control flow V is denoted as W(V);

-

Bottom-up feedback flow (state attributes A) is denoted as W(A).

Horizontal interactions across activities at the same level are captured by C and are expressed in terms of coordination flows: Ch(V)—control flow between same-level activities; Ch(A)—feedback flow of state attributes.

Choreographed messaging between activities of differing content is represented as follows: Cm(S)—outgoing message; Cm(I)—incoming message.

These definitions allow for the formal classification of interaction types across the Agile hierarchy. Based on experience in typical enterprise application system (EAS) projects [1], the standard ratios of vertical relationships are as follows: So/Th = 1:5; Th/I = 1:3; I/E = 1:10; E/S = 1:20. In particular, it means that a typical EAS development project includes from 1 to 5 themes, 1–3 initiatives for each theme, 10 epics per initiative, and about 20 user stories per epic.

Finally, to evaluate the structural complexity of an Agile project, we define two types of indicators, the vertical complexity indicator Q1 and the horizontal complexity indicator Q2. The indicator Q1 evaluates the number of vertical interactions involving distinct content types across Agile hierarchy levels. It comprises the following:

-

Q1(q, q′)—the number of vertical interactions between any specific pair of levels q and q′ in the Agile hierarchy.

-

Q1—the total number of vertical interactions with different content types across the entire Agile project structure.

The indicator Q2 quantifies the number of horizontal interactions with diverse content within Agile activity specifications. It includes the following:

-

Q2(q)—the number of horizontal interactions occurring at a single Agile hierarchy level q.

-

Q2—the cumulative number of horizontal interactions with distinct content types across all levels of the project.

The introduced notations provide a coherent and extensible formal foundation for modeling causal interactions within Agile project structures. By systematically defining activity types, hierarchy levels, management roles, interaction flows, and complexity indicators, the causal Agile framework enables precise characterization of both vertical and horizontal dependencies. This formalization not only reinforces semantic clarity and traceability across all levels of Agile activity but also supports the development of robust evaluation mechanisms for project progression, organizational alignment, and strategic coherence.

2.5. Relativity of Role Assignment in Agile Activities

In the causal Agile process hierarchy, all activities are conceptualized as management transactions (MTs), formally defined as MT(F, P, A, V). Within this structure, any activity X at level q assumes the role of the management function F, while an adjacent lower-level activity Z acquires the role of process P, resulting in the transaction MTq(F(X), P(Z), A, V). When transitioning to the next lower-level q′, the role of activity Z changes: Z now serves as the management function F* relative to an even lower-level activity Y, which assumes the role of process P*. This is represented as transaction MT*q′ (F*(Z), P*(Y), A*, V*). This recursive modeling approach demonstrates that every activity, regardless of its level, can be viewed both as a manager and as a process depending on the perspective. The same activity can thus occupy the role of F in one transaction and the role of P in another.

The principle of activity role relativity states that within the causal Agile hierarchy, all activity types are modeled as management transactions (MTs). Through hierarchical decomposition, an individual activity may serve different roles depending on its contextual position. Specifically, an activity may act as the management function F within one transaction, typically at a higher level, and as the process P within another transaction at a lower level. That is, the same activity can occupy the role of F in an upper-level MT and the role of P in a subsequent lower-level MT′.

This role assignment is inherently perspective-dependent: whether an activity is designated as a function or a process within a given MT is relative to its structural position in the hierarchy and the level of abstraction applied. The same principle applies to horizontal interactions within a single Agile level, where roles are similarly relative and shaped by the modeling focus. Consequently, the role of an Agile activity in the MT hierarchy is not absolute but relational, emerging from the recursive structure of management transactions that defines the causal Agile process.

The causal Agile process hierarchy is inherently a recursive structure of overlapping management transactions, as illustrated in Figure 4. At each level of the hierarchy, an activity is modeled as a management transaction MT, formally defined as MT(F, P, A, V). Suppose an activity j at level q is specified as a transaction MTq, where activity j fulfills the role of the management function F, and a lower-level activity i fulfills the role of the process P, resulting in MTq(Fj, Pi, A, V). In the subsequent step at a lower design level q*, where q^* < q, the same activity i is reconceptualized as a self-contained management transaction MTq*. Activity i now assumes the role of management function Fi, overseeing an adjacent lower-level activity n in the role of process Pn, leading to MTq*(Fi, Pn, A*, V*).

In this way, decomposing transactions from higher to lower levels induces a recursive structure. The activity originally modeled as a process Pi at level q transforms into a management function Fi in a new transaction at level q* (see Figure 4). This recursive behavior characterizes the causal Agile hierarchy as a dynamic network of interlinked and reinterpreted MTs.

It is also important to note that a higher-level activity typically interacts not with a single lower-level activity, but with a set of them. Based on empirical analysis results (see Table 1), the number of lower-level activities associated with a higher-level transaction typically ranges from one (KN Th:I) to twenty, depending on the type and granularity of the activity—whether it is a theme, initiative, or epic.

For example, the relative roles of activities involved in the interaction between an initiative and an epic are illustrated in Figure 5. At the initiative level, an initiative I is represented as a management transaction MT(I,E) = (F, P, A, V), where the initiative I assumes the role of management function F, and the epic E acquires the role of process P.

The feedback loop between initiative and epic includes flow A, which transmits state attributes from epic E to initiative I, reflecting the process state, and flow V, which conveys control instructions from initiative I to epic E, expressing requirements and managerial influence. The content of control flow V may target any element of the epic-level transaction MT(E,U) = (F*, P*, A*, V*), or a combination of these elements, depending on the scope of influence intended by the initiative.

At the epic level, epic E itself becomes the management function F* relative to a lower-level user story U, which assumes the role of process P*, producing the transaction: MT(E, U) = (F*(E), P*(U), A*, V*). Here, the feedback loop between epic and user story includes flow A*, which transmits the state attributes of user story U upward to epic E, and flow V*, which carries control signals from epic E that influence the development and execution of user story U.

In the same manner, relative role assignments apply to MT elements (i.e., activities) across other levels of the causal Agile hierarchy. In the next section, we analyze the content and structure of vertical and horizontal interactions among activities defined as MTs within the causal Agile model.

3. Definition of the Causal Agile Management Model

A valid causal model must reflect the structural and causal complexity of the phenomenon it represents. Excessive simplification increases the risk of omitting essential attributes and obscuring causal relationships. To address this concern, we present a formal definition of the causal Agile management process, which is a flexible and structurally rigorous framework that captures both vertical and horizontal interactions among Agile activity types. This model helps to identify the content of such interactions and explore theoretically valid content variants.

We formally define the causal Agile management model by first introducing its foundational structural elements. These include activity types, hierarchical levels, role assignments, and interaction flows. Building on this foundation, we then elaborate the causal Agile management process itself, which articulates the content of information exchanges between activity types and identifies the range of theoretically valid interaction scenarios. This complex model is presented below in successive Definition Sections A–F.

A. 

Definition of a causal management activity

-

From the causal modeling point of view, each individual activity is conceptualized as a management transaction MT (a knowledge unit with a predefined internal structure): MT = (F, P, A, V), where F represents the management function, P denotes the process, flow A is the state attributes set A = {A₁, A₂, …, An} transmitted through flow A, and V = {V₁, V₂, …, Vm} is the management control set transmitted through flow V.

-

Each Agile activity is further characterized by its assignment to a specific type of enterprise management function r (r ∈ R), and its location within a defined level q (q ∈ Q) of the Agile hierarchy. This yields a level-specific formulation of the management transaction: MTq = (r, F, P, A, V).

-

A causal Agile activity n is defined as a management transaction MT, as shown in (1), when a vertical interaction with a lower-level activity m is identified:

MTq(r, Ψqn, Ψq′m) = (r, F(Ψqn), P(Ψq′m), Am, Vn);

(1)

where Am ∈ A, Vn ∈ V.

-

A causal Agile activity n is defined as a management transaction MTq, as shown in (2), when vertical (internal) interactions with multiple lower-level activities are identified:

MTq(r, Ψqn, Ψq′) = MTq{(r, F(Ψqn), P(Ψq′1), A1, V₁), (r, F(Ψqn), P(Ψq′2), A2, V2), …,
(r, F(Ψqn), P(Ψq′m), An, Vn)}

(2)

where

-

q—Agile hierarchy level (q ∈ Q).

-

r—enterprise management function type (r ∈ R).

-

Ψq—a set of activities of the same type (belongs to the same hierarchy level q).

-

MTq(Ψqn, Ψq′)—agile activity n considered as MT at the level q; Ψqn specifies activity n of type Ψq, which creates an impact on the set of activities at the lower-level q′. For example, MT₁(Th, I)—defines theme Th as a specific MT at level q = 1 having impact to the subset of initiatives (I) at level q = 2.

-

Ψq′ = {P(Ψq′1), …, P(Ψq′m)} denotes a set of activities of type Ψq′ located at the lower hierarchy level q′, each associated with the same activity at the upper-level q, and serving in the role of process P. For example, consider a theme Th defined as management transaction MT₁(Th, I), where q = 1. The corresponding set Ψq′ = {P(I₁), …, P(Im)} represents initiatives at level q′, which are vertically related to the theme Th and function as its subordinate processes P.

Note: In Formula (2), all lower-level activities Ψq′ belong to the same management function r (r ∈ R). In the general case, however, this constraint may not apply. Lower-level activities may be associated with different management functions (such as r, r′, …).

B. 

Content of the horizontal interaction (coordination) at the one hierarchy level

-

A management transaction MT is a knowledge unit with a predefined internal structure: MT = (F, P, A, V), specifying the content of an Agile activity.

-

Any management transaction MT = (F, P, A, V) may interact with another transaction MT′ = (F,′ P′, A′, V′), transmitting information flows that can affect the internal elements of MT′(F′, P′, A′, V′) and receiving reciprocal flow that affects the internal elements (both structure and behavior) of the original MT.

-

The content of the horizontal interaction (coordination) of a causal agile activity MT with other activities of the same hierarchical level is defined as an information flow that references one or more internal elements of another MT′ (F′, P′, A′, V′). This may involve a single element or any combination of them.

-

Let C denote a set of horizontal interaction variants between two activities of the same type Ψq, as shown in the taxonomy of horizontal interactions in Table 5. Let Cn denote a specific horizontal interaction variant, representing the content exchanged between activity Ψqn and another activity Ψqm at the same level q, chosen from among the variants in Table 5.

C. 

Content of the internal vertical interaction of causal Agile activity

-

A management transaction MT = (F, P, A, V) has internal vertical interaction as a feedback loop between F and P.

-

The content of the vertical interaction (management control) within a causal Agile activity MT(F, P, A, V) consists of two directed information flows between elements F and P:

-

The first is flow A, which transmits the state attributes from process P (this assumes that the lower-level activity MT′(F′, P′, A′, V′) is functioning in the role of P).

-

The second is control flow V, which originates from the management function F (the higher-level activity) and directs influence toward process P (the lower-level activity).

-

An important feature of the causal Agile process hierarchy is the recursive nature of its structure. In the causal agile process hierarchy, the internal structure of MT(F, P, A, V) forms a recursive structure, since the element P (i.e., a lower-level activity m) is further decomposed as management transaction MT*(F*, P*, A*, V*) as well (here activity m is in role F*). A description of the recursive property along with an example is presented in Figure 4 and Figure 5.

-

Therefore, due to the recursive property, the content of V includes references to the internal elements (F′, P′, A′, V′) of the lower-level MT′, a reference to one of them, or any combination of them. Let us denote a set W = {W(A), W(V)}, where W(V) serves as a vertical top-down flow (of controls V), and W(A) as bottom-up flow A (state attributes, feedback) (see Figure 4).

We can now define a causal Agile activity at a given hierarchical level, incorporating the assessment of its state at a specific point in time by identifying variations in the content of vertical and horizontal interactions. This includes characterizing changes in the management control flow V and coordination flow A, as detailed in

Table 3. Vertical interaction: control flow V content variants.

Upper Level	Controls: Flow V from MT to MT*	Lower-Level MT*(Z, B) = (F*, P*, A*, V*)
MT(W, Z)	MT(W, Z) Impact Variations to MT*(Z, B)	A*	V*	P*	F*
V1	Notes/controls regarding A* status	x
V2	Notes/controls regarding V* status		x
V3	Notes/controls regarding P* status			x
V4	Notes/controls regarding F* status				x
V5	Notes/controls regarding A* and V* status	x	x
V6	Notes/controls regarding V* and P* status		x	x
V7	Notes/controls regarding P* and F* status			x	x
V8	Notes/controls regarding V* and F* status		x		x
V9	Notes/controls regarding of A* and P*	x		x
V10	Notes/controls regarding A* and F* status	x			x
V11	Notes/controls s regarding V*, P*, and F* status		x	x	x
V12	Notes/controls regarding A*, V*, and F* status	x	x		x
V13	Notes/controls regarding A*, P*, and F* status	x		x	x
V14	Notes/controls regarding A*, V*, and P* status	x	x	x
V15	Notes/controls regarding A*, V*, P*, and F*	x	x	x	x

,

Table 4. Vertical interaction: feedback flow A (state attributes) content.

Upper Level	Flow A from MT* to Upper-Level MT	Lower-Level MT*(Z, B) = (F*, P*, A*, V*)
MT(W, Z)	Feedback Flow A Content Variations	A*	V*	P*	F*
A1	Flow A* status notification	x
A2	Flow V* status notification		x
A3	Notification regarding P* status			x
A4	Notification regarding F* status				x
A5	Notification of A* and V* status	x	x
A6	Notification of V* and P* status		x	x
A7	Notification of P* and F* status			x	x
A8	Notification of V* and F* status		x		x
A9	Notification of A* and P* status	x		x
A10	Notification of A* and F* status	x			x
A11	Notification of V*, P*, and F* status		x	x	x
A12	Notification of A*, V*, and F* status	x	x		x
A13	Notification of A*, P*, and F* status	x		x	x
A14	Notification of A*, V*, and P* status	x	x	x
A15	Notification of A*, V*, P*, and F* status	x	x	x	x

and

Table 5. Taxonomy of control flow V content in the horizontal interaction performed as MT.

Activity MT(X, X*)	Control Flow V from MT to MT*	Coordinated Activity MT*(X*, W) = (F*, P*, A*, V*)
Content of V	Impact of Activity X to X*	A*	V*	P*	F*
C1	Controls regarding A*	x
C2	Controls regarding V*		x
C3	Controls regarding P*			x
C4	Controls regarding F*				x
C5	Controls regarding A* and V*	x	x
C6	Controls regarding V* and P*		x	x
C7	Controls regarding P* and F*			x	x
C8	Controls regarding V* and F*		x		x
C9	Controls regarding A* and P*	x		x
C10	Controls regarding A* and F*	x			x
C11	Controls regarding V*, P*, and F*		x	x	x
C12	Controls regarding A*, V*, and F*	x	x		x
C13	Controls regarding A*, P*, and F*	x		x	x
C14	Controls regarding A*, V*, and P*	x	x	x
C15	Controls regarding A*, V*, P*, and F*	x	x	x	x

.

D. 

Definition of a causal Agile activity n: identification of all possible interactions

-

Vertical (internal) interactions with lower-level activities (as defined in Definition A) and horizontal interactions with other same-level q activities (as defined in Definition B) are jointly represented as follows:

MTq(r, Ψqn, Ψq′, Cn, Wn) = MTq{(r, F(Ψqn), P(Ψq′1), A1, V1, Cnm, Wn),
(r, F(Ψqn), P(Ψq′2), A2, V2, Cnm, Wn), …, (r, F(Ψqn), P(Ψq′m), An, Vn, Cnm, Wn)}

(3)

where

-

Ψq′ = { Ψq′1, Ψq′2, …, Ψq′m}—a set of lower-level activities vertically related to the higher-level activity n; each is modeled as an individual management transaction (MT).

-

C(H)—a reference set of interaction content pairs {(Ci, Aj)} combining coordination variants (C1–C15), presented in Table 5, and state attribute variants (A1–A15), presented in Table 4.

-

Cnm—a specific content variant (Ci, Aj) of horizontal interaction between activity n and another same-level activity m, assessed at a specific point in time.

-

Cn—the set of horizontal content variants {(Ci, Aj)} of horizontal interaction of activity n with a set of related activities at the same level q at certain point in time, between activity n and all related same-level activities at time t.

-

W = {(A,V)}—the set of vertical interaction content variants within MTq, as defined in Table 3 and Table 4.

-

Wn = {Ai,Vj}—the specific vertical interaction content variant within MTq for activity n, assessed at a defined point in time.

E. 

Definition of the recursive property of the causal Agile management model

-

The causal Agile management model, spanning all levels of the Agile hierarchy (q ∈ Q), is structured as a hierarchy of activity types {Ψq}, each represented as a management transaction (MT). A key feature of this model is its recursive property, defined as follows:

MTq(r,{Ψq}, {Ψq′}, A, V, C, W) = {(MTq(r, F(Ψqn), P(Ψq′) = (P(Ψq1), … P(Ψq′m), …), An, Vn, C, W) & (MT*q′(r, F*(P(Ψq)), P*(Ψk), A*, V*, C, W)},

(4)

where

-

q and q′—Agile hierarchy levels (q ∈ Q, q′ ∈ Q), such that q > q′.

-

MTq(r,{Ψq}, {Ψq′}, A, V, C, W)—a causal Agile activity hierarchy model in which activities are defined as management transactions, with content assessments at a specific point in time.

-

r—enterprise management function type, r ∈ R.

-

{Ψq}—set of activities of the same type located at level q.

-

{Ψq′}—set of lower-level activities associated with a higher-level activity n, functioning in the role of P.

-

F(Ψqn)—activity n in the role of management function F at level q in the transaction MTq(r, F(Ψqn), P(Ψq′)).

-

P(Ψq′)—set of lower-level activities, acting as processes P, and related to the same higher-level activity n (e.g., related to F(Ψqn)).

-

MT*q′(r, F*(P(Ψq′)), P*(Ψk), A*,V*, C, W)—a recursive structure enabling top-down decomposition, in which each lower-level activity P(Ψq′) is further defined as management transaction MT*q′(F*,P*,A*,V*), now playing the role of F*.

-

F*(P(Ψq′m))—activity P(Ψq′m) reinterpreted in the role F at level q′ as part of the recursive MT*q′ definition.

For example, in the Scrum-based Agile management framework, the project is structured across four hierarchy levels: themes, initiatives, epics, and stories (TIES). The activities at each level q ∈ Q are described individually using Formula (1) to reflect their respective structural roles and semantics. The entire Agile project is therefore modeled by a system of formal expressions as represented in Formula (2), where each hierarchy level q is specified separately, recognizing the differentiated semantics assigned to activity types at each level.

F. 

Definition of a causal Agile management hierarchy in the Process Space

Considering TIES elements (theme, initiative, epic, user story) as self-managed activities (MTs), the internal content of the hierarchy elements could be specified properly—normalized using the definition of MT = (F, P, A, V). To further formalize the interactions between Agile management activities modeled as MTs, we utilize an abstract construct referred to as the Process Space (see Figure 6), previously introduced in [3,28,39]. The Process Space is defined as a three-dimensional abstract space PS = (AG, GE, T), where the following apply:

-

AG is the aggregation axis, representing the hierarchy of material objects or entities;

-

GE is the generalization axis, representing the hierarchy of informational abstractions;

-

T is the time axis, denoting the chronological sequence of activity occurrence.

This concept enables a formal and structured representation of the causal Agile process model. The abstract Process Space PS = (AG, GE, T) provides a framework to formalize interactions across the Agile hierarchy (Figure 3), classify them systematically, identify theoretically valid combinations of vertical and horizontal interactions (transmitted content variants), and introduce quantitative indicators for assessing Agile process complexity and project status. A general abstract case of interaction between two activities, MT and MT′, is depicted in Figure 6.

Agile activities are represented as black-box nodes (dots), such as MT(i, j, t, r, p) and MT′ (i′, j′, t′, r′, p′). Each activity follows the internal structure MT = (F, P, A, V), though this structure is not shown in the visualization—allowing easier comparison with the current Agile methodology. These activities differ across one or more Process Space dimensions:

-

Aggregation hierarchy, i ≠ i′;

-

Generalization hierarchy, j ≠ j′

-

Time period, t ≠ t′;

-

Enterprise management function, r ≠ r′;

-

Process identity, p ≠ p′.

The fundamental cases of mutual arrangement between two Agile activities MT and MT′ in the Process Space PS = (AG, GE, T) can be characterized by the values of the following indices:

-

Aggregation axis level is the same (i = i′);

-

Aggregation axis level is different (i ≠ i′);

-

Generalization axis level is the same (j = j′);

-

Generalization axis level is different (j ≠ j′);

-

Management function type is the same (r = r′);

-

Management function types differ (r ≠ r′);

-

The same process P is handled by both activities MT and MT′ (p = p′);

-

Different processes P are handled by activities MT and MT′ (p ≠ p′);

-

The processes managed by activities MT and MT′ occur within the same time period (t = t′);

-

The processes managed by activities MT and MT′ occur in different time periods (t ≠ t′).

3.1. Vertical Interaction Content Variants

Vertical interaction refers to the directional exchange between two levels of the Agile hierarchy, in which the upper-level activity MT′(F′, P′, A′, V′) transmits a vertical flow V′ (representing impact or control) to the lower-level activity MT(F, P, A, V), and subsequently receives feedback flow A, describing the state characteristics of process P [2]. A single vertical flow V′ may carry information that asserts the influence of the higher-level transaction MT′(F′, P′, A′, V′) on one or more internal components of the lower-level activity MT(F, P, A, V). This dependency reflects the recursive property embedded in the causal structure of the Agile model.

The example presented in Figure 7 shows the vertical interaction between initiative (I) and epic (E) [2]. Here, initiative (I) is defined as MT′(I, E), and epic (E) is defined as MT(E, U); both are represented as white boxes:

-

The upper-level activity initiative (I) is defined as MT′(I, E) = MT′ (F′, P′, A′, V′) and is located at the point (i′, j′, t′, r′, p′) in the Process Space. In this context, the initiative (I) is in the role of function F, while epic (E) is under the control of F and assumes the role of process P (i.e., the epic is considered a process in this vertical relationship);

-

Epic (E) is also defined as MT(E, S) = MT(F, P, A, V), situated at aggregation level I and identified as the point (i, j, t, r, p) in the Process Space. Here, epic (E) takes on the role of function F, managing a lower-level activity, user story (S), which acts as process P under the epic’s control.

Thus, in this example, initiative I = MT′(F′, P′, A′, V′) and epic E = MT(F, P, A, V) are located at different levels of the aggregation hierarchy AG (i ≠ i′), and at different levels of the generalization hierarchy GE (j ≠ j′); they operate in different time periods (t ≠ t′) and govern different processes (p ≠ p′).

The semantics of vertical interaction depend on the content of the transmitted flows A and V between two activities belonging to adjacent levels of the Agile hierarchy. In the causal Agile model, such interaction is formally treated as a management transaction (MT). Variations in vertical interactions, defined by the semantic content of the vertical flow between an upper-level activity W and a lower-level activity Z are specified in Table 3 and Table 4.

Table 3 presents a taxonomy of the content of the control flow V originating from the upper-level activity W. This flow conveys instructions or directives to the lower-level activity Z, indicating required changes to one or more of its internal elements (F*, P*, A*, V*). Table 4 provides the taxonomy of the feedback flow A originating from the lower-level activity Z, reporting the current status of its internal elements (F*, P*, A*, V*) back to the upper-level controller. The combined taxonomy of vertical interactions, as described in Table 3 and Table 4, represents a formal specification that applies uniformly across all levels of the Agile hierarchy, encompassing the following management transactions: MT(theme, initiative), MT(initiative, epic), MT(epic, user story).

Examples of the content variants in the control flow V, transmitted from the theme level to the initiative level, include the following: V1, which specifies requirements for the state attributes A* of the activity MT(I, E); V2, which contains requirements for the controls V*; V3, representing the impact of MT(I, E) on the rules governing execution of the process P*; V4, which includes requirements for the management function F* of MT(I, E), such as modifications to internal management logic or rule sets; variants V5–V15 represent compound combinations derived from the fundamental flows V1–V4.

The taxonomy of content variants for vertical interactions within a management transaction MT is represented as a set of pairs (Ai, Vj), combining content variants A1–A15 from the attribute state flow A with content variants V1–V15 from the control flow V. Formally, the set is expressed as W = {(A1, V1), (A1, V2), …, (A15, V14), (A15, V15)}.

3.2. Example of Vertical Interactions in a Causal Agile Process Hierarchy

Figure 8 presents an illustration of vertical interaction within a causal Agile process hierarchy, where epic (E) plays the role of management function F and controls a set of user stories S = {S1, …, Sk, …, Sn, …, Sz}. Each individual interaction between epic E and a corresponding user story is modeled as a management transaction {MT(E, S1), …, MT(E, Sk), …, MT(E, Sn), …, MT(E, Sz)}. All user stories from the set {S} play the role of process P within each transaction—that is, all user stories in the set are managed under the control of the same epic E. The vertical interaction within each MT instance reflects the flow of management control, while any horizontal interaction among user stories at the same level is referred to as coordination.

Let us provide examples of vertical flow content that are applied in practice to describe epic and user story interaction, which is defined as MT(E, S) = MT(F(E), P(S), A, V) in Figure 8. The state flow A = {A₁, A₂, A₃} can be defined, where the following apply:

-

The status of user story S at a moment in time is defined by flow A content A1 = {a1.1 = “To do”, a1.2 = “In progress”, a1.3 = “In review”, a1.4 = “In testing”, a1.5 = “Ready for deployment”, a1.6 = “Done”, a1.7 = “Cancelled”};

-

The user story S, assigned responsible person (assignee), defined by flow A content A2 = {a2.1 = “The same”; a2.2 = “Changed”};

-

The time spent working on the user story is defined by flow A content A3 = {a3.1 = “Within allocated time limit”, a3.2 = “Close to allocated time limit”, a3.3 = “Over allocated time limit”}.

The status of the controls flow V = {V1, V2, V3} at a moment in time can be described as follows.

-

Optimal/expected duration of user story completion V1, based on team velocity and progress of the user story, indicates whether the story is expected to be completed within a defined time frame:

V1 = {v1.1 = “User story fits within expected time frame”, v1.2 = “User story does not fit within expected time frame”};

-

The total remaining time to complete all user stories is reflected in V2, representing the initial epic estimate based on activity velocity when a new user story is added: V2 = {v2.1 = “Added user story fits into originally estimated time”, v2.2 = “Added user story does not fit into originally estimated time”}.

3.3. Horizontal Interactions in the Causal Agile Hierarchy Model

Horizontal interaction in the Agile hierarchy occurs between activities at the same level of the aggregation hierarchy AG; this type of interaction is referred to as coordination (Figure 9). There are two distinct coordination options:

-

Between activities belonging to the same type of enterprise management function r (r ∈ R);

-

Between activities associated with different types of enterprise management function (r ∈ R and r* ∈ R).

Additionally, horizontal interaction can be modeled from two different perspectives:

-

Horizontal interaction is considered as a management transaction (MT);

-

Horizontal interaction is considered as a message transmission (or choreography, in terms of BPMN).

A theoretically more interesting case in examining causality is when horizontal interaction is analyzed and executed as a management transaction MT [2]. The mutual communication (coordination) between activities X and X* in this context is defined as a management transaction MT(X, X*) and is illustrated in Figure 9.

In the horizontal interaction between two activities X and X*, considered as a management transaction, it is necessary to agree on which activity is the leader. Let us assume that the leading activity is X, which takes on the role of function F in the transaction MT(X, X*), while the activity X* assumes the role of process P. It should be noted that both X and X* are also independently defined as management transactions: MT(X, Z) and MT(X*, W), where Z and W are the lower-level Agile activities. Each of these transactions contains internal vertical interactions.

In a horizontal interaction between two activities, X and X*, viewed as the management transaction MT(X, X*), one activity must serve as the leader. Let X assume the leader’s role, i.e., the function F, and X* assume the process role P.

Both X and X* also participate in their own vertical transactions, MT(X, Z) and MT(X*, W), respectively, where Z and W are lower-level Agile activities. Each of these transactions encompasses its own internal vertical interactions.

Formally, the structure of a horizontal interaction mirrors that of the vertical interaction discussed in Section 3.1, with “coordination” semantics replacing “management control.” The content variants of flow A remain identical to those in Table 4, while the coding of control-flow variants V is modified to distinguish horizontal interactions from their vertical counterparts (see Table 5).

Examples of the impact V from activity X to the activity X* include the following: the content of C1 defines requirements for the state attributes A* of MT*(X*, W); the content of C2 specifies requirements for the controls V* of MT*(X*,W); the content of C3 reflects impact on the process execution rules P* within MT*(X*, W); V4 includes requirements to the management function F* (impact to management logic, rules) of MT*(X*,W); content variants C5–C15 represent combinations of C1–C4.

The taxonomy of content variants for horizontal interactions performed as management transactions MTs is represented as a set of pairs (Ai, Cj), where each pair combines a content variant C1 through C15 of the control flow V, with content variants A1 through A15 of the attribute state flow A. This set is formally expressed as C(H) = {(A1, C1), (A1, C2), …, (A15, C14), (A15, C15)}.

4. Project Complexity Assessment Indicators

4.1. Assessment of Vertical Project Complexity Based on Interaction Content

The principles for assessing project complexity quantitatively are grounded in the taxonomy of vertical interaction content presented in Table 3 and Table 4, which apply to the four-tiered TIES hierarchy: theme, initiative, epic, and user story. Vertical interactions in the causal TIES hierarchy are categorized into four types, each representing a specific management transaction MT: MT(Th,I) = MT(theme/initiative), MT(I,E) = MT(initiative/epic), MT(E,S) = MT(epic/user story) and MT(S,X) = MT(user story/optional lower-level activity).

First, the levels of the Agile hierarchy have clearly defined semantics, containing a fixed type of project activity with its own terminology (business language, professional language), different entities exist, and their names are different. The vertical interaction cases (with different semantics) between one upper-level activity and one lower-level activity inside the single management transaction MT(F, P, A,V) are as follows: top-down—15 (V1–V15, Table 3); bottom-up—15 (A1–A15, Table 4). The possible variants of interaction content inside the single management transaction MT(F, P, A,V) includes the combinations of all the V and A content variants: {(V1, A1), (V1, A2), …., (V15, A14), (V15, A15)}.

-

Thus, the total number of internal interaction types within any MT is 15 × 15 = 225. These quantitative estimates are valid at all hierarchy levels for all types of management transactions MT(Th,I), MT(I,E), MT(E,S), and MT(S,X).

-

Because TIES levels have different real-world semantics, formally defined vertical interactions in the causal hierarchy of Agile activities create a total of 4 × 225 = 900 content variants.

Second, there are usually not one, but several lower-level Agile activities that belong to one higher-level activity, so this is taken into account when calculating the complexity indicators of the entire project. Thus, the number of possible vertical interactions (with different semantics) increases accordingly. We will use the expert data on the project scope presented in Table 1, which is a typical composition of medium-sized Agile projects, indicating the number of objects (activities) at the levels of the hierarchy. We calculate the formally possible number of combinations of content transmitted between the theme and initiative levels.

-

At the theme level, the number of different themes (Th) is from 1 to 5 (per project) and the number of initiatives (I) is between 1 and 15; thus, one theme can have from 1 to 5 initiatives. Therefore, the number of combinations of content transmitted between the theme and initiative levels is as follows: minimum 1Th × 1I × 225 = 225, intermediate 1Th × 5I × 225 = 1125, maximum 5Th × 5I × 225 = 5625.

-

At the initiative level, the number of initiatives (I) is between 1 and 15, and one initiative can have about 10 epics. Therefore, the number of content variants transmitted between the initiative and epic levels is as follows: minimum 1I × 10E × 225 = 2250, maximum 15I × 10E × 225 = 33,750.

-

At the epic level, the number of epics (E) is 150 or more; one epic can have about 20 user stories (S). Therefore, the number of content combinations transmitted between epics and user story levels is as follows: minimum 1I × 10E × 20S × 225 = 45,000, maximum 5I × 10E × 20S × 225 = 225,000.

In this way, we obtained estimates of theoretically possible vertical interactions exhibiting different semantic characteristics within a single Agile project, based on the expert data presented in Table 1. These estimates provide a foundation for the quantitative evaluation of project complexity, enabling the introduction of complexity indicators tailored to specific project situations.

4.2. Project Vertical Complexity Indicator

Assumption (vertical interaction). Each element of upper-level activity MT(F, P, A, V) can send a control flow V directed to one or more elements (F*, P*, A*, V*) of lower-level activity MT*(F*, P*, A*, V*) and obtain feedback flow A, associated with the state of one or more elements (F*, P*, A*, V*) of MT*.

The vertical interaction taxonomy in Table 3 and Table 4 reveals variants of interaction content between the higher-level Agile activity type and the related adjacent lower-level activity type. The number of variants (A1–A15) of flow A and variants (V1–V15) of flow V with different content is 15 in both cases. The total number of variants of the content transmitted within MT is a set of pairs (Ai, Vj)—combinations of content variants of attribute state flow A and control flow V: W = {(A1, V1), (A1, V2), …, (A15, V14), (A15, V15)}—and is 15 × 15 = 225.

The horizontal complexity indicator Q1 is calculated for each hierarchy level separately as the number of vertical interactions of different content between different activity types (at different hierarchy levels).

Vertical complexity indicator Q1 is a set that includes MT complexity indicators at each level of hierarchy:

Q1 = (Q1(Th,I), Q1(I,E), Q1(E,S), Q1(S,X))

(5)

There are three types of vertical complexity indicator Q1:

-

Q1T—theoretical (typical, normative), based on a formal definition of causal processes and assessing the normative (typical) number of project objects;

-

Q1P—Q1 of a specific project, calculated based on the current composition and state of the project;

-

Q1N—the normalized “relative” complexity indicator of the project, as the ratio of the project complexity Q1P and the theoretically calculated complexity Q1T, showing the difference between the state of a specific project and the typical (normative).

Theoretical values of the project vertical complexity Q1T for TIES levels have already been calculated in the section above and presented in

Table 6. Vertical complexity indicator Q1.

Agile Hierarchy Level	Number of Objects	Theoretical Q1T	Project Q1P	Normalized Q1N = Q1P/Q1T
Theme (Th) level
MT (Th, I) [1Th × 1I]	1	225	Q1P(Th)	Q1N(Th)
MT (Th, I) [1Th × 5I]	1	1125
MT (Th, I) [5Th × 5I]	5	5625
Initiative (I) level
MT(I, E) [1I × 10E]	1	2250	Q1P(I)	Q1N(I)
MT(I, E) [5I × 10E]	5	11,250
MT(I, E) [15I × 10E]	15	33,750
Epics (E) level [per initiative]
MT(E, S) [1I × 10E × 20S]	10	45,000	Q1P(E)	Q1N(E)
MT(E, S) [5I × 10E × 20S]	20	225,000

. They are calculated using characteristics of a typical medium-sized project, see Table 1. In practice, a typical EAS development project has the following number of objects at individual levels (Table 1): 1–5 themes, where 1 theme corresponds to some strategic objective; 1–5 initiatives for the theme; 10 epics per initiative; and about 20 user stories per epic.

Based on the vertical interaction characteristics described above, let us conduct an evaluation of the complexity of a specific project. Here is a small example of calculating the project Q1P and normalized Q1N = Q1P/Q1T. Let us assume that a specific EAS project is being implemented with 1 theme; 1 initiative; 8 epics per initiative; and 120 user stories (15 user stories per epic):

-

At the theme level, there is one theme and vertical interaction with one initiative: Q1P(Th) = 225.

-

At the initiative (I) level, there is one initiative and the vertical interaction of this initiative with eight epics: Q1P(I) = 8 × 225 = 1800.

-

At the epic level, there are 8 epics and 120 user stories (15 user stories per epic), so the total number of vertical interactions (of content combinations between epics and user story levels) in the project is Q1P(E) = 10E × 15S × 225 = 33,750.

We conclude that the complexity of vertical interactions of this project, compared to the complexity of a theoretical (typical) project Q1T, is evaluated as follows:

-

At the theme level, Q1P(Th) = 225 is equal to Q1T(Th), and vertical complexity coincides;

-

At the initiative level, the vertical complexity Q1P(I) = 1800 of the project is less than typical (Q1T(I) = 2250);

-

At the epic level, the vertical complexity Q1P(E) = 33,750 of the project is less than typical (Q1T(E) = 45,000).

Let us set the values of normalized Q1N = Q1P/Q1T of vertical interactions of this project:

-

At the theme level, Q1N (Th) = Q1P(Th)/Q1T(Th) = 225/225 = 1;

-

At the initiative level, Q1N(I) = Q1P(I)/Q1T(I) = 1800/2250 = 0.8;

-

At the epic level, Q1N(E) = Q1P(E)/Q1T(E) = 33,750/45,000 = 0.75.

We conclude that the complexity of the vertical interactions of this project is not much different from the complexity of a theoretical (typical) project Q1T, since at the theme level they overlap, at the initiative level they constitute 80%, and at the epic level they constitute 75% of the typical complexity.

4.3. Project Vertical Completion Status Assessment

We introduce two additional vertical complexity indicators, designed to assess the specification status of vertical interactions within a given Agile project:

-

Project vertical specification scope status indicator, Q1PS;

-

Vertical interaction (management control) content status indicator, Q1PC.

Project vertical specification scope status can be assessed based on the proportion of vertical interactions that are described in the database. The status of the vertical specification scope of a project indicator Q1PS can be indicated by the vertical interaction specification ratio, i.e., the ratio of the number of already specified vertical interactions to the number of theoretically required (at each hierarchy level separately):

Q1PS = (Q1PS(Th), Q1PS(I), Q1PS(E), Q1PS(S)),

(6)

The vertical interaction content status Q1PC of any MTq(Ψqn, Ψq′) is identified as a pair of content variants (Ai,Vj) of flow and V flow A from Table 3 and Table 4: {(A1,V1), (A2,V2), …, (A14,V14), (A15,V15)}, a total of 225 variants. The vertical interaction content status indicator Q1PC is identified as a pair of flow and V flow A content variants (Ai,Vj) from classifications in Table 3 and Table 4 (for TIES hierarchy):

Q1PC = (Q1PC(Th,I), Q1PC(I,E), Q1PC(E,S), Q1PC(S,X)),

(7)

where

-

Q1PC(Th,I) = {(MT(Th,I),(Ai,Vj))}—specified MT(Th,I) vertical interaction content at the theme level;

-

Q1PC(I,E) = {MT(I,E),(Ai,Vj)}—specified MT(I,E) vertical interaction content at the initiative level;

-

Q1PC(E,S) = {MT(E,S),(Ai,Vj))}—specified MT(E,S) vertical interaction content at the epic level;

-

Q1PC(S,X) = {MT(S, X)(Ai,Vj))}—specified MT(E,S vertical interaction content at the user story level.

For example, vertical interaction content status (A1,V2) = (A1 = (A* defined, V* not defined, P* not defined, F* not defined), C2 = (A* not defined, V* defined, P* not defined, F* not defined), and content status (A14, V13) = (A14 = (A* defined, V* defined, P* defined, F* not defined), V13 = (A* defined, V* not defined, P* defined, F* defined). Such assessments provide valuable information for project management staff, enabling the identification of gaps in project implementation and supporting the planning of corrective or refinement activities.

To determine the vertical interaction content status Q1PC, the model evaluates all MT components and generates a list of identified element-state combinations. This form of analysis is feasible only within an Agile software environment adapted to apply this modeling method. In the subsequent step, a dedicated user interface (dashboard) can be generated for the Agile project team, presenting summarized results and generating reports that align with specific project management objectives.

4.4. Assessment of Horizontal Complexity of a Project Based on Interaction Content

Assumption (horizontal interaction on the level q). When horizontal interaction is implemented as an MT, the coordinating activity MTq (F, P, A, V) can send a coordination message to each element (F*, P*, A*, V*) of another MT*q (F*, P*, A*, V*) or any combination of elements and receive feedback on the status of any combination of elements (F*, P*, A*, V*) of the coordinated activity MT*q.

When the horizontal interaction between activities X and X* is implemented as MT(X, X*), the content variants of the control flow V (coordination message) are listed in Table 5, where coordinating activity X is defined as MT(X, X*) and interacts with coordinated activity X* defined as MT*(X*, W). As can be seen from the coordination content variants presented in Table 5, there are 15 control flow V variants with different semantics at the same TIES level. The content variants of feedback flow A in the MT(X, X*) are the same as those listed in Table 4. As can be seen, the number of variants of flow A with different semantics between two activities at the same TIES level is 15.

Thus, the total number of horizontal interactions (coordination instances with different semantics) inside one MT(X, X*) is the combination of all instances of flows A and V: {(V1, A1), (V1, A2), …., (V15, A14), (V15, A15)}; the number of them is 15 × 15 = 225. In practice, the number of horizontal interactions at a specific level of the Agile hierarchy is determined by the number of active objects, as indicated in Table 1. At the theme level, for example:

-

A typical project may involve up to five distinct themes.

-

Assuming a coordination scenario in which one theme assumes the role of leader while the other four are coordinated, the number of theoretically possible coordination variants can be calculated as 4 × 225 = 900.

At the initiative level, the number of distinct initiative objects typically ranges from 5 to 15 per project. Assuming that one initiative serves as the leader and the remaining initiatives are positioned in a coordinated role, the number of theoretically possible horizontal coordination variants ranges as follows:

-

Minimum 4 × 225 = 900,

-

Maximum 14 × 225 = 3150.

Note: We do not model coordination interactions as management transactions (MTs) at the lower levels of the Agile hierarchy, such as epics and user stories, based on the assumption that coordination-related problems are resolved at the initiative level. In simpler cases, coordination may take the form of message transfer between activities, consistent with choreography in BPMN terms. This involves a directive (instruction) sent from one activity to another, optionally followed by a response message.

4.5. Project Horizontal Complexity Indicator

The horizontal complexity indicator Q2 of the project is determined separately for each level of the Agile hierarchy. It is defined as the number of horizontal interactions exhibiting distinct content types between activities operating at the same level. The overall project horizontal complexity is represented as a vector of level-specific indicators:

Q2 = (Q2(Th), Q2(I), Q2(E), Q2(S))

(8)

Similarly to the vertical complexity indicators, three types of horizontal complexity indicator Q2 are defined:

-

Q2T—the theoretical (typical, normative) horizontal complexity indicator, based on a formal definition of causal processes and assessing the normative (typical) number of project objects;

-

Q2P—the project-specific horizontal complexity indicator, calculated according to the actual composition and current state of activities in the specific Agile project;

-

Q2N—the normalized “relative” complexity indicator of the project, defined as the ratio of the project complexity Q2P and the theoretically calculated complexity Q2T, indicating the deviation of a specific project status from the typical or expected normative model.

The theoretical values of the project horizontal complexity indicator Q2T across the TIES hierarchy levels have already been calculated and are presented in

Table 7. Horizontal complexity indicator Q2.

Agile Hierarchy Level	Number of Objects	Theoretical Q2T	Project Q2P	Normalized Q2N = Q2P/Q2T
Coordination as MT
Theme (Th)	1	0	Q2P(Th)	Q2N(Th)
	2	225
	5	900
Initiative (I)	1	0	Q2P(I)	Q2N(I)
	5	900
	15	3150
Messaging
Epics (E) per initiative	10	45	Q2P(E)	Q2N(E)
	20	190
User stories (S) per epic	10	45	Q2P(S)	Q2N(S)
	15	105
	20	190

. They are calculated using characteristics of a typical medium-sized project (see Table 1).

Horizontal complexity indicators Q2P values for a specific project for TIES levels are calculated knowing the structure of the project, i.e., the number of objects at the TIES levels. The normalized horizontal complexity of a project Q2N = Q2P/Q2T is calculated as the ratio of the actual project complexity Q2P to the theoretically possible interaction estimate Q2T for the selected agile project size (or type).

For example, a typical EAS development project has 1 theme; 1 initiative for the theme; 10 epics per initiative; and 200 user stories (20 user stories per epic). In this case we have only one theme and one initiative; therefore, there are no horizontal interactions at these two Agile hierarchy levels: Q2P(Th) = 0, Q2P(I) = 0.

Let us assume that at the epic level, coordination is performed as a message passing (choreography in BPMN terms): communication between 10 epics includes 45 mutual interactions (the number of k-combinations from a given set S of n elements C(n,k), e.g., C(10,2) = 45C(n,k)). Alignment of 20 epics includes 190 mutual interactions (C(20,2) = 190).

Coordination interactions between user stories are calculated in the same way: alignment of 10 user stories involves 45 interactions and alignment of 20 user stories involves 190 interactions. The horizontal complexity indicator Q2T obtained in this way for a typical EAS project is Q2T = (Q2T(Th) = 0; Q2T(I) = 0; Q2T(E) = 45; Q2T(S) = 190)).

Here is a small example. Let us assume that a specific EAS project is being implemented: 1 theme; 1 initiative; 8 epics per initiative; and 120 user stories (15 user stories per epic). In this case we have only one theme and one initiative; therefore, there are no horizontal interactions at these two Agile hierarchy levels: Q2P(Th) = 0, Q2P(I) = 0.

The epics level coordination is performed as a message passing: communication between 8 epics includes 28 mutual interactions (the number of k-combinations from a given set S of n elements C(n,k), e.g., C(8,2) = 28). Coordination interactions between user stories are calculated in the same way: alignment of 15 user stories (per epic) involves C(15,2) = 105 interactions.

The horizontal complexity indicator Q2P of this project is Q2T = (Q2T(Th) = 0; Q2T(I) = 0; Q2T(E) = 28; Q2T(S) = 105)). The normalized horizontal complexity of this project Q2N = Q2P/Q2T is calculated as follows:

Q2N(Th) = 0; Q2N(I) = 0; Q2N(E) = 28/45; Q2(S) = 105/190;

We obtain that the normalized (relative) horizontal complexity of this project is evaluated as follows:

Q2(N) = (Q2N(Th) = 0, Q2N(I) = 0, Q2N(E) = 0.62, Q2N(S) = 0.55).

This shows that at the epic level complexity is more than half of the normative and at the user story level is nearly a half of the normative. Such a project can be classified as moderately complex from the perspective of horizontal coordination of agile activities.

4.6. Project Horizontal Completion Status Assessment

We define here two additional indicators of the status of the project’s horizontal specification:

-

Project horizontal specification scope status indicator Q2PS;

-

Horizontal interaction (coordination) content status indicator Q2PC.

Project horizontal specification scope status can be assessed based on the proportion of horizontal interactions between activities that are described in the database (specified, for example, in the Atlassian JIRA system).

The status of the horizontal specification scope of a project indicator Q2PS can be indicated by the horizontal interaction specification ratio, i.e., the ratio of the number of existing specifications to the number of theoretically necessary requirements (at each hierarchy level separately):

Q2PS = (Q2PS(Th), Q2PS(I), Q2PS(E), Q2PS(S)),

(9)

Let us assume that a specific EAS project is being implemented and the following horizontal interactions are specified at a given point in time:

-

The specific theme and initiative are formulated and described.

-

Content compatibility of epics has been partially implemented; for example, interactions of six epics have been described, two epics have not yet been analyzed.

-

The content of the user stories was partially verified, for example, 100 verified and 20 not yet verified.

For checking compatibility of initiatives, epics, and user stories, it is convenient to use matrices, as performed in enterprise architecture frameworks (MODAF, UAF) [38].

The project specification scope status Q2PS for each hierarchy level (activity type) can be described as the ratio of the number of existing specifications to the number of theoretically necessary requirements:

Q2PS = (Q2PS(Th) = 1, Q2PS(I) = 1, Q2PS(E) = 6/8 = 0.75, Q2PS(S) = 100/120 = 0.83).

The horizontal interaction content status indicator Q2PC is identified for all coordination interactions as a pair of flow and V flow A content variants (Ai,Cj) from Table 4 and Table 5 separately for the TIES levels:

Q2PC = (Q2PC(Th), Q2PC(I), Q2PC(E), Q2PC(S)),

(10)

where

-

{(A1,C1), (A1,C2), …, (A15,C14), (A15,C15)}—a set of horizontal interaction combination variants (Ai,Cj);

-

Q2PC(Th) = {(Th(p)&Th(k)(Ai,Cj))}—a set of interaction variants between themes, Ths;

-

Q2PC(I) = {I(p)&I(k)(Ai,Cj))}—a set of interaction variants between initiatives, Is;

-

Q2PC(E) = {E(p)&E(k)(Ai,Cj))}—a set of interaction variants between epics, Es;

-

Q2PC(S) = {S(p)&S(k)(Ai,Cj))}—a set of interaction variants between user stories, Ss.

For example, horizontal interaction content status (A1,C2) = (A1 = (A* defined, V* not defined, P* not defined, F* not defined), C2 = (A* not defined, V* defined, P* not defined, F* not defined), and content status (A15, C14) = (A15 = (A* defined, V* defined, P* defined, F* defined), C14 = (A* not defined, V* defined, P* defined, F* not defined).

Project activity status information is important for project management staff, allowing them to see gaps in the project phase and plan appropriate work.

When determining the horizontal interaction content status indicator Q2PC, it is theoretically correct to analyze each object and identify content variants, creating a status list. This is only possible in an Agile application software environment modified according to this method. In the next step, a suitable dashboard is formed, summarizing the results in sections relevant to project management. We believe that the complexity indicators Q1 and Q2 and their types (theoretical, project, and normalized) as well as the specification status indicators Q1PS and Q2PS can help to evaluate the complexity and effort of communication and coordination in EAS project management in terms of required financing and other resources.

It is important to note that project complexity indicators Q1 and Q2 can be calculated as described in [2] by summing up the values for each hierarchy level (topics, initiatives, epics, and user stories). However, since the largest contributions come from the epic and user story levels, it is also useful to report these indicators separately for each level (i.e., by activity type).

5. Implementation Elements and Experimental Evaluation

5.1. Implementation Elements

The architectural solution for an intelligent Agile project management tool integrated with the standard Jira environment is detailed in [1]. That article introduces the conceptual model of the causal Agile management repository and outlines the main steps for checking project-progress data (recorded within Jira) against the causal knowledge model (i.e., the MT structure). Table 8 in [1] illustrates how an “epic” and a “user story” are decomposed into the MT tuple (F, P, A, V) in the repository’s database records.

Table 8. Content of the data base record of the enhanced JIRA tool.

Theme	Initiative	Epic					User Story
		ID	F	P	A	V	ID	F	P	A	V
N	N	E01 Technical Tasks (785)	N	Y	Y	Y	S01 Technical architecture review (800)	Y	Y	Y	Y
N	N	E01 Technical Tasks (785)	N	Y	Y	Y	S02 Segregate audit log and transaction log (803)	Y	Y	Y	Y

Source: quoted from Ref. [1].

presents the EAS project requirement records based on the database structures shown in Figure 9 of [2]. It reveals that epic E01 lacks both an initiative and theme reference and has no management-function entry (F = “N”), even though its process (P), input flow (A), and output flow (V) are all defined and fixed in the database (Y). By contrast, user stories S01 and S02 under E01 are fully specified, with every MT element marked as Y at that point in time.

The prototype of an intelligent user interface component is presented in Figure 10. It indicates that there is a missing theme and initiative information. Also, epic E01 is missing a link to initiative and theme (F = “N”).

The improved user interface includes real-world domain knowledge for causal analysis, based on the Jira knowledge base: a strategy model view (Figure 10a, bottom left). A Business and IT Alignment (BITA) view is also provided, which includes a list of capabilities and a view of the business (operational) model, as well as buttons for analyzing A and V of internal MT information flows (see Figure 10b).

5.2. Experimental Evaluation Results

The experimental evaluation provided here drew on data from four enterprise application development initiatives, each spanning from one to several years. All projects combined Scrum at the team level with the Scaled Agile Framework (SAFe) at the organizational level.

The input for project requirements is gathered from four different Nordic countries working on one core process for each project. The purpose of the projects was to harmonize the processes, as there are minor deviations in the detailed processes of each country, e.g., ordering banking products as account opening, payment cards, digital signing, etc.

The enterprise application software projects must also address these deviations in the final version of the solution. Also, from an enterprise perspective, the dependencies between other teams working in the same area on their project deliveries must be addressed and aligned as part of SAFe.

The outcome of each project was a significantly reduced lead time, cutting the customer order fulfillment time from over two weeks to just four days.

We adopted an inductive research approach. During project delivery, we observed a recurring pattern: requirements driven by organizational strategy (for example, the objective “Become first in customer experience”) often emerged late in the lifecycle and were translated into specific priorities or capabilities (for example, “Interactive digital experience”). From these observations, we developed a method to detect misalignments between (a) the information captured from organizational strategy into the enterprise architecture framework and (b) the information available to the development team executing the projects, thereby leveraging organizational capabilities and aligning execution with business strategy. Finally, we conducted a case study to evaluate the effectiveness of this method.

The requirements organized as themes, initiatives, epics, user stories, change requests, and bugs were analyzed over project lifecycles ranging from 8 to 60 months. These items correspond to the TIES hierarchy levels (theme, initiative, epic, user story). The aggregated results appear in

Table 9. Enterprise application software projects requirements distribution.

Parameter	Project #1	Project #2	Project #3	Project #4
Requirements out of which:	138	224	236	2539
Strategic objective	Not defined	Not defined	Not defined	Not defined
-Themes	0 (not defined)	0 (not defined)	0 (not defined)	4
-Initiatives	1	2	2	10
-Epics	9	15	17	314
-User stories	128	207	217	2211
Change requests	273	173	36	1341
Bugs	135	252	304	824
Project duration	8 months	12 months	10 months	60 months

and

Table 10. EAS project theme to initiative composition example.

Theme	Initiative
Th-253 UAM * Workflows	I-241—User and role management for administrators. I-841—Role assignment to existing users. I-451—Basic information provisioning.
Th-6377 UAM and SSO	I-9426—Basic information provisioning implementation. I-3996—UAM solution implementation. I-4996—UAM implementation with security schema.
Th-4586 System improvements	I-7476—Integration with legacy system.
Th-4286 Enterprise UAM implementation	I-241—User and role management for administrators implementation. I-3462—Component integration PoC. I-4462—Role assignment to existing users implementation.

* UAM—user access management.

below.

Project #4 is examined in detail below. For this project, the TIES composition is as follows (see Table 10).

At the epic and user-story level, the distribution of user stories under each epic is presented in Figure 11.

Applying the proposed method to minimize information gaps between business-strategy execution and EAS delivery, we analyzed the data, and the findings are shown in

Table 11. Enterprise application software projects requirements distribution when using suggested method.

Parameter	Project #1	Project #2	Project #3	Project #4
Requirements out of which:	121	181	216	2244
Strategic objective	Become 1st choice for personal banking in the Nordics	Become 2nd by market share in business banking in the Nordics	Become 2nd by market share in business banking in the Nordics	Ensure state-of-art self-service experience to customers
-Themes	1	1	1	4
-Initiatives	1	2	2	10
-Epics	8	13	15	292
-User stories	111	165	198	1938
Change requests	238	146	36	1208
Bugs	107	238	304	765
Project duration	8 months	11 months	10 months	54 months

.

In this context, change requests refer to adjustments to user-story content, typically arising when delivered functionality does not align with business needs and a change request is created to adjust the system behavior to a desired state. Bugs denote invalid system behavior that results in errors.

After applying the method, the TIES requirement set changed: fewer epics and user stories were developed to complete the EAS projects. The change-request and bug categories saw significant reductions as well—Project 1’s bug count fell by over 20%, and Project 3’s change requests dropped by more than 16%. Comparative results are presented in

Table 12. Enterprise application software projects requirement distribution comparison.

Parameter, %	Project #1	Project #2	Project #3	Project #4
Requirements	−12.3	−19.2	−8.5	−11.6
Change requests	−12.8	−15.6	−16.7	−9.9
Bugs	−20.7	−5.6	0	−7.2
Project duration	0 months	−1 months	0 months	−6 months

and

Table 13. Enterprise application software projects complexity indicators.

Parameter, %	Project #1	Project #2	Project #3	Project #4
-themes	1	1	1	4
-initiatives	1	2	2	10
-epics	8	13	15	292
-user stories	111	165	198	1938
Complexity indicators
Q1PS	0.37	0.9	1.24	234.84
Q2PC	0.37	0.9	1.24	234.84
Q1PS	3.58	8.63	11.95	2264.79
Q2PC	3.58	8.63	11.95	2264.79

Note: The project complexity indicators in Table 13 were calculated according to the variant described in [2] by summing up the individual hierarchy-level indicators (themes, initiatives, epics, user stories).

.

The observed savings should be evaluated in terms of development effort and average hourly developer cost, allowing cost-savings to be calculated. Furthermore, based on the normalized (method-applied) EAS requirements distribution, project complexity indicators are calculated as follows.

As shown by the complexity metric calculations, complexity increases significantly with the number of epics and user stories in the EAS project hierarchy. This directly indicates the coordination resources (project managers, product owners) required to manage a project of this complexity.

The experimental evaluation results show that using a causal Agile project management method in EAS development reduces the coordination effort needed to align development activities with strategic business goals. Thus, the organization realizes the intended project benefits and advances its business objectives.

Experimental evaluation results demonstrate that the proposed modified causal Agile method, which is designed to align business and IT within an Agile environment by linking EAS project requirements to the company’s strategic goals, significantly enhances EAS project execution. It reduces the number of requirements, change requests, and errors by almost 13% over the entire project development life cycle. IT solutions also improve when missing information is incorporated into project specifications, because this inclusion ensures that each EAS system requirement is explicitly tied to the organization’s strategic objectives.

6. Conclusions

At the organizational level, Agile management offers the advantage of self-managed functions performed by multiple teams working on a single project. Organizing work according to Scrum, in sprints, ensures active feedback; that is, sprints function as a type of closed-loop transaction.

One key disadvantage is that the typical Agile process is poorly formalized. Agile activity types and their vertical and horizontal interactions lack a mandatory definition of content. As a result, tools built on this model capture only limited information about individual activities (user stories, epics, initiatives, themes) and omit both activity content and inter-activity relationships when storing data. Any information required to ensure alignment between strategic business objectives and specific Agile activities is typically obtained through communication among stakeholders, product managers, and development team members. Current Agile methods lean heavily toward the empirical end of the spectrum between formalism and agility.

Consequently, project management tools based on such a simple hierarchical model offer only limited support to project managers and team members. Therefore, this paper addresses the need to move slightly further toward the formal side of the spectrum. This approach enables development teams to retain the autonomy and self-organization inherent in Agile methods, while also leveraging constraints positively aligning with business objectives and focusing on delivering the most valuable features. By introducing formal structures, this method enhances clarity around business goals and reduces reliance on speculation.

The complexity of the model must match the complexity of the processes being modeled, so that essential features are not lost and the content of causal interactions is revealed. Therefore, a causal modeling method was chosen, adapted to specify Agile activities and processes based on the management transaction framework. MT is a causal knowledge structure that defines the mandatory internal structure of all Agile activities (thus normalizing their specification) and defines the semantics of MT’s internal information interactions. Interaction content comprises the mandatory elements defined in the MT structure: enterprise process (P), input flow A (process P state attributes), output flow V (process P controls), and management function (F). Each MT is related to an enterprise goal (G).

The causal model of the Agile management process has formally defined activity types and a hierarchical structure and, accordingly, a clearly defined content of information exchange between activities. The causal Agile management model formally defines Agile activities as a management transaction (MT), in which information feedback between internal MT elements reproduces the circular causality property of the business domain. A vertical interaction between two Agile activities is itself a complex MT with an internal feedback loop. Both vertical and horizontal classifications of causal interactions reveal variations in the content of information transmitted between different activities (i.e., MTs). Horizontal interaction can occur as an MT or as choreography (message passing) between two activities. Interaction content variants correspond to different combinations of elements in the management transaction structure MT(F, P, A, V). The theoretically possible interaction-content variants between activities are classified.

The set of Agile activities that make up a project is placed in an abstract Process Space (Aggregation, Generalization, Time). This placement makes it possible to formally define each activity’s location in the Agile hierarchy and record its identification parameters. Consequently, the knowledge base of enhanced Agile management tools is supplemented with new content: strategic goal specifications linked to themes (Th) and to Agile activities associated with enterprise management functions such as software development management, business management, financial management, and others.

EAS project complexity indicators were introduced to evaluate the communication and coordination effort required for EAS project management in terms of financing and other resources. The vertical complexity indicator Q1 is calculated for each activity type at every hierarchy level and comes in three variants: theoretical (normative) Q1T, based on a formal definition and estimating the typical number of project objects; project-specific Q1P; and the relative complexity indicator Q1N, defined as the ratio of Q1P to Q1T. The horizontal complexity indicator Q2 is defined analogously, with Q2T, Q2P, and Q2N calculated for each hierarchy level.

Project specification status is tracked through both vertical and horizontal status indicators at any point in time. Vertical specification status comprises two measures:

-

Q1PS, the vertical specification scope indicator, which gauges the proportion of required vertical interactions documented in the database against the theoretically defined total quantity.

-

Q1PC, the vertical interaction content status indicator, which details the specific content variant (Ai,Vj) of management tasks at each level of the agile hierarchy.

By formalizing these status metrics, the causal Agile management model makes the flow of information between Agile activities visible and supports systematic classification of interaction patterns. This foundation enables AI-driven orchestration of EAS development projects, ensuring Agile activities remain aligned with strategic business objectives and coordinated across functions. One of the features of the causal Agile management model that traditional Agile methods do not have is the integration of company objectives with the hierarchy of Agile processes and the identification of types of company management functions, which ensures traceability of project content to company management needs.

The number of combinations increases with each new user story, epic, initiative, or theme introduced in an EAS project. The theoretically possible large number of combinations of interaction content proves the complexity of managing a company in an Agile environment. Therefore, the architecture of advanced project management tools should be supplemented with a causal knowledge base specifying the proposed additional attributes. This would allow for automatic verification of the project status and more in-depth monitoring of the project status. If existing Agile tools (e.g., Jira from Atlassian) could capture deep causal knowledge as proposed in this method, they could significantly increase the ability to monitor the integrity of EAS project activities and provide guidelines for defining the correct relationships between levels in the Agile management hierarchy.

The high values of the introduced complexity indicators reflect an increased demand for EAS project coordination. This enables the organization to assess the level of coordination effort needed to ensure timely EAS project delivery and to allocate the appropriate number of coordination resources—such as program or project managers, product owners, coordinators, and other relevant roles.

Here, we have proposed an architectural solution that extends Jira with a causal Agile management repository, mapping themes, initiatives, epics, and user stories into an MT = (F, P, A, V) causal model, and a prototype UI that delivers real-time causal hierarchy views, strategy/domain models, and performance metrics for monitoring EAS development.

An experimental case study on four Nordic EAS projects (using Scrum at team level and SAFe at program level) shows that embedding causal checks into the standard Jira workflow uncovers missing initiative/theme links and harmonizes cross-team dependencies in real time. Applying our causal Agile method yielded an average 13% reduction in total number of requirements, a 14% drop in change requests and a 7% decrease in bugs, thereby cutting coordination effort and strengthening alignment between EAS development activities and strategic business objectives.

Even though the proposed causal Agile management approach offers significant advantages, its applicability is limited by the requirement that the organization’s business processes be fully defined and that it has achieved at least level 3 in the CMMI process evaluation model [40].