Desarrollo interno de proyectos de software con equipos maduros: estimación de esfuerzo y provisión de recursos en equilibrio

Insourcing software projects with mature teams: effort estimation and resource provision at equilibrium


María-Guadalupe Medina-Barrera[1], Rosa María Cantón Croda[2], Damián Emilio Gibaja-Romero[3]




La Estimación de Esfuerzo (EE) es crucial para la planeación de proyectos de software toda vez que contribuye al logro de objetivos. Sin embargo, la EE es un proceso complejo aún en las metodologías ágiles debido a los factores ambientales y estructurales que se encuentran presentes durante la interacción entre el equipo de desarrollo y su líder. Para hacer más sencillo el proceso de EE, las compañías prefieren el desarrollo interno con equipos maduros y un líder que provea recursos. Modelamos la interacción entre el líder y el equipo de desarrollo como un juego líder-seguidor para entender como ambos se comportan en equilibrio. Después, comparamos las estrategias en equilibrio del líder y del equipo de desarrollo al momento en que intercambian sus roles. Nuestros resultados principales proveen condiciones que garantizan la unicidad de las estrategias en equilibrio, y mediante ejemplos numéricos ilustramos el impacto de las variables exógenas sobre las estrategias en equilibrio.


Palabras clave: Desarrollo de software ágil, estrategias óptimas, estimación de esfuerzo, Scrum.




Effort estimation (EE) is crucial for planning software projects since it contributes to delivery goals. Nevertheless, even in agile methodologies, EE is a complex process due to environmental and structural factors surrounding the interaction between the leader and the development team. To simplify EE, companies prefer insourcing development with a mature team and a leader that provides resources. We model the interaction between the leader and the development team as a leader-follower game to understand how they behave at equilibrium. Later, we compare leader and development team equilibrium strategies when they interchange their roles. Our main results provide conditions that guarantee the uniqueness of equilibrium strategies, and we illustrate the impact of exogenous variables on equilibrium strategies through numerical examples.


Keywords: Agile software development, optimal strategies, effort estimation, Scrum.





Scrum is the most widely used framework for agile software development (, 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 stories1 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.


Figure 1

Events around the EE game under Scrum context

Source. Own elaboration.



It is worth recalling that user stories’ priority2 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 points3 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  is the minimum number of iterations or partial deliveries of the total product, whereas  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 ; 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 , 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 , where  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  that he provides to DT, that is . An actions profile is a pair  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  varies according to its members’ knowledge, skills, and experience (Čelar et al., 2014). Concerning the scrum master, her type  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 , the DT does not have the necessary skills to cope with the project’s objectives, while  states the opposite. Also, a type  means that the scrum master is not interested in providing resources to the DT, while  describes the opposite. Since we assume an insourcing development with a mature team, the types’ vector  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  and additional resources . On the other side, the DT exerts a fixed effort  related to transportation and administrative activities. Thus, the estimated effort  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  and , respectively.


To describe the previous functions, we first consider that the DT gets a monetary income . 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 . 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  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 ( ) 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:

1.                  The planning meeting,

2.                  The daily meeting,

3.                  and the retrospective meeting.


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

-  What have you done since yesterday?

-  What are you going to do today? and

-  Do you have any impediment that is not allowing you to advance?

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

-  How happy are you at your job role?


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 ( ).



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 , 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  that she provides to the DT.

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


The number of resources SM provides to DT is , 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).


Figure 2

Scenario 1: Sprint planning

Source. Own elaboration.



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  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  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.


Figure 3

Scenario 2: Daily meeting

Source. Own elaboration.



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  that she provides at the beginning of the sprint.

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

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


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 ; if they are not enough, the SM provides additional resources .



                                                                         Figure 4

Scenario 3: Retrospective meeting

Source. Own elaboration.



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  to denote an equilibrium strategy that maximizes . Similarly, we say that  is the equilibrium strategy of the SM, which maximizes her benefit function . Formally, a strategies profile  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 (  and ) as well as the players’ benefits at equilibrium (  and ) change as the exogenous parameters vary. Firstly, we study the impact of the players’ type ( and ). 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 (  and ), benefits at equilibrium (  and ) concerning players’ types and . 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.


Figure 5.  

Changes in , , ,  as  and  change

Source. Own elaboration.



                                                                 Table 1


Players’ best strategy and payoffs as  and  change by each scenario





DT’s low experience =0.1 and SM’s inflexible profile =0.1
















DT’s average experience =0.5 and SM’s medium profile =0.5
















DT’s high experience =1 and SM’s flexible profile =1
















Source. Own elaboration.


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  ( , ) and the corresponding payoffs ( , ). We set other exogenous parameters by considering the following values: DT has high experience ( =1), the SM is flexible ( =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.




Figure 6