Methodological approach to managing cross-functional dependencies in Scrum teams as a factor in reducing business change delivery time

A cross-functional dependency arises when completing a Scrum team’s work item requires an output, decision, resource, or information that lies outside the team’s direct control. Such dependencies arise between development, analytics, design, information security, operations, and other participants involved in implementing the change. Scrum establishes the team’s responsibility for creating value within a sprint, while interaction with external parties remains a distinct coordination task [1].

The relevance of this issue is supported by recent research. A study involving 340 practitioners found a positive relationship between coordination strategy and coordination effectiveness, with synchronization, interaction structuring, and coordination across organizational boundaries identified as significant components [2]. An analysis of 69 studies combined with interviews demonstrated the growing importance of inter-team knowledge sharing as software development scales [3]. Another study identified inter-team dependencies as one of the most prominent organizational challenges associated with the sustained use of Agile approaches [4].

For a Scrum team, the significance of a dependency is determined by its impact on workflow. Unfinished external work increases waiting time, work item age, and the likelihood of spillover between sprints [5], ultimately affecting business change delivery time. In addition, the current DORA framework links delivery performance to change lead time and recommends beginning improvement efforts by measuring the current state and identifying constraints in the workflow [6].

From a methodological perspective, it is important to distinguish between the existence of a cross-functional dependency and the occurrence of a blockage. A dependency does not increase delivery time if the external output is available before the team actually needs it. Time is lost when there is a gap between the point at which the output is needed and the point at which it becomes available. Therefore, the transition of a dependency into a blocking state is the primary target of management intervention, while early identification should enable preventive action before the work item is blocked. This distinction defined the aim and scope of the present study.

The aim of this study is to develop a methodological approach to managing cross-functional dependencies in Scrum teams that enables their early identification, quantitative assessment of criticality, and control of their impact on business change delivery time.

The study employed analysis, classification, structural modeling, and scenario-based validation. Based on the nature of the required external output, four types of dependencies are distinguished:

1. A technical dependency involves an API, shared platform, environment, or integration;
2. A process dependency arises from a mandatory approval or a prescribed sequence of actions;
3. A resource dependency is determined by the availability of a specialist or shared resource;
4. An information dependency arises from the absence of a decision, requirements, data, or expert knowledge.

Research on inter-team coordination confirms the importance of managing such dependencies at the level of individual work items [7].

The proposed classification is consistent with the established approach to describing dependencies in the literature. In studies of organizational systems, coordination is defined as the management of dependencies among activities [8, p. 87-119], while in the context of agile software development, the most widely used taxonomy distinguishes knowledge, process, and resource dependencies [9, p. 23-46]. The present study retains the process and resource categories and divides knowledge dependencies into information dependencies (absence of a decision, requirements, or data) and technical dependencies (shared interface, platform, or environment), because the latter require a different resolution mechanism involving changes to an artifact or infrastructure rather than the transfer of knowledge between participants.

At the same time, the assessment of dependency criticality in existing studies remains predominantly qualitative: critical dependencies are identified through interviews and thematic analysis based on the most substantial delays and impediments to work progress [10]. The reviewed sources do not propose a quantitative measure for ranking registered dependencies according to their observed impact on workflow. Addressing this gap defined the focus of the present study.

The unit of management is an individual dependency associated with a backlog item. For each dependency, the required output, provider, recipient, responsible person, expected date, affected work items, and actual blocked time are recorded. Dependencies are registered during backlog refinement and sprint planning. Dependencies that emerge during execution are added to the same register.

To describe the transition of a dependency into a blocking state, three time points are recorded: the registration date, the control date, and the point at which the output is needed. The control date precedes the point of need and defines the threshold for preventive action. This distinction differentiates a dependency resolved in a timely manner from one that has already resulted in time loss and links the dependency register to workflow management.

For ranking purposes, a dependency criticality index is proposed that incorporates three normalized indicators: Bᵢ, the share of blocked time in the duration of the affected work items; Wᵢ, the proportion of work items affected by the dependency; and Fᵢ, the frequency of its occurrence across the sprints within a rolling observation window, the length of which is set by the team and is assumed here to be four sprints. The index is calculated as follows:

, (1)

The multiplicative form reflects the complementarity of the three factors: a high index value can be achieved only when all three are present simultaneously, while a zero value for any one of them reduces the index to zero. Equal exponents represent an explicit assumption that the factors are equally important, which may be revised as empirical data accumulate, rather than an absence of weighting as such. High index values are assigned to dependencies that cause prolonged waiting, affect a substantial proportion of work items, and recur regularly. One-off blockages are additionally monitored based on absolute waiting time.

The index is calculated using actual data from preceding sprints and therefore characterizes a recurring class of dependencies between specific organizational units or infrastructure components. This distinction is essential to the preventive nature of the approach: ranking based on accumulated historical data is applied to newly registered dependencies of the same class before a blockage occurs. For a dependency with no observation history, the index value is undefined, and monitoring is based on the control date and the expected time of output delivery. Thus, retrospective assessment of criticality provides the basis for preventive action in subsequent sprints.

For example, a dependency on the availability of an external API blocked the affected work items for 44% of their duration, affected 40% of the work items, and occurred in three of four sprints:

, (2)

The index is used to rank the dependency register. The priority group comprises dependencies that fall within the upper quartile of the Kᵢ distribution for the period analyzed and simultaneously exceed the absolute minimum expected blocked time established by the team. Combining relative and absolute criteria is necessary because the upper quartile always includes one-quarter of the register regardless of the actual severity of the dependencies; if no dependencies exceed the absolute minimum, the priority group remains empty. Thus, the value of 50.9 obtained in the example above is included in the priority group only if both conditions are met. This principle accounts for the specific characteristics of the team and does not require a universal threshold value for the index.

The index is treated as a measure of observed operational criticality rather than an expert-assessed probability of risk, as it combines blockage intensity, breadth of impact, and recurrence. The quartile-based approach makes the threshold relative and allows the priority group to be revised as the distribution of values changes, while the absolute minimum expected blocked time prevents clearly insignificant dependencies from being included. Dependency criticality is considered separately from the business priority of the work item; therefore, a high-priority item does not imply a high Kᵢ in the absence of blockage, whereas a recurring delay may make a dependency associated with a lower-priority item critical.

Thus, figure 1 illustrates the impact of cross-functional dependencies on workflow:

Fig. 1. Impact of cross-functional dependencies on workflow

A key feature of the approach is that dependencies are assessed based on their actual impact on workflow. The number of cross-functional dependencies is used as a descriptive measure. Key management decisions are based on the extent of blockage, recurrence, and the proportion of work items affected.

The management algorithm is presented in figure 2. According to the algorithm, once a dependency is registered, its type is determined and Kᵢ is calculated. For dependencies in the priority group, a responsible person on the provider side is assigned, along with a control date preceding the point of actual need. The status is checked before a blockage occurs. Failure to meet the control date triggers escalation to a level capable of changing the priority, resource allocation, or sequence of work. Once the dependency is resolved, the actual resolution time and blocked time are recorded. Recurring causes are reviewed during retrospectives and used to revise the rules governing cross-functional interaction.

Fig. 2. Algorithm for managing critical cross-functional dependencies

Thus, the algorithm defines three dependency states: registered, warning, and blocking. The first indicates the existence of a dependency without an immediate threat to the delivery timeline; the second occurs when the control date is approaching without confirmation that the required output will be ready; and the third occurs once the point of need has been reached and the required output remains unavailable. Transitions between these states determine the intensity of monitoring. Escalation should result in changes to priority, resource availability, the sequence of work, or the method of obtaining the required output.

Effectiveness is assessed using a system of interrelated metrics. The blocked-time ratio (BTR) is defined as the ratio of the total waiting time caused by cross-functional dependencies to the total lead time of work items; conceptually, this metric is complementary to flow efficiency [5]. Dependency resolution time (DRT) represents the average time from dependency registration to receipt of the required output. Dependency-related spillover (DSR) represents the proportion of work items, out of all items committed to a sprint, that are carried over to the next sprint due to an unresolved external dependency. The final metric is the median change lead time.

The system of metrics should be interpreted sequentially: DRT characterizes the speed of dependency resolution, BTR the proportion of waiting time, DSR the spillover of delays into the next sprint, and median change lead time links local blockages to the overall business change delivery time. Comparing these metrics prevents conclusions about improvement based solely on a reduction in the number of dependencies.

For scenario-based validation, two synthetic samples of 30 work items each were generated, corresponding to two consecutive four-sprint observation windows. The metric values were assigned for illustrative purposes and are intended to demonstrate how the proposed method operates. During the second period, the actions prescribed by the approach were applied to dependencies in the priority group: registration during backlog refinement, assignment of a responsible person on the provider side, establishment of a control date preceding the point of need, and escalation if that date was not met. In the baseline period, 19 work items had cross-functional dependencies, compared with 18 in the second period after application of the method. Their proportion decreased from 63.3% to 60.0%. At the same time, BTR decreased from 28% to 14%, average dependency resolution time from 3.6 to 1.9 days, and dependency-related spillover from 26.7% to 10.0%. Median change lead time decreased from 8.9 to 6.8 working days:

, (3)

Comparison of the modeled periods illustrates this effect. The proportion of work items with dependencies decreased by 3.3 percentage points, whereas BTR decreased by 50.0%, DRT by 47.2%, DSR by 62.5%, and median change lead time by 23.6%. Within the specified scenario, the effect is primarily associated with changes in the timing and sequence of dependency resolution. Delivery time is reduced without a substantial decrease in the number of cross-functional dependencies. The reduction in median change lead time exceeds the effect attributable solely to the decrease in blocked time within a sprint because BTR does not capture the waiting time that arises when a work item is carried over across a sprint boundary; the reduction in DSR addresses precisely this component of the delay. Because the values in both samples were generated by calculation, the observed relationship demonstrates the internal logic of the approach and does not constitute statistical evidence of its effectiveness.

The scenario results indicate that the effect is driven primarily by shorter waiting periods and earlier resolution of critical dependencies. The overall number of dependencies changes to a lesser extent. This finding is consistent with coordination research linking coordination effectiveness to interaction structure, synchronization, and timely knowledge sharing [2, 3].

A limitation of the study is the synthetic nature of the validation. The Kᵢ index requires validation using data from multiple Scrum teams. Future research should record dependencies at the backlog-item level across a series of consecutive sprints and compare the distribution of Kᵢ values with actual blocked time, spillover, and change lead time.

Thus, the proposed approach transforms cross-functional dependencies into measurable management objects. The proposed Kᵢ index enables the ranking of recurring dependencies, the algorithm establishes a procedure for managing them before prolonged blockage occurs, and the system of metrics enables assessment of their impact on workflow. The approach differs from existing studies by moving from the qualitative identification of critical dependencies to their quantitative ranking based on their observed impact on workflow. Future research should focus on validation in real-world settings and statistical assessment of the relationship between dependency criticality and business change delivery time.