DECISION SUPPORT TECHNOLOGY FOR SPRINT PLANNING

.


IS is an
x is a selection indicator of i -th US for implementation in the sprint; TP is a team performance; q w is a weight coefficient of q -th key performance indicator; q u is an utility function; q KPI is a value of q -th key performance indicator; worst q KPI is a worst value from set of values of q -th key performance indicator; best q KPI is a best value from set of values of q -th key performance indicator.

INTRODUCTION
The attractiveness of Ukraine in the world market of software development services for foreign companies is constantly growing.The IT share in GDP of Ukraine is 4% by the start of 2019 and it is raising [1].The number of IT companies, complexity of IT projects, requirements for quality and skills of specialists are increasing.As a result, the software development process is making more and more complex.On the one hand, this process is characterized by the complexity of coordination of ITprofessionals, where each member of the team has different experience and qualifications.On the other hand, it is necessary to take into account a large number of require-ments from users of future programs, which are sometimes controversial.There are many models of software development.The most commonly used software development lifecycle models to date are [2]: Waterfall model, V-model, Incremental iteration model, Prototype model, Spiral model.
All aforementioned models have their advantages and disadvantages for software development.However, Agile methodologies for software development have been getting more and more popularity today.The most utilized among Agile methodologies is the Scrum methodology [3,4].It is a flexible development cycle model that allows developers to take advantage of existing coding practices and enables the client to make changes to requirements at any time limiting the negative impact on development teams during the sprint course.Its main feature is involvement of all participants into the process: both client and performer.The use of Scrum allows you to detect and eliminate deviations from the desired result in the earlier stages of software development.
Software development with Scrum consists of small iterations, or sprints, which are essentially small projects.Sprint duration is a fixed time period of 1-4 weeks.It has the same length until the end of the project.When sprint is over, a new working version of the product should be received.The following actions are analysis and refocusing on the new tasks of the next cycle.The effectiveness of sprint and an IT-project, in general, is directly dependent on the planning process, so solving of the sprint planning task is the very important and actual problem nowadays.
The object of study is the planning process of sprint.
The subject of the study is the theoretical and methodological tool for assessing and selection the set of tasks for sprint.
The purpose of this work is to develop a decision support technology for solving the sprint planning task.

PROBLEM STATEMENT
The sprint planning activity is a selection of a set of user stories or tasks which development team commits to solve within a single sprint, assessing their complexity and efforts with evaluation of possible risks that may occur while developing software during the sprint.In its turn, it means that the development team literally finds the optimal solution of the planning problem in the face of uncertainty.
The mathematical formulation of the planning task can be presented in the following way: -to estimate labor intensity of every US , ∈ and the team velocity V .

REVIEW OF THE LITERATURE
In order to plan a sprint, it is necessary to evaluate the complexity and labor content of user stories.There are most commonly used methods for evaluating the complexity of a story [5,6]: T-Shirt Sizes method, Planning Poker method, Dot-voting method, Ordering Rule method.Almost all of these methods are based on heuristic approaches.The aforementioned techniques do not need much time, they are quite accurate for comparison of the work efforts of one US to another, and as such they are used on many IT-projects.Regardless on sufficient number of methods for solving the sprint planning problem, they still remain open some issues that development teams face.
To reduce the subjectivity of the judgments of stakeholders, it is necessary to use formal methods based on different mathematical models.There are many scientific articles showed the way of calculating efforts or labor intensity of user stories.The journal publications [7,8] proposes using of Bayesian network for effort calculation; the reports at scientific conferences [9,10] demonstrate unusual implementation of Bloom's Taxonomy for computation of complexity of user stories; the works [11,12] reveal how to construct and use fuzzy logic framework for complexity calculation.These scientific works show the applicability of the proposed methods for assessing the complexity of user stories, but they require a very long period of time for preparation.For each IT-project, the team has to build own model or own framework, and this requires additional financial and time resources, as well as the availability of experienced specialists in the mathematical field.Such a disadvantage can lead to increase project times, which is unacceptable to Product Owner.
All of the aforementioned methods and approaches have a disadvantage: there are no recommendations for planning tasks when the complexity of the estimated user stories exceeds the average sprint velocity for the team.Scrum methodology [3,4] proposes to decompose large user stories in such cases, and then choose a set of stories, the complexity of which corresponds to the velocity of the sprint.The problem there is that the task of optimal user story selection is task in the face of uncertainty, because the likelihood of different choices is unknown most of the time.In such cases, the team and the Product Owner are guided only by benefits they get in return, with no risk assessment recommendations in every case.

MATERIALS AND METHODS
In general, the model of the business process of software development using the Scrum methodology can be represented in the following form (Fig. 1).The Business Process Model and Notation Specification [13] was chosen to model the diagram.
Before the start of software development, Product Owner and development team conducts the first meeting.It is called the Kickoff Meeting, which provides the opportunity for Product Owner to explain vision and scope of the project.The following meeting is the Product Backlog Grooming Meeting, which is devoted to creation of Product Backlog -the main document of the project.Product Backlog can be considered as the software re- quirement specification, which consists of epics and user stories.Sprint Planning Meeting is carried out before starting of the sprint.The main purpose is to prioritize and evaluate the content of Product Backlog and form the Sprint Backlog.It means that set of user stories from Product Backlog are selected for the next sprint.The biggest problem at this stage is to correctly evaluate the complexity of each story as well as to assess related uncertainty if any.Every day, a Daily Scrum is conducted to determine the status and progress of work during the sprint, identify early obstacles, and make decisions to change the strategy needed to meet sprint's goals.
The Sprint Retrospective meeting is undertaken on the last day of the sprint.It goes as following: -team members answer two questions: "what has been done well in the past sprint?"and "what needs to be improved in the next one?";-highlights improvements of the development process; -evaluates the efficiency of the team in the past sprint and predicts the expected performance in the next sprint; -identifies existing problems, proposes possible solutions and assigns team members responsible for them; -makes estimates of the probability of completion of all necessary work on the product.Sprint Review Meeting is conducted at the end of the sprint.It may be used by the team to demonstrate the version of the product to all interested stakeholders.Thus, solving the Sprint planning task allows to increase the effectiveness of decision-making process by project managers.So, the main purpose of this study is to develop decision support technology for sprint planning.
Referring to [3,4], the general model of solving the sprint planning task can be represented in the following form (Fig. 2).
The first step of planning is to prioritize each user story in Product Backlog.Product Owner handles this activity.Due to the prior prioritization, all user stories are sorted by importance to the business.Typically, Sprint Backlog creation is the selection of user stories with the highest priority from Product Backlog, unless otherwise discussed with the client.
According to the algorithm above, the next step is to solve two problems: 1) estimation of labor intensity of each user story from Sprint Backlog; 2) evaluation of uncertainty and possible risks from software development standpoint.
The determined estimations of Sprint Backlog should be compared with the team velocity.Velocity is a measure of the amount of work the team can do during a single sprint.Depending on the results, there are three options: 1) The labor content of all Sprint Backlog stories is roughly equal to the team's predicted speed and effort.In this case, the Sprint Backlog is not changed, and the team works as usual.
2) If the estimated labor content of Sprint Backlog less than the velocity of the team, then Sprint Backlog is filled with the next user story from the ordered Product Backlog list.
3) A difficult situation arises when the number and complexity of user stories in Sprint Backlog are much greater than the speed of the team.Therefore, the task selection of the highest priority user stories arises, but their number must be as high as possible.Otherwise, Product Owner changes the priorities of user stories or decomposes some of them, and the stories are reevaluated.
Solving of the problems from above results in creation of Sprint Backlog.After the sprint, the sprint results are analyzed, and the velocity is modified.Its updated value is used for further calculations in the next sprint.Velocity is calculated by totaling the points for all fully completed user stories.
Let's consider the tasks presented above in details.
The task of evaluating uncertainty is to predict implementation of a sprint in the context of incomplete information.There is a risk of failing of team commitments when there is not enough input data for sprint planning.Therefore, one of the important tasks in sprint planning is to assess the uncertainty to mitigate any possible risks that may arise in the following cases: -temporary occupation of a team member on project tasks unrelated to development, for example, demonstration to a client of a product demo, which may happen even in another country; -missing employees due to improving their skills or supporting the IT company by attending an IT conference, conducting an online training, involvement into pre-sales activities for new clients, etc.; -temporary absence of a team member due to the urgent need to use his expertise on other projects; -temporary absence of a team member due to illness; -lowering of team member performance due to objective or subjective reasons.
2) Changing of the Product Backlog before the start of the sprint: -some user stories can be added, deleted or modified on demand of the client, it leads to changing of the labor intensity of these user stories, labor intensity of the sprint and the whole project; -changing of project scope; -changing user story priorities in Product Backlog can cause Sprint Backlog failure; -incorrect estimation of complexity and labor content of the user stories in Sprint Backlog; -misinterpretation of the client's wishes, in other words, changing of the content of some user stories.
In each case, the Product Owner should decide how to assess any uncertainty and mitigate risks.Uncertainty can be taken into account in two ways.
The first way is to reduce velocity of the next sprint, in case if probability of complications is big enough.
The second way of evaluating of sprint risks is to raise the labor intensity of the user story: ( ) Then the final estimation of the user story should be slightly increased by a couple of units used by the team for the evaluation.However, the adjusted estimates should be used with care in the decision making process as of their expert judgment nature.
We can use different, more formal way of uncertainty evaluation -calculation of interval estimation instead of point estimation: As a measure of uncertainty, it is suggested to use the residual mean square for estimates of the confidence interval.The RMS shows the average deviation of user story estimation from the mathematical expectation of a set of user stories in Sprint Backlog.Therefore, when Sprint Backlog is being evaluated with a high likelihood of time failure, it is highly recommended to use the pessimistic values of the labor intensity of the user story.It means the usage of the maximum value from the confidence interval.
The RMS can also be used to analyze the estimations: the large value of RMS characterizes the imbalance of the user story estimations.This means that the labor intensity of some user stories is very high.According to the Scrum methodology [3,4,14], implementation of user story should not exceed one working day or 12 hours.So, the user story should be divided into separate tasks and reevaluated.
Consider the task of estimating the labor intensity of the user story.
User stories in Sprint Backlog are evaluated in units used by the team: man-hours or story points [5,6,14].Although the Scrum methodology recommends story points as an abstract metric for assessing the labor content of user story, some IT companies use time as a unit of story complexity.In the latter case, there are a certain number of hours to complete the story.A more qualified developer can complete the stories in a part of the allotted time, and then begin to perform the next task or switch to tasks that are not directly related to the sprint goals.Moreover, a developer with no experience can spend extra time for solving a specific problem.Thus, estimations of the user story are not objective in this case.This disadvantage can be minimized by using a different rating scale based on comparisons of labor content to implement user story.It is suggested to use Story Points as a unit of measurement.
1 SP is the unit of labor intensity of the story or the effort of the whole team to implement the simplest requirement or user story.
The number of Story Points to develop the same functionality differs from team to team, but this does not mean that time costs will be different, as each team means its value for 1 SP.Assessing stories in SP makes sense only within the same project and the same development team, because the labor content of the tasks is compared with each other.
Thus, in order to evaluate the complexity of the user story, it is necessary to make subjective paired comparisons on the selected scale.Paired Comparison Method is one of the appropriate decision making tools because of its simplicity and effectiveness.It lets to describe values and compares them to each other.In [15] the scale of comparison for subjectively paired comparisons was proposed: -equal importance -1; -moderate importance -3; -strong importance -5; -very strong importance -7; -extreme importance -9; -these marks for intermediate cases -2, 4, 6, 8.The effectiveness of this scale has been proven by comparison with many other scales in many applications [16].
The process of pairwise comparison is conducted as following.All user stories need to be compared with each other.The obtained estimates are entered into the judgment matrix.When comparing an element with itself, the ratio equals 1.If the first user story is more important than the second, then an integer from the scale is used, otherwise the inverse value is used.The lower off-diagonal elements are determined by the upper off-diagonal elements.The number of different paired comparisons in a rank-ordering of N objects is ( ) . Then the judgment matrix is used to calculate the estimation of user stories.Most scientific papers uses eigenvector to calculate values of user stories [15].However, Crawford and William in work [16] showed that the geometric mean vector is computationally easier than eigenvector and statistically preferable to the eigenvector.Let's formalize the process of user story evaluation based on the mathematical apparatus proposed in [15] and [16].
Let us denote I as the set of user stories in the current sprint, the complexity of which should be evaluated, whereas I n = is the strength of the set of user stories.
Then ij a is the result of a paired comparison of the i -th and j -th ( , ) i j I ∈ user stories, which is written to the judgment matrix n n A × , where 1 ij ji a a = and 1 ii a = .
The average relative size i g of LI of i -th US is calculated as geometric mean of judgments Let us assume , k k I ∈ is the number of the US chosen as the standard.There is recommendation for the first sprint to choose a standard user story, which labor content is known from team past experience on similar projects, or such story that has the minimal labor content.Standard US for the following sprints is the one which complexity in SP can be found in the easiest way based on the experience of the previous sprints.
where , k g k I ∈ was calculated by the formula (2).
It is necessary to use formula (1) to determine uncertainty of the complexity of user stories, where uncertainty is determined by residual mean square.Analyzing the input data, it is clear that it is impossible to find the RMS, but only RMS estimation by means of the sample variance.The following formula was proposed in science paper [13] for finding the sample variance A D of the judgment matrix n n A × for creation of the sprint backlog: 2 Sprint backlog is formed in such a way that there is no idleness of the team.So, the implementation of one user story is a process independent from implementation of another user story.Assume that each story contributes equally to the overall variance.In this case, the sample variance of the sprint backlog is the sum [ ] i D s of the sample variances of the every user story

The estimation of RMS of i -th US is calculated in following way: [ ]
Then confident interval i CI can be found such as: Thus, the algorithm of finding estimates of the labor intensity of user stories has been presented.
Consider the task of selection of user story from Sprint Backlog in the case when it is not necessary to change the priorities of a user story.
In general, the scale of priority evaluation may differ from one IT project to another.Product Owner chooses a way to evaluate the user stories herself.
Let's i x is the variable that indicate whether or not the i -th user story is selected for implementation in the current backlog sprint: 1 i x = when i -th user story is selected and 0 i x = -otherwise.So, the variable can only take two values {0,1}, ) Sprint backlog has to include the highest number of top priority user stories: The labor content of sprint backlog should not exceed the team velocity Based on the aforementioned objective functions and constraints, the model of selection of user stories for the sprint backlog can be defined in the following way: find the set of user stories satisfying the objective function (8) and constraint (9) under condition (7).This task belongs to the class of integer programming problems with Boolean variables.1.In order to obtain the numerical values of the labor intensity i s of the formula (3), the geometric mean of the labor intensity i g is calculated by using the formula (2).If this is the first sprint, and there is no information about the complexity of the user stories, then it is recommended to take as the standard a story with a minimum geometric mean value, and to take its complexity as 1 SP.Nevertheless, by the statement of the task, it is known that 2 10  s SP = , therefore, it acts as a standard for this sprint.To determine the risks the sample variance and estimation of RMS for each user story can be found by formulas ( 4) and ( 5) accordingly.

EXPERIMENTS
To find the interval estimations, which maximum value the product owner can use as a pessimistic estimations of user stories, the limit values have been calculated by formula (6) basing on obtained results.
According to labor complexity of each US and its priority, it is necessary to use the model of selection of user stories ( 7)- (9).It allows choosing the set of US from proposed sequence of US for current sprint, if summary labor content of proposed sequence of user stories is much greater than the team velocity.

RESULTS
The results of the calculations of the labor intensity of user stories from proposed IT-project for the current sprint are presented in Table 2.The value of estimation of RMS i σ is low, it means that obtained estimations are well-balanced.
The graphical representation of the confidence intervals of the estimates of user stories is shown on the Fig. 3 based on the obtained results from the Table 2.It can be seen, that for the fourth user story has the largest difference between minimum and maximum estimations.Product owner may use this information to analyze the user stories, for example, to decompose 4 th US into sub-stories, thereby reducing uncertainty.
. Therefore, it is necessary to change the story priorities and reduce the sprint backlog, or to select user stories for the sprint with current priorities.In this particular case, it is not possible to change the priorities according to the conditions of the example, so it is necessary to solve the task of selection of user stories.
Based on priorities and calculated labor intensity of each user story, the objective function (8) can be defined as follows: Taking into account condition (7) the solution of the given problem by simplex method is as following: Basing on the calculated results, the user story #4 with high priority has not been selected as the candidate for the sprint backlog.This is because its labor intensity is almost the same as the velocity of the team.In this case, the Product Owner can: -divide this story into individual cases; -refine the functionality of this story; -change priority.
The results for this story are consistent with the recommendations obtained in the evaluation of the complexity of the sprint backlog.
Thus, technology for supporting manager decisions in sprint planning has been considered.

DISCUSSION
To assess the adequacy of the developed decision support technology in sprint planning, it is necessary to compare the results of work of the team before applying the technology and after.One of the ways to verify the effectiveness of using the proposed technology in an IT company is to evaluate work efficiency using Performance Management [18].Performance management is the process of calculating and improving team performance to achieve the goals of the IT-company.To assess team performance, it is necessary to identify set of key performance indicators.We can use the following KPI: - KPI is a team satisfaction.To evaluate the team performance TP , the article [18] proposes using of universal mathematical model from [19] as a convolution criterion for KPI: 5 2 1 ( ) The utility function q u can be found in the following way: Let's consider limit values for proposed KPI.If the team spends more than 2/3 working time on different project meetings, there is the chance the project will be behind the schedule.One of the possible reason is the "analysis paralysis", which means the inability to develop or decide due to overthinking available alternatives and possible outcomes [20].Another possible reason is "scope creep", it refers to changes, continuous or uncontrolled growth in a project's scope, at any point after the project begins [21].In the common case, the number of working hours in each sprint is equal to 160 hours, so To evaluate the team performance, it was considered three sprints: first sprint was conducted without proposed technology, the team worked as usual; during the second and third sprints, the team used decision support technology for sprint planning.The results of the evaluation of the team performance in several sprints calculated by using formula (10) are shown in the Table 4.The analysis of results of the team performance evaluation from the Table 4 demonstrates the positive dynamics of changes of the team productivity on 9-12%.
The commonly used approaches to decision-making in sprint planning [5][6][7][8][9][10][11][12] allow determining the complexity of user stories in specified units.In comparison to them, the proposed technology allow calculation of the complexity of user stories, takes into account uncertainty of the current sprint, and selects a set of user stories from the sprint backlog when the total complexity of the sprint backlog exceeds the team velocity.
The proposed technology enables increasing of the team productivity and provides additional information for sprint planning.The using of the decision support technology for sprint planning and the obtained results show the feasibility of using the proposed technology in real conditions.

CONCLUSIONS
In the course of this research the decision-making technology for solving the planning problem in the face of uncertainty has been proposed.For this purpose, an analytical review of the methods of estimating the labor intensity of user stories has been conducted.It has revealed the shortcomings of existing approaches.Due to the development of technology of decision support in software development the planning task in the face of uncertainty has been further developed.A sprint planning algorithm has been developed.Formalization of the process of estimation of the labor content of user stories based on the previous experience has been presented.Sprint Backlog reshuffling model in case of extra labor effort needed for its implementation in comparison with team velocity has been developed.
The scientific novelty of the obtained results consists in improvement of the sprint planning process with the assistance of the proposed technology, which helps to reduce uncertainty while defining labor intensity of user stories and Sprint Backlog as a whole.Numerous studies have shown that the use of the proposed technology requires only handy tools, such as Microsoft Excel, OpenOffice Calc, LibreOffice Calc, PlanMaker and others, which do not require from project managers and Product Owners any specific mathematical skills.The results show the practical significance of the approach for IT companies and the ability to use the proposed technology in software development projects to increase the effectiveness of decision-making process in uncertainty for project managers, product owners and development teams.

ЛІТЕРАТУРА / ЛИТЕРАТУРА
of user stories; -to choose subset of user stories { } i US from the proposed set I for next sprint according to labor intensity of every US , i s i I

Figure 1 -
Figure 1 -Scrum model of software development

Figure 2 -
Figure 2 -The algorithm of solving the sprint planning task 1) Changing the team composition:-temporary occupation of a team member on project tasks unrelated to development, for example, demonstration to a client of a product demo, which may happen even in another country;-missing employees due to improving their skills or supporting the IT company by attending an IT conference, conducting an online training, involvement into pre-sales activities for new clients, etc.;-temporary absence of a team member due to the urgent need to use his expertise on other projects;-temporary absence of a team member due to illness; -lowering of team member performance due to objective or subjective reasons.2) Changing of the Product Backlog before the start of the sprint:-some user stories can be added, deleted or modified on demand of the client, it leads to changing of the labor

Figure 3 -
Figure 3 -Interval estimations of user stories During the previous several sprints, the team showed an average speed of work equal to 60 V SP =.Knowing the complexity of a sprint backlog, one can see that 5 1

1 KPI is a meeting time per sprint; - 2 KPI is a percentage of missed tasks; - 3 KPI is the team velocity; - 4 KPI
is a customer satisfaction; -5

1 © 4 KPI and the 5 KPI
e-ISSN 1607-3274 Радіоелектроніка, інформатика, управління.2020.№ 1 p-ISSN 2313-688X Radio Electronics, Computer Science, Control.2020.№ Melnyk K. V, Hlushko V. N., Borysova N. V., 2020 DOI 10.15588/1607-3274-2020-1ject will be behind the schedule as well.The value of team velocity depends on team, project, Product Owner, so best and worst values can be found from set of previous values.The should be evaluated by 10-point scale, where 1 is the minimal value for metrics and 10 is the maximum accordingly,
Let's consider usage of the decision support technology for sprint planning by example.There is IT-project for creating IS.It is known, that team have chosen Scrum as model of software development lifecycle.The team conducted several sprints, so velocity now is equal to

Table
1 -The judgment matrix

Table 2 -
Complexity of user stories

Table 4 -
Team performance