Introduction

Scrum is the most widely used framework for agile software development (^{Digital.ai, 2020}; ^{Mutiullah et al., 2018}; ^{Fustik, 2017}; ^{Usman, Mendes & Börstler, 2015}). In such a context, effort estimation is fundamental in Scrum since it is necessary for planning a sprint, which is a development cycle (^{Azanha, Argoud, Camargo Junior & Antoniolli, 2017}). However, such a process remains challenging because there is a mutual dependence between the scrum master and the development team. On the one hand, the scrum master aims to produce the highest business value in each sprint. On the other hand, the team wants to maximize its profits by exerting some effort. Hence, Scrum is a cycle development that casts similarities with principal-agent problems, where uncertainty is attributed to a lack of communication between the leader and the team (^{Eisenhardt, 1989}). Consequently, companies often prioritize insourcing development with mature teams because agents know each others’ abilities and expertise under such a structure (^{Paramanantham, Nizam & Eissa, 2019}; ^{Omar, Bass & Lowit, 2016}). Also, companies have control over their products and services (^{Chudzicka, 2013}), which is necessary for businesses based on technology and innovation (^{Naik, 2016}).

Despite the advantages of insourcing development with mature teams, EE is not an easy task because it is a complex process where agents face structural deficiencies and pursue different objectives (Popli & Chauhan, 2014). In this paper, we perform numerical simulations concerning the behavior of the scrum master and the development team at equilibrium. The simulated strategies are based on ^{Medina-Barrera et al. (2022)}, which analyzes a leader-follower interaction between the scrum master (who provides resources during the first stage) and the development team (that exerts effort in the second stage). Later, they analyze two alternative scenarios where i) agents exchange their roles and ii) an additional meeting is considered. Our main contribution relies on showing the impact of parameters’ variations on equilibrium strategies.

In recent years, the importance of software development analysis has increased since digital solutions diminish costs and increase efficiency. So, digital solutions are increasingly required in social and economic activities. However, development teams struggle to cope with delivery given the complexity of software projects and their increasing demands, which saturates development teams (^{Brem, Viardot & Nylund, 2021}). So, effort estimation and resource provision are crucial for planning software projects and achieving successful results (^{Mohagheghi & Jørgensen, 2017}; ^{Arias et al., 2012}). We observe that effort and resources at equilibrium increases as the players are more skilfull but the interaction structure reduces the resources at equilibrium when the scrum master is the leader; We also observe decreasing marginal returns finding a point where expending more effort becomes inefficient.

This paper is organized into fifth sections, as follows. The second section explains how a software project development is planned under the Scrum context. The third section presents the game-theoretic model of ^{Medina-Barrera, et al. (2022)} for effort estimation and resource provision in Scrum projects. Also, we describe the variations of such a model. The fourth section shows some numerical examples, and we derive strategies for managing software projects. Finally, the conclusions are exposed in the last section.

Product planning

Scrum develops software projects by carrying them out incrementally; in other words, the customer receives partial deliveries following planned scheduling. From the product owner, the scrum master gets the product backlog, a prioritized list with k user stories¹ describing customer requirements that the team must develop (see block A in Figure 1). So, the scrum master splits the project into parts and establishes the number of partial deliveries and their features, such as how long they will take and the deliveries’ objective, which are the project’s parts of being built in such a delivery.

Source. Own elaboration.

Figure 1 Events around the EE game under Scrum context 

It is worth recalling that user stories’ priority² is agreed with the customer based on its business value. Thus, the development team should address the highest priority user stories in the product backlog first. Then, the team estimates the size of each user story through story points³ that compose scrum cycles, also known as time-boxed (^{Torrecilla-Salinas et al., 2015}). Afterward, the team communicates its iteration velocity v to the scrum master; v represents the number of stories the team can develop in a time t.

The scrum master can fit the velocity v if he has historical data from similar projects developed by the team. Besides, it is necessary to set a tolerance rangeδ around v. The scrum master establishes δ with the support of the development team through a preliminary analysis of the risks involved concerning the project’s development. Hence, we have that it-=k/v+δ is the minimum number of iterations or partial deliveries of the total product, whereas it+=k/v-δ is the maximum number of iterations. The previous process represents the initial planning for the software product’s agile development.

Later, when the first sprint starts, the strategic interaction between the scrum master and the development team emerges since each of them pursues their maximum benefit. Let us explain this point. On the one hand, the scrum master aims to produce the highest business value during the time interval [it-, it+]; for example, the scrum master may accelerate the sprint to attend to other projects. On the other hand, exerting effort generates costs for the development team (like transportation); consequently, the development team exerts the effort that maximizes its profits.

It is worth mentioning that v indirectly summarizes the team’s abilities because the velocity points out the team’s productivity at each iteration. So, v should be updated at the end of each iteration, while the job must be re-estimated for the next delivery. In such a way, each iteration represents a new conflict since v reflects the team’s current development capacity.

The EE game model

Given the previous discussion, this paper analyzes a single sprint with a fixed iteration velocity v. The set of players is J=SM, DT, where SM is the scrum master, and DT is the development team. We consider an insourcing development project in the hands of a mature team, which implies complete information. Also, we assume that DT makes decisions as a single player since scrum teams used to be self-organized. In other words, DT shares goals and makes decisions collectively (^{Srivastava & Jain, 2017}).

The set of DT’s actions is ADT=e∈R0≤e≤t, where e is the estimated effort to perform the necessary tasks for building the story points of the iteration in progress. Regarding SM’s actions, the SM‘s mission is to support DT by removing obstacles during the iteration; hence, SM is a resource provider (^{Villegas Gómez et al., 2016}; ^{Srivastava & Jain, 2017}). Consequently, the SM’s actions are the resources r that he provides to DT, that is ASM=r∈R0≤r. An actions profile is a pair e,r∈ADT×ASM that summarizes all relations in project development.

Players are characterized by a behavior type that summarizes interpersonal skills and impacts their decision-making (^{Ramos & Vilela Junior, 2017}). The DT’s type h varies according to its members’ knowledge, skills, and experience (^{Čelar et al., 2014}). Concerning the scrum master, her type f represents SM flexibility in resource provision as a team leader (^{Sabbagh, 2013}; ^{Quinn et al., 1996}). We assume that both types take values between 0 and 1. If h=0, the DT does not have the necessary skills to cope with the project’s objectives, while h=1 states the opposite. Also, a type f=0 means that the scrum master is not interested in providing resources to the DT, while h=1 describes the opposite. Since we assume an insourcing development with a mature team, the types’ vector f,h is of common knowledge.

Players’ benefits are mutually dependent since exerting effort requires resources, while providing resources needs coping with stories. So, SM’s benefits depend on the DT’s effort, and the DT’s benefits depend on the SM’s support. On one side, we consider that SM provides DT with basic infrastructure K and additional resources r. On the other side, the DT exerts a fixed effort G related to transportation and administrative activities. Thus, the estimated effort e is additional for developing the iteration’s activities.

We define players’ benefits as the difference between revenues and costs. We denote the benefits of the development teams and the scrum master as πDT=BDT-CDT and πSM=BSM-CSM, respectively.

To describe the previous functions, we first consider that the DT gets a monetary income I>0. Moreover, the sprint’s outputs result from mixing resources and effort. So, we assume that both agents have Cobb-Douglas functions that depend on the inputs basket r, e∈ASM×ADT. To simplify the model, we assume that the selling price of agents’ products is standardized to one. So, the revenue of each agent is

Players in J face costs by exerting effort and providing resources. As is common in the agile software literature, we use quadratic functions to represent players’ costs (^{Lee & Kim, 2013}). Quadratic costs are appealing for this analysis since they illustrate increasing marginal costs, which means that costs increase as the project needs an additional unit of effort or resources. Concerning the players’ types, we assume that costs diminish as (h, f) improves since behavior types represent skills and disposition to perform activities in a better way. The project’s environment also impacts the cost function since it serves as an adjusting parameter; that is to say, if stability τ prevails in the working place, it is easy to develop all the activities that the sprint needs. In other words, costs diminish as τ increases (^{Ziauddin & Zia, 2012}). Finally, DT’s effort costs are weighted by the tasks’ complexity γ involved in the current sprint backlog (^{Ziauddin & Zia, 2012}). The previous considerations are summarized in the following costs functions:

Players interaction

The impact of SM’s resources on DT’s effort varies according to how they are deployed during the sprint. Hence, it is crucial to establish user stories’ complexity in the sprint backlog and all the impediments and conflicts hindering their construction. Therefore, the Scrum framework outlines the following events around the sprint:

During daily meetings, members of the development team answers questions like

Besides, the SM may monitor DT’s happiness during the retrospective meeting by asking questions like

The SM’s main goal is to identify whether DT is facing issues or conflicts and their impact on completing the sprint backlog. If such impediments cannot be overcome in the current iteration, SM can decide to abort it and to re-plan it. In such a case, both players would receive null payoffs (πSM,πED=0).

These procedures are recommended patterns for developing Scrum projects whose responsibility lies with SM (^{Sutherland, Harrison & Riddle, 2014}).

The previous meeting classification also sets up different scenarios for the interaction between the SM and DT. We formalize such scenarios as sequential games since DT and SM do not simultaneously unfold their activities. Given a fixed sprint backlogΠ=s1,s2,...sn, the common base list of activities, the interaction between SM and DT may unfold in one of the following three scenarios

Scenario 1

The scrum master and the development team take the role of leader and follower, respectively. Thus, we have the following two-stage game:

Stage 1. The SM chooses the additional resources r that she provides to the DT.

Stage 2. The DT observes resources that SM provides in the previous stage. Later, DT establishes the effort e to exert during this stage.

The number of resources SM provides to DT is K+r, i.e., basic infrastructure plus additional resources to develop the sprint backlog. Also, it is worth noticing that SM only participates in the sprint planning meeting. So, she ceases her interaction with DT (see Figure 2).

Source. Own elaboration.

Figure 2  . Scenario 1: Sprint planning 

Scenario 2

In this scenario, the players exchange their roles. Now, the development team is the leader, while the scrum master is the follower. So, the game proceeds as follows:

Stage 1. The DT establishes the effort e to exert during the iteration.

Stage 2. The SM observes the effort that the DT exerts in the previous stage and chooses the additional resources r that she provides for the sprint’s activities.

In this scenario, SM behaves as part of the team by providing resources. Such an interaction results from close communication between them in the daily meeting to identify and eliminate obstacles during the iteration (see Figure 3). We can say that the SM actively collaborates with DT to accomplish the sprint’s goals. Then, besides the basic infrastructure K, SM provides additional resources r required by DT to remedy conflicts arising during the sprint. Such resources may include upgraded equipment, maintenance, training, exit permissions, and free time for recreation.

Source. Own elaboration.

Figure 3 Scenario 2: Daily meeting 

Scenario 3

In the last scenario we consider, the scrum master intervenes in two stages. So, there is a planning meeting where SM provides initial resources and a retrospective meeting after the teams exert effort where the SM offers additional resources. Formally, the previous interaction is the next sequential game:

Stage 1. The SM chooses the initial resources r1 that she provides at the beginning of the sprint.

Stage 2. The team observes resources r1 and establishes the effort e to exert during the iteration.

Stage 3. After the DT exerts effort, the SM observes the sprint’s state. So, SM provides additional resources r2.

Then, the third scenario describes a scrum interaction where the SM actively participates before, during, and after the sprint. In other words, during the sprint planning meeting, SM identifies and eliminates obstacles that DT may face. Finally, in the retrospective meeting, SM identifies the main impediments to completing the sprint. Thus, the last meeting requires collaboration with the DT since the SM observes the team effort. Suppose the SM and the DT identify complex tasks. In that case, the discoveries are inserted as the highest priority user story on the subsequent sprint backlog (see Figure 4), which is a designed pattern to scale results (^{Sutherland, Harrison & Riddle, 2014}). In summary, the DT receives the basic infrastructure K and initial resources r1; if they are not enough, the SM provides additional resources r2.

Source. Own elaboration.

Figure 4 Scenario 3: Retrospective meeting 

Finding the optimal strategies at equilibrium

It is worth emphasizing that SM and DT follow rational and strategic behavior during the sprint since both choose strategies that maximize their benefits. Still, each other decisions also impact their gains. The solution concept we study is the Subgame Perfect Nash Equilibrium to avoid non-credible strategies from both agents while coping with the sprint’s goals. For DT, we use e* to denote an equilibrium strategy that maximizes πDT. Similarly, we say that r* is the equilibrium strategy of the SM, which maximizes her benefit function πSM. Formally, a strategies profile e*,r* is a subgame perfect Nash equilibrium if each strategy eliminates incentives to change strategies at each sub-game.

^{Medina-Barrera et al. (2022)} get the equilibrium strategies through a backward induction under which each sequence of events is resolved from the last to the first stages. In other words, such a process first computes the equilibrium strategies at the final stage, and such a strategy is used to solve the previous stage. Since a single player makes decisions at each stage, equilibrium strategies solve a maximization problem, i.e., we apply the first- and second-order conditions.

Numerical examples

In this section, we perform some numerical examples to show how the equilibrium strategies (r* and e*) as well as the players’ benefits at equilibrium (πSM and πDT) change as the exogenous parameters vary. Firstly, we study the impact of the players’ type (h and f). Then, we investigate the influence of the sprint backlog complexity and the environmental stability ( γ and τ).

The impact of DT’s experience and SM’s flexibility

In this example, we analyze the relationship between the equilibrium strategies (r* and e*), benefits at equilibrium ( πSM and πDT) concerning players’ types h and f. We compare the impact of such parameters on the equilibria of each scenario. We fix the value of other exogenous. Specifically, we consider the stable environment is τ=1, low sprint backlog complexity γ=0.1, null monetary income I=0, null fixed expense G=0, and null basic infrastructure K=0. Figure 5 illustrates the impact of types on equilibrium strategies, and Table 1 presents the numerical results.

Source. Own elaboration.

Figure 5 Changes inr*,e*,πSM,πDTasfandhchange 

We note that players’ types have a different impact on players’ strategies and payoffs. SM’s strategy and payoff increase as her profile becomes more flexible. The effort of DT at equilibrium increases as the DT is more skillful; as a consequence, its payoff also increases. Interestingly, the interaction structure reduces the resources that SM provides at equilibrium when SM is the leader. On the contrary, players’ payoff increases while they occupy the follower position. Thus, SM can take advantage of the interaction structure where he participates as a leader and follower by deciding how much support provide to DT in each intervention. Such a scenario increases the SM’s benefits, avoiding the waste of resources. These results show the advantages of holding retrospective and daily meetings to boost the sprint results.

Equilibrium strategies under variations on the Spring backlog complexity and environmental stability

Now, we analyze equilibrium when the sprint backlog complexity and the environmental change. So, we illustrate the impact of changes γand τ in the equilibrium strategies ( r*, e*) and the corresponding payoffs (πSM, πDT). We set other exogenous parameters by considering the following values: DT has high experience (h=1), the SM is flexible ( f=1), null monetary income (I=0), null fixed expense (G=0), and null basic infrastructure (K=0). Figure 6 shows the impact of backlog complexity and environmental stability on equilibrium strategies and benefits. Table 2 presents the corresponding numerical results.

Source. Own elaboration.

Figure 6 Changes inr*,e*,πSM,πDT as γ and τchange 

In Figure 6, we generally observe non-linear behaviors, meaning that marginal effects depend on the relationship between the interaction’s parameters. In other words, there is no negative or positive relationship since exogenous factors are not independent between them. Interestingly, we observe an inverse U that illustrates decreasing marginal returns in most cases. There is a point where the sprint reaches its maximum results, at which expending more effort becomes inefficient. We can say that too much stability and simplicity can discourage people from striving. In contrast, extremely complex projects developed in an excessively turbulent environment can also put people off.

Results and discussion

In this work, we model the effort estimation process in a Scrum context as a leader-follower game where players have complete information about each other. Given the importance of effort exertion to complete software projects under insourcing development, we study the interaction between a scrum master and a mature development team when they know the attributes and capabilities of each other. In such a game, the scrum master provides resources while the development team exerts effort. Later, we compare leader and development team equilibrium strategies when they interchange their roles. Our results provide conditions that guarantee the uniqueness of equilibrium strategies. We also find that equilibrium effort is the same regardless of the game structure we consider. At the same time, the scrum master has the opportunity to diminish the number of resources that she provides when she behaves as a follower. Interestingly, being a follower provides a larger payoff than being a leader for both the scrum master and the development team. We think this could provide useful insights for agile software development environments since servant leadership may reduce the waste of resources, as the third scenario suggests.

Conclusions

This work presents a game-theoretical model to find the optimal leader-team strategies in the EE process in a Scrum context. Since EE is crucial to accomplish software projects in insourcing environments, we consider mature teams; the parties involved know each other’s abilities. By analyzing three different scenarios, we find that players’ strategies at equilibrium increase when the environment is stable, the team experience, and the leader flexibility are high. Meanwhile, players’ strategies decrease as the sprint backlog becomes more complex. Therefore, team velocity accelerates when the sprint backlog is simple, the environment is highly stable, and the leader and the team are skillful. Here, the leader has a strategic role in achieving the sprint goals by supporting the team through the scrum meetings.