You are currently viewing a new version of our website. To view the old version click .
MDPIMDPI
Search all articles
Mathematics
Download PDF
  • Article
  • Open Access

18 August 2025

A Causal Modeling Approach to Agile Project Management and Progress Evaluation

,
,
and
1
Informatics and Statistics Department, Faculty of Marine Technologies and Natural Sciences, Klaipeda University, Bijunu St. 17, LT-91225 Klaipeda, Lithuania
2
Informatics and Electrical Engineering Department, Faculty of Technology, Klaipedos Valstybine Kolegija—Higher Education Institution, Bijunu St. 10, LT-91223 Klaipeda, Lithuania
3
edON Academy, K. Donelaicio g. 60, LT-44248 Kaunas, Lithuania
*
Author to whom correspondence should be addressed.
Mathematics2025, 13(16), 2657;https://doi.org/10.3390/math13162657
This article belongs to the Special Issue Business Analytics and Decision-Making: Models, Algorithms and Applications
Version Notes
Order Reprints

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.

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 = {A1, A2, …, An} transmitted through flow A, and V = {V1, V2, …, 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);
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, V1), (r, F(Ψqn), P(Ψq′2), A2, V2), …,
(r, F(Ψqn), P(Ψq′m), An, Vn)}
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, MT1(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 MT1(Th, I), where q = 1. The corresponding set Ψq′ = {P(I1), …, 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, Table 4 and Table 5.
Table 3. Vertical interaction: control flow V content variants.
Table 4. Vertical interaction: feedback flow A (state attributes) content.
Table 5. Taxonomy of control flow V content in the horizontal interaction performed as MT.
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)}
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)},
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:
Figure 6. Interaction between activities MT and MT′ in the Process Space. Source: created by the authors based on [3].
-
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:
Figure 7. Vertical interaction between initiative I and epic E (defined as MT′ and MT) in the Process Space. Source: created by the authors.
-
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.
Figure 8. Causal Agile hierarchy: a single epic (E) creates interactions with a set of user stories S = (S1, …, Sz), defined as MT(E, S), where epic E acts in the role of function F, and each user story S takes on the role of process P. Source: created by the authors.
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 = {A1, A2, A3} 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:
Figure 9. Horizontal interaction conceptualized as a management transaction MT(X, X*). Source: created by the authors.
-
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))
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. 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.
Table 6. Vertical complexity indicator Q1.
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)),
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)),
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))
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. They are calculated using characteristics of a typical medium-sized project (see Table 1).
Table 7. Horizontal complexity indicator Q2.
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)),
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)),
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 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.
Table 8. Content of the data base record of the enhanced JIRA tool.
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”).
Figure 10. Enhanced Jira user interface dashboard for the manager (a) and the product owner (b). Source: created by the authors.
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 and Table 10 below.
Table 9. Enterprise application software projects requirements distribution.
Table 10. EAS project theme to initiative composition example.
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.
Figure 11. User stories distribution under epics. Source: created by the authors based on [30].
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.
Table 11. Enterprise application software projects requirements distribution when using suggested method.
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 and Table 13.
Table 12. Enterprise application software projects requirement distribution comparison.
Table 13. Enterprise application software projects complexity indicators.
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].

Author Contributions

Validation, K.N.; Data curation, K.N.; Writing—original draft, S.G.; Writing—review & editing, S.G., V.D. and J.T.; Visualization, J.T. All authors have read and agreed to the published version of the manuscript.

Funding

This research received no external funding.

Data Availability Statement

The original contributions presented in this study are included in the article. Data available on request due to restrictions (privacy, legal reasons).

Conflicts of Interest

The authors declare no conflict of interest.

References

  1. Noreika, K.; Gudas, S. Causal Knowledge Modelling for Agile Development of Enterprise Application Systems. Informatica 2023, 34, 121–146. [Google Scholar] [CrossRef]
  2. Gudas, S.; Noreika, K. Causal Interactions in Agile Application Development. Mathematics 2022, 10, 1497. [Google Scholar] [CrossRef]
  3. Gudas, S. Foundations of the Information Systems’ Engineering Theory Monograph; Vilniaus University: Vilnius, Lithuania, 2012; 382p, ISBN 978-609-459-075-7. [Google Scholar]
  4. Francis, B.A.; Wonham, W.M. The Internal Model Principle of Control Theory. Automatica 1976, 12, 457–465. [Google Scholar] [CrossRef]
  5. SCRUMstudy. Guide to the Scrum Body of Knowledge (SBOK Guide), 4th ed.; VMEdu Inc.: Phoenix, AZ, USA, 2013; 340p, ISBN 978-0-9899252-0-4. [Google Scholar]
  6. Highsmith, J.A. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems; Dorset House Publishing: New York, NY, USA, 1999; 358p, ISBN 978-0932633408. [Google Scholar]
  7. McDonald, K. Beyond Requirements: Analysis with an Agile Mindset (Agile Software Development Series), 1st ed.; Addison-Wesley Professional: Boston, MA, USA, 2015; 304p, ISBN 978-0321834553. [Google Scholar]
  8. Nurdiani, I.; Börstler, J.; Fricker, S.; Petersen, K.; Chatzipetrou, P. Understanding the Order of Agile Practice Introduction: Comparing Agile Maturity Models and Practitioners’ Experience. J. Syst. Softw. 2019, 156, 1–20. [Google Scholar] [CrossRef]
  9. Agile Project Management. Running Agile Projects; DSDM Consortium, The Stationery Office: London, UK, 2012. [Google Scholar]
  10. Cockburn, A. Crystal Clear: A Human-Powered Methodology for Small Teams, 1st ed.; Addison-Wesley Professional: Boston, MA, USA, 2004; 312p, ISBN 978-0201699470. [Google Scholar]
  11. Palmer, S.R. Practical Guide to Feature-Driven Development; Prentice Hall: Englewood Cliffs, NJ, USA, 2002; 298p, ISBN 978-0130676153. [Google Scholar]
  12. Leffingwell, D.; Yakyma, A.; Knaster, R.; Jemilo, D.; Oren, I. SAFe® 6.0 Reference Guide: Scaled Agile Framework for Lean Enterprises; Addison-Wesley Professional: Boston, MA, USA, 2023. [Google Scholar]
  13. Beck, K.; Beedle, M.; van Bennekum, A.; Cockburn, A.; Cunningham, W.; Fowler, M.; Grenning, J.; Highsmith, J.; Hunt, A.; Jeffries, R.; et al. Manifesto for Agile Software Development. 2001. Available online: http://agilemanifesto.org/ (accessed on 6 August 2025).
  14. Larman, C.; Vodde, B. Large-Scale Scrum—More with LeSS, 1st ed.; Addison-Wesley Professional: Boston, MA, USA, 2016; 368p, ISBN 978-0321985712. [Google Scholar]
  15. Leffingwell, D. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise (Agile Software Development Series), 1st ed.; Addison-Wesley Professional: Boston, MA, USA, 2010; 518p, ISBN 0321635841. [Google Scholar]
  16. Mansurali, A.; Swamynathan, R.; Sajal, K.; Shanmuga, J. Systematic Review of Literature on Agile Approach. NMIMS Manag. Rev. 2024, 32, 84–105. [Google Scholar] [CrossRef]
  17. Dhanasekar, E. Scalable Agile Frameworks: Comparing Safe, Less, And Nexus for Enterprise Adoption. Am. J. Eng. Technol. 2025, 7, 135–143. [Google Scholar] [CrossRef]
  18. Noreika, K.; Gudas, S. Modelling the Alignment Between Agile Application Development and Business Strategies. In Proceedings of the BIR 2021 Workshops and Doctoral Consortium Co-Located with 20th International Conference on Perspectives in Business Informatics Research (BIR 2021), Vienna, Austria, 22–24 September 2021; CEUR Workshop Proceedings. Volume 2991, pp. 59–73. Available online: https://ceur-ws.org/Vol-2991/paper06.pdf (accessed on 6 August 2025).
  19. Ambler, S. Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process, 1st ed.; Wiley: Hoboken, NJ, USA, 2002; 400p, ISBN 978-0471202820. [Google Scholar]
  20. Prior, D. Agile Planning With Ties With Tom Churchwell. 2021. Available online: https://www.liminalarc.co/podcast/agile-planning-ties-tom-churchwell/ (accessed on 7 August 2025).
  21. Digital.ai Software, Inc. 14th Annual State of Agile Report. Available online: https://stateofagile.com/#ufh-i-615706098-14th-annual-state-of-agile-report/702749 (accessed on 27 March 2021).
  22. Bunge, M. Causality and Modern Science, 3rd ed.; Dover Publications: Mineola, NY, USA, 2011; 448p, ISBN 978-0486237282. [Google Scholar]
  23. Senge, P.M. The Fifth Discipline: The Art and Practice of the Learning Organization; Doubleday/Currency: New York, NY, USA, 1990; 424p, ISBN 978-0385260947. [Google Scholar]
  24. Deming, W.E. The New Economics for Industry, Government and Education, 3rd ed.; Massachusetts Institute of Technology, Center for Advanced Engineering Study: Cambridge, MA, USA, 1993; 247p, ISBN 978-0-262-54116-9. [Google Scholar]
  25. Porter, M.E. Competitive Advantage: Creating and Sustaining Superior Performance; Free Press: New York, NY, USA, 1985; 557p, ISBN 978-0029250907. [Google Scholar]
  26. Harmon, P. Business Process Change: A Guide for Business Managers and BPM and Six Sigma Professionals (The MK/OMG Press), 2nd ed.; Morgan Kaufmann: Burlington, MA, USA, 2007; 592p, ISBN 978-0123741523. [Google Scholar]
  27. Rummler, G.A.; Brache, A.P. Improving Performance: How to Manage the White Space on the Organizational Chart, 1st ed.; Jossey-Bass Inc. Pub: San Francisco, CA, USA, 1990; 256p, ISBN 978-0787900908. [Google Scholar]
  28. Gudas, S. Information Systems Engineering and Knowledge-Based Enterprise Modelling: Towards Foundations of Theory: Springer Proceedings in Business and Economics; Kavoura, A., Sakas, D., Tomaras, P., Eds.; Strategic Innovative Marketing; Springer: Cham, Switzerland, 2017; pp. 481–497. ISBN 978-3-319-33865-1. [Google Scholar] [CrossRef]
  29. Bondy, J.A.; Murty, U.S.R. Graph Theory; Springer: Berlin/Heidelberg, Germany, 2010; 675p, ISBN 978-1849966900. [Google Scholar] [CrossRef]
  30. Gudas, S.; Lopata, A. Towards Internal Modelling of the Information Systems Application Domain. Informatica 2016, 27, 1–29. [Google Scholar] [CrossRef]
  31. Grefen, P.; Vonk, J. A Taxonomy of Transactional Workflow Support. Int. J. Coop. Inf. Syst. 2006, 15, 87–118. [Google Scholar] [CrossRef]
  32. Dietz, J.L. The deep structure of business processes. Commun. ACM 2006, 49, 58–64. [Google Scholar] [CrossRef]
  33. Moyanom, C.G.; Pufahl, L.; Weber, I.; Mendling, J. Uses of Business Process Modeling in Agile Software Development Projects. Inf. Softw. Technol. 2022, 152, 107028. [Google Scholar] [CrossRef]
  34. He, S.; Ning, Y.; Zhang, L.J.; Lei, K. A Paradigm Shift to Causal Model-Driven Decision-Making With Generative AI. In AI and Multimodal Services—AIMS 2024; Pan, X., Huang, M., Zhang, J., Chen, J., Zhang, L.J., Eds.; AIMS 2024. Lecture Notes in Computer Science, 15421; Springer: Cham, Switzerland, 2024; pp. 3–19. [Google Scholar] [CrossRef]
  35. Shi, D.; Wang, N.; Zhang, F.; Fang, W. Intelligent Electromagnetic Compatibility Diagnosis and Management With Collective Knowledge Graphs and Machine Learning. IEEE Trans. Electromagn. Compat. 2020, 99, 1–11. [Google Scholar] [CrossRef]
  36. Pankowska, M. Enterprise Modeling According to Enterprise Architects. Open J. Soc. Sci. 2021, 09, 636–647. [Google Scholar] [CrossRef]
  37. Barn, B.S.; Barat, S.; Sandkuhl, K. Adaptation of Enterprise Modeling Methods for Large Language Models. In The Practice of Enterprise Modeling: PoEM 2023; Almeida, J.P.A., Kaczmarek-Heß, M., Koschmider, A., Proper, H.A., Eds.; Lecture Notes in Business Information Processing, 497; Springer: Cham, Switzerland, 2023. [Google Scholar] [CrossRef]
  38. Gudas, S. Causal Modelling in Enterprise Architecture Frameworks. Informatica 2021, 32, 247–281. [Google Scholar] [CrossRef]
  39. Gudas, S. Organisational System as a Hierarchy of Information Processes—Applications of Artificial Intelligence in Engineering VI (AIENG 91). In Proceedings of the 6th International Conference on Artificial Intelligence in Engineering (AIENG 91), Oxford, UK, June 1991; Computational Mechanics Publications: Southampton, UK; Boston, MA, USA; pp. 1037–1050, ISBN 1-85312-141-X. [Google Scholar]
  40. Ahern, M.D.; Clouse, A.; Turner, R. CMMI Distilled: A Practical Introduction to Integrated Process Improvement, 3rd ed.; Addison-Wesley Professional: Boston, MA, USA, 2008; 282p, ISBN 0321461088. [Google Scholar]
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Article Metrics

Citations

Article Access Statistics

Journal Statistics
Multiple requests from the same IP address are counted as one view.
Download PDF
Existence, Stability, and Numerical Methods for Multi-Fractional Integro-Differential Equations with Singular Kernel
Previous
General Decay Stability of Theta Approximations for Stochastic Delay Hopfield Neural Networks
Next