Improvements for the Planning Process in the Scrum Method

Abstract

In today’s dynamic development environments, agile methodologies like Scrum are essential for effective software project management. Despite its popularity, the Scrum framework’s reliance on subjective intuition during the sprint planning process can lead to inconsistencies and project delays. This study aims to enhance the sprint planning phase by integrating the BeCoMe method, which is a mathematical approach designed to optimize task selection through structured compromise solutions. Utilizing a soft systems methodology, this research identifies and analyzes the existing inefficiencies in Scrum’s planning process. The implementation of the BeCoMe method in a real-world case study demonstrated significant improvements in task completion rates and overall project efficiency. The method’s structured process reduces biases, fosters team consensus, and enhances decision-making accuracy. The findings suggest that incorporating the BeCoMe method into Scrum can substantially mitigate risks, save time, and improve project outcomes by ensuring a more objective and data-driven approach to sprint planning. These insights are crucial for developers managing modern software projects, offering a robust framework for enhancing planning efficiency and success rates.

1. Introduction

Modern software applications are increasingly widespread, and the demand for high-quality software (SW) is constantly growing. Software developers are under pressure to improve efficiency, reduce development costs, adhere to delivery schedules, and meet customer satisfaction. Traditionally, software project management has followed two main methodological approaches: the hard methodological approach (unified process) and the modern soft methodological approach (agile methodology).

Agile methodologies, such as Scrum, Lean Development, and Extreme Programming, are particularly advantageous in today’s dynamic environments where customer requirements frequently change. Agile methods accommodate these changes, making them popular choices among developers. Among these, Scrum is one of the most widely adopted methodologies.

However, the Scrum method introduces certain pitfalls during the sprint planning process, particularly in selecting the right tasks for development. This decision-making process is often left to the intuition of the development team members without any mathematical or systematic method to guide task selection. Such reliance on intuition can lead to risks including conflicts of opinion, dominant personalities influencing decisions, and potential mistakes, which may result in delayed delivery, cost overruns, and customer dissatisfaction.

This research addresses this deficiency by implementing the BeCoMe method—a mathematical approach to finding the best compromise solution based on expert opinions. By integrating the BeCoMe method into the Scrum planning process, we aim to provide a mathematically verified optimal trade-off solution for task planning in each sprint. Although this solution may not always need to be applied, it is particularly useful in resolving conflicts of opinion or verifying task selections for a sprint.

The research utilizes the soft systems methodology, which is chosen for its ability to consider the human aspects of systems, recognizing that project management fundamentally involves people. This methodology helps analyze and address the complexities and human factors involved in Scrum’s planning process.

Modern agile methods are well documented in the literature, yet there remains room for improvement. This research contributes to the field by offering enhancements to the Scrum method. The findings are expected to be valuable for developers of modern software solutions, helping them reduce project risks, avoid mistakes, save time and money, and improve conflict resolution within development teams. Ultimately, this research aims to mitigate the identified risks by presenting a possible improvement for the planning process in the Scrum method.

This paper is organized into several sections. Section 1 introduces the study, providing an overview of the research context and examining relevant literature on the theoretical background. Section 2 reviews related work, highlighting recent studies on the evolution of Scrum methodology and emphasizing innovations in planning processes. Section 3 details the materials and methods, focusing on the theoretical foundations of the Soft Systems Methodology (SSM) and the BeCoMe method utilized in this research. Section 4 presents the results and demonstrates how the BeCoMe method was applied to improve the Scrum planning process through a case study. Section 5 discusses the implications of these findings, comparing the BeCoMe method with existing approaches and evaluating its impact on agile project management. Finally, Section 6 concludes the paper, summarizing the study’s contributions and suggesting avenues for future research.

1.1. Agile Methodology

Agile methodologies are project management approaches designed for the rapid and efficient development of solutions, allowing for flexible adaptation as needed. These methodologies, such as Extreme Programming, Scrum, Lean Development, and others, focus on delivering working software quickly for customer feedback, prioritizing face-to-face communication, maintaining a sustainable development pace, emphasizing simplicity, and fostering self-organized, learning-oriented teams [1,2,3,4].

1.2. Scrum Methodology

Scrum is an object-oriented development methodology where each developer is responsible for specific objects defined by their behavior and interface. Development proceeds in fixed-length intervals called sprints, typically lasting about a month, with projects generally spanning three to eight sprints. Scrum does not prescribe detailed processes within sprints but emphasizes daily Scrum meetings. These meetings summarize progress, demonstrate results, identify tasks, foster team cohesion, and support dynamic changes, replacing traditional central planning [3,4].

Risk analysis is a central concept in Scrum. Risks are assessed at the end of each iteration and during daily meetings. These risks influence iteration content, documentation, functionality, and other critical attributes [5].

Projects using Scrum are characterized by flexibility and collaboration. Deliverables adapt to environmental needs. Scheduling is flexible, acknowledging potential shifts and emphasizing realistic timelines over rigid deadlines. Teams are small (five to nine members) with larger projects divided among multiple teams. Self-organization is key, and progress is frequently reviewed both during and outside of meetings. Cooperation is vital, involving both the development team and client representatives. While Scrum does not enforce collective code ownership, team members are individually responsible for specific objects [6].

1.2.1. Scrum Specific Terms

Scrum uses several key terms crucial for its implementation. The Backlog is the project agenda, listing tasks and priorities, which are managed exclusively by the project manager and accessible to all team members. A Sprint is a developmental phase, typically 30 days long, varying based on project complexity, risks, and team size. Each sprint includes daily Scrum Meetings of 15–30 min to review progress, plan tasks, and address issues. The Scrum Master, often the project manager, moderates these meetings, though the role may rotate. These terms define the core structure of Scrum and support its practical application [7].

1.2.2. Scrum Advantages and Disadvantages

Scrum, a widely adopted agile framework, is known for its effectiveness in managing complex projects, especially in software development. Its iterative process and emphasis on team collaboration have been praised for delivering high-value products efficiently. However, Scrum also comes with its set of challenges. This chapter explores the advantages and disadvantages of Scrum, providing a comprehensive overview supported by various scientific sources.

Advantages of Scrum

Scrum enhances team collaboration and communication through regular meetings and defined roles, fostering a collaborative environment. Daily stand-ups and sprint reviews ensure all team members are aligned, leading to better team dynamics and improved project outcomes [8]. The flexibility and adaptability of Scrum allow teams to respond quickly to changes in project requirements or market conditions. This iterative nature, highlighted by Hron and Obwegeser (2022), enables continuous feedback and incremental improvements, making Scrum effective in dynamic and fast-moving project environments [9].

Frequent testing and reviews integral to the Scrum process help identify and address issues early, leading to higher-quality deliverables and reduced risk of significant defects at the end of the project [10]. The focus on value delivery ensures efficient resource utilization, as described by Schwaber and Sutherland (2020), optimizing the use of time and resources by breaking down large projects into manageable sprints [11].

Customer satisfaction is another significant advantage, as regular feedback loops and stakeholder involvement ensure the final product meets user needs and expectations. This alignment with customer-centric development practices is evident in the iterative approach of Scrum [9].

Disadvantages of Scrum

Despite its advantages, Scrum can lead to scope creep due to continuous feedback and new requirements, making it challenging to finalize the product [12]. The methodology also heavily relies on the skills and experience of the team members. Inexperienced team members may struggle with the autonomy and responsibility that Scrum requires, leading to suboptimal performance [13].

Scrum is not always suitable for large and complex projects. The need for frequent communication and collaboration can become cumbersome as team size increases, often necessitating additional frameworks like LeSS or SAFe, which can be challenging to implement [12]. The frequent meetings and continuous feedback loops in Scrum require a high level of commitment from all team members, which can be demanding and may lead to burnout if not managed properly [14].

Ensuring high quality in Scrum can be challenging, particularly in the early stages of adoption. The iterative process requires rigorous testing and validation, which can be difficult to maintain consistently [13].

1.3. Challenges in Sprint Planning and Task Definition

Sprint planning is a critical component of the Scrum framework, which is designed to ensure that teams are adequately prepared to achieve their sprint goals. However, the process of defining and assigning tasks for each sprint often presents significant challenges. Research indicates that issues such as inaccurate effort estimation, ambiguous task definitions, and misaligned sprint goals are prevalent in many Scrum implementations [8,10,11].

These challenges can lead to inefficiencies, unmet goals, and overall frustration within the team [9].

This section explores the common problems associated with sprint planning and task definition, which is supported by various scientific sources.

1.3.1. Overcommitment and Undercommitment

One of the primary challenges in sprint planning is finding the right balance between overcommitment and undercommitment. Teams often struggle to accurately estimate the effort required for backlog items, leading to sprints that are either too ambitious or too conservative. Moe et al. (2010) highlight that inaccurate effort estimation can cause sprint failures with tasks remaining incomplete or teams being underutilized [8]. Similarly, Hron and Obwegeser (2022) emphasize that modifications to Scrum often arise from the need to better align sprint goals with team capacities [9].

1.3.2. Defining Clear and Achievable Tasks

Another significant challenge is the definition of clear and achievable tasks. Tasks must be specific, measurable, achievable, relevant, and time-bound (SMART) to ensure that they can be completed within the sprint duration. Vlietland and van Solingen (2013) note that well-defined tasks contribute to better team performance and higher-quality deliverables [10]. The Scrum Guide also underscores the importance of clarity in task definition to avoid ambiguity and ensure that all team members understand their responsibilities [11].

1.3.3. Setting Realistic Sprint Goals

Setting realistic sprint goals is crucial for the success of a sprint. Goals that are too ambitious can demotivate the team and lead to incomplete sprints. Conversely, goals that are too modest can result in underutilization of team capacity. According to the Scrum Alliance, establishing a clear sprint goal helps the team stay focused and provides a benchmark for measuring progress [14]. The absence of a well-defined sprint goal can lead to aimless sprints that provide little business value, as highlighted by Applied Frameworks (2022) [15].

1.3.4. Addressing Task Dependencies

Task dependencies can complicate sprint planning, as certain tasks may need to be completed before others can begin. This interdependence requires careful planning and coordination. The Large-Scale Scrum (LeSS) framework suggests dividing the sprint planning meeting into two parts: one focused on what will be accomplished and the other on how it will be accomplished to better manage dependencies and ensure a smooth workflow [16].

1.3.5. Involvement of All Team Members

Effective sprint planning requires the involvement of all team members to ensure that everyone understands and agrees on the tasks to be completed. The GoRetro guide (2022) recommends that all relevant personnel, including the Scrum Master, Product Owner, and development team, participate in the planning meeting to provide their input and clarify any uncertainties. This collective involvement helps align the team’s efforts toward the sprint goal [17].

1.3.6. Continuous Improvement

Finally, continuous improvement through retrospectives is vital for refining the sprint planning process. By regularly reviewing what went well and what did not, teams can identify patterns and make necessary adjustments. Addressing common challenges through regular retrospectives can significantly enhance the effectiveness of sprint planning and task definition [18].

1.3.7. Problem in Scrum Method by V. Mahnic

V. Mahnic in his case study “A Case Study on Agile Estimating and Planning using Scrum” describes a problem in planning in the Scrum method, where he mentions a problem in selecting and then executing the specified plan (tasks) for a given sprint. His study shows that on average, teams complete only 42% of the scheduled cues for a sprint in the first sprint of a project. In the second sprint, this figure is higher (75.18%); however, even in this case, these are not satisfactory figures. This problem of Scrum lies in the setup of the Scrum framework, where this method leaves the planning process entirely to the intuition of the team members and relies on the self-learning process of the people [19].

2. Related Work

The evolution of Scrum methodology has attracted substantial attention in recent research, reflecting its adaptability and relevance in modern project management. Studies increasingly focus on broader trends in Scrum practices and innovations in specific processes, such as planning. Together, these insights offer a holistic view of how Scrum continues to influence and respond to contemporary challenges in agile development.

Scrum’s flexibility and effectiveness across diverse domains have been consistently highlighted in the recent literature. A bibliometric analysis by Kokol et al. (2020) traced the development of Scrum research, identifying key themes such as its application outside software development and the growing focus on team dynamics [20]. These findings align with Masood et al. (2020), who explored practical adaptations of Scrum and noted significant deviations from its theoretical framework. Such variations are often driven by organizational constraints, project-specific requirements, or team composition [21].

The effectiveness of Scrum teams has been another focal point of study. Verwijs and Russo (2022) proposed a theoretical model that emphasizes factors such as role clarity, communication, and cohesion as key determinants of team success [22].

The planning process in Scrum has emerged as a critical area of research with recent studies highlighting its central role in achieving project success. Ottaviani et al. (2023) demonstrated how data-driven planning enhances productivity and resource allocation [23]. Technological advancements have significantly influenced Scrum practices, particularly in the planning phase. Schröder (2023) introduced AutoScrum™, an AI-driven approach to automating planning tasks, which has shown promise in reducing administrative overheads and improving precision [24]. Giuseppe (2019) identified unique challenges faced by remote teams in Scrum, such as communication barriers and reduced team cohesion during planning [25].

3. Materials and Methods

3.1. Soft Systems Methodology

The research adopts a soft systems methodology due to its focus on social interaction, distinguishing it from hard methodologies. Unlike hard systems, which lack social considerations, SSM ensures solutions are socially and societally acceptable. Given that the Scrum method prioritizes people in the planning process, SSM is a more suitable approach for this research [26].

SSM involves several structured steps. The initial step, Entering the problem situation, defines the problem’s context, distinguishing between simple and complex problems [27]. The next step, Expressing the problem situation, employs the Rich Picture (RP) technique to visually represent complex problems, enhancing understanding through detailed pictorial expressions [28].

Formulating root definitions uses the CATWOE to identify critical system components, including customers, actors, transformation process, world view, owner, and environmental constraints. The CATWOE and the Rich Pictures are used to show the interactions and relationships in the system, which allows for a more understandable representation than a mere verbal evaluation [26].

Building conceptual models of human activity systems involves creating logical, graphical representations of reality based on stakeholder views. These models, informed by practices like E-R diagrams, illustrate the relationships and structures of relevant entities [29].

Comparing the models with the real world: Conceptual models are used to compare the created models with reality and evaluate the feasibility of changes in practice [28].

Defining changes that are desirable and feasible: Based on the above-mentioned steps, i.e., describing the problem, building a conceptual model, and especially the above-mentioned comparison with the real world, socially acceptable solutions are defined [28].

Taking action to improve the real-world situation involves using SSM as a learning system to address unstructured problems in organizational or social contexts. By incorporating diverse worldviews, SSM fosters a deeper understanding of the problem, leading to varied outcomes. The issue may dissolve through consensus, result in an informal solution (e.g., role redefinition), or transform into a structured “hard” problem with a clear resolution path [29].

3.2. Decision-Making Process

Decision making is the process of making choices by gathering information, assessing alternative resolutions, and identifying a decision. Using a decision-making process can help make more deliberate, thoughtful decisions by organizing relevant information and defining alternatives. This approach increases the chances that the most satisfying possible alternative will be chosen [30].

Multi-Criteria Decision Making

Multi-criteria decision making includes multi-criteria variant analysis, which explicitly enumerates all considered options, and multi-criteria programming. These methods aid complex decisions by evaluating multiple criteria. The primary goal is to select or rank options based on defined preferences [31].

3.3. Method BeCoMe

BeCoMe is a method of multi-criteria optimization. BeCoMe is the maximum-agreement-mean method, which can find the best compromise solutions in group decision-making tasks. It aggregates expert opinions while focusing on points of agreement. It can minimize Shannon entropy to optimize results, it has a low level of computational and conceptual complexity, it yields easy-to-interpret results, it has an indicator of accuracy, and it does not require a specialized software. It can improve decision processes in software development methods [32] in all situations when individual expert opinions were contradictory.

The BeCoMe method is superior to methods that use generalized averaging operators; in particular, it has the following advantages:

• It can find the best possible theoretical compromise;

• In addition to providing quantitative results, it can be used to qualitatively assess the aspects of the problem that cannot be quantified. It can also be used to select the most suitable solution among several presented options;

• The experts can express their opinions by using real numbers, fuzzy numbers, or by using Likert linguistic terms;

• The time cost is minimized, as a final solution can be immediately obtained following input of the variables;

• The most important advantage of the BeCoMe method is its simplicity, as all of the decision-making process parameters can be easily calculated without any specialized software. More specifically, all necessary calculations can be performed by using a Microsoft Excel spreadsheet program which is free and publicly available at https://covid19-become.pef.czu.cz/en (accessed on 20 October 2024).

• A direct consequence of this simplicity is the conceptual clarity of the BeCoMe method, as it yields easy-to-interpret results. Ease of use is a prerequisite for an unencumbered level of agility in project management and one of reasons why it could be used as a “soft” solution [32].

The result of BeCoMe: (πφξ) is calculated in the following steps, according to [32].

1. Collect the triangular experts’ judgments, AiCiBi, where Ai, Ci, Bi are vertices of the i-th triangular fuzzy number.

2. Calculate arithmetic mean Γ: (αγβ):

(1) $$\begin{gathered} \alpha =1/M{\sum }_{k=1}^M{\mathrm{A}}_{\mathrm{k}} \\ \beta =1/M{\sum }_{k=1}^M{\mathrm{B}}_{\mathrm{k}} \\ \gamma =1/M{\sum }_{k=1}^M{\mathrm{C}}_{\mathrm{k}}. \end{gathered}$$

• 3.. Calculate center of mass Gx (centroid) for each triangle AiCiBi:

Gx = (A + B + C)/3.(2)

• 4.. Rank experts with respect to their centroids.

• 5.. Select median Ω: (ρωσ) as the triangle that is in the middle of all triangles AiCiBi, according to ρ = Aq, ω = Cq, and σ = Bq when the number of experts is an odd number, or when M = 2n is an even number, the center of the set of triangular fuzzy numbers AiCiBi lies between fuzzy numbers ApCpBp and ArCrBr, where p refers to zi = n and r refers to zi = n + 1.

The median is the arithmetic mean of fuzzy numbers ApCpBp and ArCrBr. In this case:

(3)$$\begin{gathered} \rho =(\mathrm{A}\mathrm{p}+\mathrm{A}\mathrm{r})/2 \\ \sigma =(\mathrm{B}\mathrm{p}+\mathrm{B}\mathrm{r})/2 \\ \omega =(\mathrm{C}\mathrm{p}+\mathrm{C}\mathrm{r})/2. \end{gathered}$$

• 6.. Calculate ΓΩMean: (πφξ):

(4) $$\begin{gathered} \pi =(\alpha +\rho )/2=1/2M{\sum }_{k=1}^M\mathrm{A}\mathrm{k}+\rho /2 \\ \phi =(\gamma +\omega )/2=1/2M{\sum }_{k=1}^M\mathrm{B}\mathrm{k}+\omega /2 \\ \xi =(\beta +\sigma )/2=1/2M{\sum }_{k=1}^M\mathrm{C}\mathrm{k}+\sigma /2. \end{gathered}$$

• 7.. Calculate maximum error Δmax:

Δmax = (αγβ + ρωσ)/2.(5)

The BeCoMe software tool can be used to facilitate calculations in searching for a compromise. The software for all calculations in the BeCoMe method as an Excel spreadsheet program is presented for two possible situations: an even or odd number of experts, respectively, agents in this case [32].

The problem addressed in this article is a social problem in which people play a major role. Hence, the outcome of the research should provide a “soft” socially acceptable solution. It might seem that implementing a hard mathematical method (BeCoMe) could compromise the softness of the output. Instead of relying on people’s reasoning (intuition), they would be required to use a mathematical method.

However, the research outcome does not contradict the theory of soft systems methodology because the BeCoMe method incorporates expert opinions from the entire group, allowing them to express their findings in several ways (real numbers, fuzzy numbers, using Likert linguistic terms). Its calculation is extremely simple and fast. The expert opinions for the calculation are compiled by the whole group, preventing a dominant person from pushing the decision in their direction. Therefore, it is assumed that it would minimally burden the development team. Moreover, the results of the computation can be taken as a recommendation, effectively serving as “another opinion” in the discussion.

4. Results

4.1. Problem Statement

There is a lot of risk involved in the planning and selection process because the entire Scrum team has to select the right User Stories with respect to the selected criteria. Currently, it relies on the intuition of team members, with no defined exact method for selecting the right user stories, leaving much to chance. This research aims to eliminate this problem in planning Scrum sprints as much as possible.

Choosing inadequate user stories can jeopardize the entire project. The development team may be delayed in their work, extending the deadline for delivering the finished software. This results in development costs that can significantly exceed the agreed amount. Another risk is failing to meet the brief, thus delivering software to the customer that does not perform its function and is therefore unusable. In such cases, the software would have to be redesigned, again exceeding the budget and delivery date. All of this leads to customer dissatisfaction with the development team’s services and can greatly demotivate team members.

There can be several problems in the planning process for the next sprint. The main issue is that Scrum currently does not define any mathematical method to properly select tasks for the next sprint. This selection is left to the intuition of the participating Scrum team members and their joint agreement, which should result in some compromise.

In this planning step, there is a risk that the task assignments will not be based on a general consensus of all participating experts in the team but rather on a compromise influenced by the most dominant individuals. This can easily steer the project in the wrong direction, resulting in failure. This problem can also affect the level of agility of the project and the team as a whole, as less dominant individuals may feel unappreciated and reluctant to express their opinions, leading to a significant drop in their motivation.

These less dominant individuals may feel unappreciated, as though it is unnecessary to express their opinions, and, in some cases, fearful, because their opinions are being overruled by stronger individuals on the team. Such situations can lead to unwanted conflicts within the team. In the planning process of the Scrum method, there is a risk of conflicting views and subsequent conflicts between individuals. It is necessary to make the right decision and choose the best possible compromise. Finally, people often make decisions based on their emotions and feelings, which can lead to poor sprint planning.

4.2. Rich Picture

The Rich Picture (see Figure 1) shows the planning process in the Scrum software project management method. In the planning phase, the tasks from the general assignment (backlog) for the next sprint are determined.

4.3. CATWOE

Based on the formulation of the problem, it is necessary to analyze the inputs and outputs of the process for subsequent representation using the Rich Picture method.

• System: the process of planning Scrum sprint and choosing the right tasks for sprint;

• Input: tasks, people, expert opinions;

• Output: assignment of tasks for sprint.

C—Customer: The customer is the customer of the software. The customer wants quality software that is good and functional. The customer wishes to receive this work within a specified time and for a specified amount. The customer is willing to work with a software development team to develop the software.

A—Actor: The actors of the process include all those who carry out the system’s activity and whose activities the system depends on. Therefore, they are developers, product owner, Scrum master, stakeholders, Scrum team members and customer, because the customer is involved to some extent in the development of the software.

T—Transformation process: This includes all activities and activities that ensure the conversion of inputs into outputs. In this case, the Transformation process means the planning process where tasks from the overall assignment (backlog) are taken as inputs; then, people enter the process with their expert opinions and select the best possible tasks from the prepared tasks for the next sprint (assignment of tasks for sprint).

W—Worldview: Selecting the optimal tasks for sprint for the most efficient software development.

O—Owners: Customer, SW company management.

E—Environmental constraints: The right level of motivation for team members, a well-informed customer involved in the development process, proper Scrum setup, working conditions and working environment.

4.4. Conceptual Model

In this part, a conceptual model (see Figure 2) for the following definition is implemented. “The system allows the development team to adjust the decision-making process in the sprint planning phase using the BeCoMe method, thereby reducing the risk of project failure by selecting the right tasks for sprint” where in order to be able to meet the given definition for the system, it must be able to implement the following activities:

• Compilation of evaluated expert opinions on the tasks of the development team (Compilation of scope of expert opinions);

• Calculation by BeCoMe method and construction of optimal task assignment for sprint.

4.5. Comparison of Conceptual Model with Reality

This section compares the conceptual model according to the following basic definition with reality (see Table 1): “The system allows the development team to adjust the decision-making process in the sprint planning phase using the BeCoMe method, thereby reducing the risk of project failure by selecting the right tasks for sprint”.

4.6. Solution of Problem and Application of Desired Changes

Based on these conclusions, the solution to this formulated problem is to implement the BeCoMe method in the sprint planning phase (see Figure 3). BeCoMe is the maximum-agreement-mean method, which can find the best compromise solutions in group decision-making tasks. It aggregates expert opinions while focusing on points of agreement. This method would reduce the risk associated with incorrectly selecting tasks for the next sprint according to the selected criteria. After aggregating the expert opinions of the entire development group, this method would select the best compromise solution and thus define the tasks for the next development sprint. The development team should always select relevant tasks for the sprint to address during the period, following an agile methodology that specifies doing only those tasks that are necessary at the moment and not any others.

During the planning phase, the development team should establish certain criteria by which they want to proceed. Evaluate the tasks against these criteria and select those that are relevant. In the classic definition of the Scrum method, this selection is determined by the intuition of the Scrum team members. The possible diversity of expert opinions can introduce a certain amount of uncertainty and risk. In this case, that risk would be mitigated by a method that mathematically derives the best compromise solution based on the expert knowledge of the team members. The BeCoMe method, which finds the best compromise solution in a few easy steps, is well suited to this mathematical expression. This would reduce risk and improve the flow of development as a whole.

The collection of expert opinions within the team could be anonymous. This would ensure that each expert has a voice and that their level of motivation and responsibility is not diminished. This way of assembling the tasks for the next sprint can also eliminate the risk of conflicts between developers in the sprint planning phase. By aggregating the views of all team members, the findings from the BeCoMe method can resolve conflicts between the different viewpoints of the experts in the team.

To summarize: As shown in the problem solution diagram (Figure 3: Solution of problem), the first step in the Scrum planning process in the modified solution is to build a scope of expert opinions for the BeCoMe method. The BeCoMe method is then used to construct the optimal task assignment from this scope of expert opinions to determine the best possible compromise solution from the expert opinions.

4.7. Case Study—Conflict Resolution in Sprint Planning Using BeCoMe Method

In this section, a case study is presented to illustrate the application of the solution from this research. This solution is suitable for use in any Scrum-driven software project where it is necessary to resolve an opinion dispute, incorporate the opinions of the entire team, and validate the decision (that is, whenever expert opinions are not unanimous). BeCoMe will unify the opinion directions and offer the best compromise solution. The solution is not tied to the exact size of the development team, company, etc. It can be used whenever there is a need to make an effective decision within the best possible compromise.

This case study demonstrates the solution to the problem outlined in this research using an enhancement presented in the conceptual model (see Figure 2). This solution was tested in an anonymous software company with 126 employees. The research involved a team consisting of five developers (programmers), two designers (UI/UX + design), a software architect, a project manager, and a product owner. This was the first time the development team in this composition worked together (it was their first common project). This team was in charge of an extensive project aimed at delivering a web-based complex customer management (CRM) software for the customer. The preliminary time horizon for delivering fully functional software was set at 8 months with the length of an average sprint set at 2 weeks.

4.7.1. Choosing the Right Tasks for Sprint

A conflict arose when setting up the tasks for the next sprint. The entire team was unable to reach a unanimous agreement on selecting the appropriate tasks for the fourth sprint in the project. To construct the best compromise sprint assignment, the team utilized the results of this research and employed the BeCoMe method to select the correct tasks. The BeCoMe method can find the best compromise solution using a Likert scale of 0–25–50–75–100 (Strongly disagree/Rather disagree/Neutral/Rather agree/Strongly agree). A preliminary broad assignment of 15 tasks was selected, for which there was a general consensus that they could be considered for the next sprint.

The question for each task under consideration was as follows: “Rate whether the task [task name] belongs in the next sprint on a Likert scale of 0–25–50–75–100 (Strongly disagree/Rather disagree/Neutral/Rather agree/Strongly agree)”. Each team member then anonymously rated the prepared tasks using this Likert scale.

By integrating the BeCoMe method into the sprint planning process, the team could effectively resolve conflicts and make more data-driven decisions, enhancing the overall efficiency and effectiveness of their project management approach.

The Table 2 shows the results of the team’s investigation. Each task was rated by each team member on a scale of 0–100 (Strongly disagree—Strongly agree). The answers obtained were entered into the BeCoMe calculation, and each task received its rank-rating, determining the common consensus and the best compromise solution for the entire team.

From this knowledge gained, further progress can be made, and agile team discussions can take place to compose the tasks for the next sprint. However, in this particular case, the team could not agree on the exact number of tasks for the next sprint. The resolution of this additional conflict situation is described in the second part of this case study, Section 4.7.2.

4.7.2. Selection of the Correct Number of Tasks for the Next Sprint

The team had to resolve a conflict of opinion on the ideal number of scheduled tasks for the fourth sprint of the project and find the best compromise. The question was “What is the ideal number of tasks for fourth sprint from a list of relevant tasks that could be implemented in this sprint?” To resolve this conflict, the solution of implementing the BeCoMe method was used.

The advantage of the BeCoMe method is that experts (team members) can express their standpoints in three ways: (1) as a crisp number; (2) as a fuzzy number in a format: Preferable value, Lower limit, Upper limit; and (3) as a quantity in the Likert scale: “Strongly disagree”, “Rather disagree”, “Neutral”, “Rather agree”, “Strongly agree” or a similar linguistic scale.

A list of relevant tasks that could be implemented in the second sprint was compiled. Furthermore, an interval <5;15> for the number of tasks in the second sprint of the project was designed. The team members chose the ideal number of tasks from a pre-prepared list of tasks they could potentially implement in the second sprint.

Team members were asked their opinion on the following:

• Best proposal for sprint 2 (see Figure 4);

• The lower limit of feasible tasks for sprint 2;

• The upper limit of feasible tasks for sprint 2.

Figure 4 illustrates the simplicity of the BeCoMe calculation (determining the best compromise solution). To obtain the result, all one has to do is to enter the individual expert opinions into a table in the BeCoMe Excel software.

Figure 4 shows step 1 of the BeCoMe calculation from Section 3.3 of this paper, where expert opinions were constructed using triangular fuzzy numbers. Next, the figure shows the values of step 3, i.e., the computation of the centroids of each expert opinion Gx. The intermediate results of step 2 of the BeCoMe calculation are $\alpha =6.6$, $\beta =12$, $\gamma =9.4$. In step 5, the median is solved, and the calculations of this step are ρ = 6.5, σ = 11.5, ω = 8.5. In the last step (step 5) before calculating the maximum deviation, the results are π = 6.6, φ = 11.75, ξ = 8.95. Max. The error of estimate can be seen in Figure 4, where its value is 0.27. The result of BeCoMe and the value of the best compromise solution from the given triangular fuzzy numbers is 9.1. From this value, we can deduce that the best possible compromise is the value of nine tasks for the next sprint.

As shown in Figure 4, the expert team answered the question using a fuzzy number in a format: Preferred value, Lower limit, Upper limit. While following the principle of agile methodologies, an important attribute is the communication between each team member, where each voice has the same level of importance. The equal weight of each team member’s rating was set to level 1. Figure 5 shows a graphical representation of the decision situation, where the opinions of each team member for the BeCoMe method are represented using a triangular membership function.

As can be seen in Figure 4, the BeCoMe method resulted in an ideal number of nine tasks for the second sprint. This result contradicted the conclusion from the previous team sprint planning, where the unconfirmed conclusion was 13 tasks for the sprint. This conclusion was skewed by the dominant person, the project manager, who was under pressure from the management to meet the set timelines and so tried to push through unrealistic targets.

Poorly chosen decisions that are not based on the best compromise of the whole team’s opinions can have a very negative impact on the mood and motivation of the development team. This can lead to suboptimal adherence to project goals. The solution is time saving, and the results are based on the opinions of all team members, representing the best compromise. The solution presented in this research can be easily applied in any project using the Scrum method where a conflict of opinion arises or when there is not complete agreement on the chosen solution and it needs to be verified.

5. Discussion

In Mahnic’s case study, he evaluated the proportions regarding the duration of selected specific tasks within the sprint with respect to others. He reported on the development team’s performance in completing scheduled tasks by sprint: “The teams completed on average only 42% (median 35.71%) of story points (tasks) planned for the first sprint and spent on average much more than one ideal day of work per story point (mean value 27.86, median 15.88 h/story point)” [19]. He further states that in each subsequent sprint, the percentage of tasks completed increases. In the second sprint, the percentage of successfully completed tasks planned for the sprint was around 75% and continued to increase in subsequent sprints. However, the value of successfully completed tasks scheduled for the first sprint (42%) is trivial, and the value in the second sprint is also far from ideal [19].

These issues highlight significant reasons for the failure of projects managed by the agile Scrum method. Project failure is defined as the inability to deliver the completed functional work on time and within the specified cost. The proper scheduling of sprint tasks appears to be one of the most critical phases of project management in Scrum. It can be concluded that leaving such an important phase of project management to human intuition is extremely inadequate. To address this shortcoming of the Scrum method, the implementation of the BeCoMe method could serve perfectly. BeCoMe is a mathematical method for selecting the best compromise solution in a few simple steps.

The BeCoMe method provides a very fast calculation in situations where an accurate and rapid compromise solution is needed. Another advantage is that experts can express their opinions using real numbers, fuzzy numbers, or Likert linguistic terms. The use of the above-mentioned method is useful in conflict situations that arise in non-cohesive developer teams or larger teams. The BeCoMe method will offer the right compromise solution quickly and steer the developers in the right direction for the next sprint.

However, to fully leverage the advantages of BeCoMe, a few more steps need to be incorporated into the planning process. The first step is to compile an assignment of valued expert opinions. Then, based on this assignment, the second step involves performing the computation using the BeCoMe method to compile the final verified task assignment for the sprint. The question remains of how these added steps will affect the agility level of the project. It would be ideal if this research were further extended to address this question.

On the other hand, the results show that this improvement in the planning process of each sprint brings an equal evaluation of the votes of all team experts, thus fulfilling one of the agile principles. Moreover, this step is not mandatory, and not all sprints in the project need to be planned this way. This step can be utilized in rare situations where the entire team cannot unanimously agree on the assignment for the next sprint.

A further extension of the research could involve providing precise guidance on the implementation of the BeCoMe method in the Scrum planning process and determining its impact on the success rate of project management.

In addition to evaluating the BeCoMe method, it is important to compare it with similar existing methods like Weighted Shortest Job First (WSJF) used in the Scaled Agile Framework (SAFe). WSJF prioritizes tasks based on their cost of delay divided by job size, balancing urgency and effort required. While WSJF is useful for large-scale agile projects, it has limitations in ensuring team consensus and managing diverse opinions effectively [33,34,35].

Consensus Building:

WSJF: WSJF does not inherently address the need for consensus among team members, and it is often driven by key stakeholders, which might lead to a lack of buy-in from all team members [33].

BeCoMe: BeCoMe excels by utilizing a structured process to aggregate individual team members’ opinions through the Likert scale, ensuring selected tasks reflect a collective agreement, thus increasing team commitment and motivation.

Objectivity in Task Selection:

WSJF: WSJF relies heavily on the accurate estimation of cost of delay and job size, which can be subjective and prone to biases [34].

BeCoMe: By employing a Likert scale and a straightforward calculation process, BeCoMe reduces subjectivity and biases, leading to a more objective selection.

Flexibility and Adaptability:

WSJF: WSJF is flexible and adapts to changing business needs but may not incorporate continuous feedback from the entire team during prioritization [35].

BeCoMe: BeCoMe maintains agility by incorporating regular feedback from all team members, allowing for the continuous adjustment and refinement of task priorities, aligning well with agile principles.

Overall, this discussion highlights the benefits of integrating the BeCoMe method into the Scrum planning process, offering a structured and objective approach to task selection. Compared to WSJF, BeCoMe ensures greater team consensus, reduces biases in task prioritization, and maintains flexibility and adaptability. Future research should focus on refining the implementation process of BeCoMe within Scrum and empirically evaluating its impact on project success rates.

6. Conclusions

If development by Scrum is viewed as a system, it can be concluded that this system hides certain pitfalls and gaps that carry a degree of uncertainty and risk. Systemically, Scrum predetermines the phases of development, such as planning, sprint assignment creation, development and implementation, review, and retrospective. In this system, software development is taken as a transformation process, where people transform their expert knowledge, using hardware, into source code, and this code then describes the final software that is delivered to the customer.

Developers aim to deliver working software to the customer on time and within budget. However, when using the Scrum method, there are risks between the different phases that can jeopardize the smooth delivery of the application to the customer. The biggest risk lies in the planning and drafting of the brief for each sprint, where developers currently rely on their possibly diverse intuition.

The research presented in this article highlights the limitations and challenges associated with the current sprint planning process in the Scrum methodology. A comprehensive literature review identified significant issues in the planning phases of individual sprints, including the reliance on team members’ intuition and subjective judgment, leading to inefficiencies and conflicts. Building on these findings, this study proposed the integration of the BeCoMe method as a structured approach to enhance the sprint planning process.

The BeCoMe method provides a structured and objective way to aggregate expert opinions and determine the most appropriate tasks for each sprint. This approach minimizes the risks associated with human error and bias, ensuring that task selection is based on a balanced and data-driven process. By using a Likert scale to evaluate tasks and employing a straightforward calculation process, BeCoMe enhances the decision-making framework within Scrum without compromising the agility and flexibility that are core to agile methodologies.

The application of the BeCoMe method in a real-world case study demonstrated its effectiveness in resolving conflicts and improving the overall efficiency of the sprint planning process. The development team was able to reach a consensus on task selection, leading to better-aligned sprint goals and improved project outcomes. This case study underscores the potential benefits of incorporating mathematical methods like BeCoMe into agile project management practices.

Furthermore, real-world systems are often influenced by numerous ambiguous and unpredictable factors, complicating planning, forecasting, and decision making. Decision-making processes in such contexts depend heavily on the expertise and perspectives of team members, with the composition and expertise level of the team playing a crucial role in the quality of outcomes. Where necessary, additional specialists can be involved to provide subject matter expertise, ensuring well-informed and effective solutions. By incorporating structured methods like BeCoMe, organizations can navigate these complexities with greater precision and confidence, enhancing the overall effectiveness of agile project management [32].

Future research should focus on further refining the implementation process of the BeCoMe method within Scrum, including the development of detailed guidelines and best practices. Additionally, the impact of this approach on the overall agility and success rate of projects should be empirically evaluated. By addressing these areas, the research can provide more robust evidence of the benefits and practical applications of integrating BeCoMe into Scrum, ultimately contributing to more effective and efficient software development processes.

Author Contributions

Conceptualization, M.Ž. and I.V.; methodology, M.Ž.; validation, M.Ž. and A.H.; formal analysis, A.H.; investigation, M.Ž.; resources, M.Ž.; data curation, M.Ž.; writing—original draft preparation, M.Ž.; writing—review and editing, M.Ž., A.H., J.T.; supervision, J.T. and I.V.; project administration, M.Ž., J.T.; funding acquisition, J.T. All authors have read and agreed to the published version of the manuscript.

Institutional Review Board Statement

Not applicable.

Informed Consent Statement

Not applicable.

Data Availability Statement

The raw data supporting the conclusions of this article will be made available by the authors on request.

Acknowledgments

The authors thank the Faculty of Economics & Management Czech University of Life Sciences and the IGA Foundation of the Faculty of Economics and Management for their support of this research.

Conflicts of Interest

The authors declare no conflicts of interest.

Footnotes

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.

Figures and Tables

Figure 1. A problem in the Scrum planning process captured by Rich Picture.

Figure 2. Conceptual model.

Figure 3. Solving a problem in the sprint planning process using the BeCoMe implementation shown in Rich Picture.

Figure 4. Team members suggestions with BeCoMe result.

Figure 5. Graphical expression of the decision situation.

Table 1

Comparison current process and solution from the conceptual model.

Activities	Current Process			Solution from the Conceptual Model
	How Is ItImplemented?	Responsible Person	Quality ofExecution	How Is ItImplemented?	Responsible Person	Quality ofExecution
(A) Choosing the right tasks for the sprint	Based on the intuition of the Scrum team	Project managerScrum team	Not Good	Implementation of the BeCoMe mathematical method for selecting the best possible compromise solution	Project managerScrum team	Optimized
(B) Elimination of human feelings/emotions/characters in planning sprints	It is not implemented in the current process			Implementation of methodBeCoMe for choosing the right tasks based on all expert opinions	Project managerScrum team	Improved
(C) Verification of decision	It is not implemented in the current process			Implementation of the BeCoMe for selecting the best mathematical verifiedcompromise solution	Project managerScrum team	Improved

Table 2

BeCoMe results based on expert evaluation of the individual tasks.

Task		Best Compromise	Max. Error of Estimate	Include in Assignment
1	Email System Integration—Receiving Emails:Implement functionality for receiving emails into the CRM.	94.5	0.5	YES
2	Email System Integration—Sending Emails:Implement functionality for sending emails from the CRM.	93.5	1.5	YES
3	Notifications—New Lead:Implement notification for the creation of a new lead.	68.65	1.35	YES
4	Notifications—Lead Status Change:Implement notification for the status change in an existing lead.	68	0.5	YES
5	Database Optimization—Table Review:Review and optimize the structure of database tables.	75.95	4.05	YES
6	Database Optimization—Implement Indexes:Add and optimize indexes in the database.	72.75	2.25	YES
7	User Roles—Define Roles:Define various user roles and their permissions.	84.25	0.75	YES
8	User Roles—Access Control Implementation:Implement access control based on the defined roles.	60.75	0.75	NO
9	Workflow Automation—Sales Process Templates:Create and implement a workflow template for a typical sales process.	89.5	0.5	YES
10	Workflow Automation—Task Escalation:Implement rules for automatic task escalation when deadlines are missed.	88.75	1.25	YES
11	Data Export—CSV Format:Implement functionality for exporting data to CSV format.	56	1.5	NO
12	Data Import—CSV Format:Implement functionality for importing data from CSV files.	58.5	1.5	NO
13	Mobile Application—Contact Synchronization:Implement contact synchronization between the mobile app and the web CRM.	62	4.5	NO
14	Mobile Application—Lead Display:Implement lead display in the mobile application.	55	5	NO
15	Dashboard—Sales Report:Create a basic sales report on the dashboard.	68.25	0.75	YES

References

1. Cohen, D.; Lindvall, M.; Costa, P. An Introduction to Agile Methods. Adv. Comput.; 2004; 62, pp. 1-66. [DOI: https://dx.doi.org/10.1016/s0065-2458(03)62001-2]

2. Strode, D. Agile methods: A comparative analysis Agile method: A comparative analysis. Proceedings of the 19th Annual Conference of the National Advisory Committee on Computing Qualifications 2006, NACCQ; Wellington, New Zealand, 7–10 July 2006; pp. 257-264. Available online: https://www.academia.edu/2376909/Agile_methods_a_comparative_analysis?utm_source=chatgpt.com (accessed on 20 October 2024).

3. Saeedi, K.; Visvizi, A. Software Development Methodologies, HEIs, and the Digital Economy. Educ. Sci.; 2021; 11, 73. [DOI: https://dx.doi.org/10.3390/educsci11020073]

4. Rising, L.; Janoff, N.S. The Scrum Software Development Process for Small Teams. IEEE Softw.; 2000; 17, pp. 26-32. [DOI: https://dx.doi.org/10.1109/52.854065]

5. Mahmoudi, S.; Kashanian, H.; Farsad, M.G. Agility in Project Management Phases by Scrum Method. Int. J. Comput. Appl. Technol. Res.; 2017; 6, pp. 417-421. [DOI: https://dx.doi.org/10.7753/IJCATR0609.1001]

6. Booch, G.; Maksimchuk, R.; Engle, M.; Conallen, J.; Houston, K.; Young, B. Object-Oriented Analysis and Design with Applications; Pearson Education: London, UK, 2007.

7. Mahnič, V.; Vrana, I. Using Stakeholder-Driven Process Performance Measurement for Monitoring the Performance of a Scrum-Based Software Development Process. Elektroteh. Vestn.; 2007; 74, pp. 241-247. Available online: https://www.semanticscholar.org/paper/Using-stakeholder-driven-process-performance-for-of-Vrana/df95261b7e8195c4493a89155cbf06128b32ad8d (accessed on 20 October 2024).

8. Moe, N.B.; Dingsøyr, T.; Dybå, T. A Teamwork Model for Understanding an Agile Team: A Case Study of a Scrum Project. Inf. Softw. Technol.; 2010; 52, pp. 480-491. [DOI: https://dx.doi.org/10.1016/j.infsof.2009.11.004]

9. Hron, M.; Obwegeser, N. Why and how is Scrum being adapted in practice: A systematic review. J. Syst. Softw.; 2022; 183, 111110. [DOI: https://dx.doi.org/10.1016/j.jss.2021.111110]

10. Vlietland, J.; van Solingen, R. A maturity model for scaling agile development. Proceedings of the 2013 International Conference on Software Engineering; San Francisco, CA, USA, 18–26 May 2013; pp. 3-12.

11. Schwaber, K.; Sutherland, J. The Scrum Guide, Scrum.org. 2020; Available online: https://www.scrum.org/resources/scrum-guide (accessed on 20 October 2024).

12. Project Cubicle. Advantages and Disadvantages of Scrum. Available online: https://www.projectcubicle.com/advantages-and-disadvantages-of-scrum/ (accessed on 20 October 2024).

13. Project Practical. Advantages and Disadvantages of Scrum Methodology. Available online: https://www.projectpractical.com/advantages-and-disadvantages-of-scrum-methodology/ (accessed on 20 October 2024).

14. Scrum Alliance. Sprint Planning Meeting: Why It’s Critical for Agile Success, Scrum Alliance. 2022; Available online: https://resources.scrumalliance.org/Article/sprint-planning-meeting (accessed on 20 October 2024).

15. Applied Frameworks. The Secrets of Effective Sprint Planning—Applied Frameworks, Applied Frameworks. 2022; Available online: https://appliedframeworks.com/blog/the-secrets-of-effective-sprint-planning (accessed on 20 October 2024).

16. Larman, C.; Vodde, B. Sprint Planning—Large Scale Scrum (LeSS), Less. 2021; Available online: https://www.craiglarman.com/wiki/downloads/Book%20Large-Scale%20Scrum%20-%20More%20with%20LeSS/Large-Scale%20Scrum%20-%20More%20with%20LeSS%20-%20Chapter%202%20-%20LeSS.pdf (accessed on 20 October 2024).

17. GoRetro. Sprint Planning Guide Part 4—Starting with Scrum, GoRetro. 2022; Available online: https://www.goretro.ai/post/scrum-sprint-planning-guide (accessed on 20 October 2024).

18. Do Async. Common Challenges Faced by Scrum Teams, Do Async. 2022; Available online: https://doasync.com/blog/common-challenges-faced-by-scrum-teams/ (accessed on 20 October 2024).

19. Mahnic, V. A Case Study on Agile Estimating and Planning Using Scrum. Electron. Electr. Eng.; 2011; 111, pp. 123-128. [DOI: https://dx.doi.org/10.5755/j01.eee.111.5.372]

20. Kokol, P.; Zagoranski, S.; Kokol, M. Software Development with Scrum: A Bibliometric Analysis and Profile. Libr. Philos. Pract.; 2020; Available online: https://digitalcommons.unl.edu/cgi/viewcontent.cgi?article=8831&context=libphilprac (accessed on 20 October 2024).

21. Masood, Z.; Hoda, R.; Blincoe, K. Real World Scrum: A Grounded Theory of Variations in Practice. IEEE Trans. Softw. Eng.; 2020; 48, pp. 1579-1591. Available online: https://ieeexplore.ieee.org/document/9201058 (accessed on 20 October 2024). [DOI: https://dx.doi.org/10.1109/TSE.2020.3025317]

22. Verwijs, C.; Russo, D. A Theory of Scrum Team Effectiveness. IEEE Trans. Softw. Eng.; 2022; 32, pp. 1-51. Available online: https://www.researchgate.net/publication/351901304_A_Theory_of_Scrum_Team_Effectiveness (accessed on 20 October 2024). [DOI: https://dx.doi.org/10.1145/3571849]

23. Ottaviani, F.M.; Sillitti, A.; Succi, G. Improving Scrum-Managed Project Planning through Productivity Analysis. Proceedings of the 27th International Congress on Project Management and Engineering; Donostia-San Sebastian, Spain, 10–13 July 2023; Available online: https://www.researchgate.net/publication/375061319_Improving_Scrum-Managed_Project_Planning_through_Productivity_Analysis (accessed on 20 October 2024).

24. Schröder, M. AutoScrum™: Automating Project Planning Using Language Model Programs. arXiv; 2023; arXiv: 2306.03197v1

25. Giuseppe, C.N. A Study of an Agile Methodology with Scrum Approach to the Filipino Capstone Program. Int. J. Comput. Sci. Res.; 2019; 2, pp. 68-88. Available online: https://www.stepacademic.net/ijcsr/article/view/82/45 (accessed on 20 October 2024).

26. Checkland, P.; Poulter, J. Learning for Action a Short Definitive Account of Soft Systems Methodology, and Its Use for Practitioners, Teachers and Students; Wiley: Hoboken, NJ, USA, 2006.

27. Md Saad, N.H.; Kasimin, H.; Alias, R.A.; Rahman, A.A. Soft Systems Methodology: A Conceptual Model of Knowledge Management System Initiatives. Commun. Comput. Inf. Sci.; 2013; 415, pp. 377-392. [DOI: https://dx.doi.org/10.1007/978-3-642-54105-6_25]

28. Bell, S.; Morse, S. How People Use Rich Pictures to Help Them Think and Act. Syst. Pract. Action Res.; 2012; 26, pp. 331-348. [DOI: https://dx.doi.org/10.1007/s11213-012-9236-x]

29. Wilson, B.; Haperen, K.v. Soft Systems Thinking, Methodology and the Management of Change; Palgrave: London, UK, 2015.

30. Lunenburg, F. The decision making process. Natl. Forum Educ. Adm. Superv. J.; 2010; 27, 4.

31. Triantaphyllou, E. Multi-Criteria Decision Making Methods: A Comparative Study; Kluwer Academic Publishers: Dordrecht, The Netherlands, Boston, MA, USA, 2000.

32. Vrana, I.; Tyrychtr, J.; Pelikán, M. BeCoMe: Easy-To-Implement Optimized Method for Best-Compromise Group Decision Making: Flood-Prevention and COVID-19 Case Studies. Environ. Model. Softw.; 2021; 136, 104953. [DOI: https://dx.doi.org/10.1016/j.envsoft.2020.104953]

33. Reinertsen, D.G. The Principles of Product Development Flow: Second Generation Lean Product Development; Celeritas Publishing: Redondo Beach, CA, USA, 2009; Available online: https://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009 (accessed on 20 October 2024).

34. Knaster, R.; Leffingwell, D. SAFe 5.0 Distilled: Achieving Business Agility with the Scaled Agile Framework; Addison-Wesley Professional: Boston, MA, USA, 2020.

35. Leffingwell, D. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise; Addison-Wesley Professional: Boston, MA, USA, 2010; Available online: https://www.amazon.com/Agile-Software-Requirements-Requirements-Addison-Wesley/dp/0321635841 (accessed on 20 October 2024).