Keywords

1 Introduction

Effort estimation is a crucial activity in a software project as it helps to establish realistic and credible plans to implement the project requirements and satisfy commitments. The failure or success of the project depends hugely on the effectiveness of the estimation done [1]. By improving the accuracy of effort estimation, the project planning becomes efficient and provides various benefits for an organization. In order to achieve accurate estimations, it is important to cater for the risks to which a project is or may be exposed during its implementation. Thus, this study tries to identify factors that impact estimation accuracy at the level of a sprint. The project is assured to be completed as planned and within expectations with a good sprint planning and estimation.

For an agile project, when features planned to be completed in one iteration spill over onto the next, delays are triggered in subsequent iterations which consequently increase the delivery time of the project. Therefore, having a good initial sprint-level estimation avoids this problem. The paper therefore aims to identify the relevant factors that directly affect sprint effort estimation. These factors will then be considered in the next phase of the research which consist of developing a model for predicting sprint effort estimation. The remainder of the paper is structured as follows: Sect. 2 gives an overview of agile effort estimation techniques and the factors that affect effort estimation. Section 3 presents results of a survey carried out to identify factors that affect sprint effort estimation. Discussions about the results are presented in Sect. 4. Future works are highlighted in Sect. 5. Finally, Sect. 6 concludes the paper.

2 Agile Effort Estimation

Software estimation is the process of predicting the amount of effort, resources, time and money required to build a software system. Inaccurate effort estimates lead to wrong decisions in controlling and managing software projects. There are various software effort estimation models that have been proposed in the past decades [2]. The popular ones are COCOMO and Function Point Analysis (FPA) [2,3,4,5,6]. The traditional estimation methods, COCOMO and FPA, are not effective when dealing with agile software estimation due to varying requirements and incremental development [7]. This prompted the introduction of other estimation methods for estimating agile projects.

The application of effort estimation methods in agile projects is very challenging. This is because the scope is continuously adjusted throughout the project and new tasks are discovered even during later stages of software development [7]. Customer requirements are subjected to change based on changing technology and domain, budgets and political influence. Due to uncertainty in requirements, there may not be adequate information to estimate upfront and thus estimating the effort of the complete agile project becomes more complex and difficult [5].

Many effort estimation methods in agile software development, such as analogy, expert judgement, planning poker and story points, use subjective expert effort estimation [7]. Analogy-based method depends on historical data of previous projects. The new project is compared to similar projects for which cost, time and effort data are known [8]. Expert opinion approach requires opinion and experience of multiple experts from different areas of software development to estimate the size and time of the stories of the project. Experts’ estimates are based on intuition [3]. Story point-based method is the most currently used estimation technique in agile software development. A story point is an estimate that includes the effort involved, the complexity and the inherent risk in developing a feature. It is relative in nature; that is, a three-point value is assumed to take trice the effort than a single point value story [5]. User stories are normally estimated for release and sprint planning [8, 9]. A developer needs to have some experience of estimating and access to historical data to set an effort estimate for developing a user story. Soliciting expert opinion to determine effort is also useful. It is, however, difficult to find suitable experts with a variety of domain skills [5]. Planning Poker is one of the recent expert estimation techniques that is widely used in agile methods for software development, especially scrum and extreme programming [10]. It is based on story point for estimating the size of user stories and developing release and iteration plans [10]. This technique encourages the involvement of the whole development team during the estimation session, thus making it more effective [10]. It is assumed to provide better estimates than individual experts as participation of people with different backgrounds helps in reducing the over-optimism of expert judgment-based estimates by identifying more issues affecting implementation [10]. Table 1 presents the different factors that affect agile effort estimation.

Table 1 Factors affecting agile effort estimation
Full size table

3 Sprint Effort Estimation

Many agile methodologies have evolved over a period of time. Scrum remains the most popular and practiced one. Scrum is an iterative and incremental framework for application or product development which is achieved through iterative cycles known as sprints [11]. A sprint is relatively a short period of about 2–4 weeks in which a number of user requirements in the form of user stories are completed by the development team [12]. At the start of each sprint, a cross-functional team selects items from product backlog and commits to complete the items by the end of that particular sprint. The product backlog contains the requirements of the project and is refined and updated through the lifetime of the project by the product owner. Every day, the team gathers for a short meeting to discuss the progress and blocking issues, if any. At the end of the sprint, the team reviews the work product with stakeholders and demonstrates what has been built. The feedback is then incorporated in the subsequent sprint. At the end of each sprint, scrum emphasizes that the integrated working software is fully tested and potentially made shippable. The sprints are strictly time-boxed and occur sequentially.

A survey was carried out in a company in Mauritius to determine the list of factors that have an impact on sprint effort estimation. A questionnaire is therefore designed for conducting a survey on 15 completed small-scaled agile projects in the company which is well known in providing information technology, outsourcing and consulting services. The company implements an agile environment in which a variety of projects are developed by distributed cross-functional teams. Most of its projects employ scrum methodology which is successfully introduced in teams and guided by high-skilled scrum masters. Most existing effort estimation systems consider factors that affect the estimation of a whole project. However for this study, the primary focus is to determine whether factors affecting the estimation of a whole project are same for a sprint and if not, which factors that affect the estimation of a project’s sprint. The questionnaire is distributed to each project’s scrum master to collect factors that affected the project’s sprints, together with justifications. The results of the survey are presented in Fig. 1.

Fig. 1
figure 1

Survey results

Full size image

It has been observed that not all factors that affect effort estimation in an agile project affect sprint effort estimation. Out of the factors described in Sect. 2, the following factors have less impact on a project’s sprint: data transaction, hardware and software requirements, operation ease, process, management, environmental factors and working time. Staff experience and technical ability and complexity of requirements are the two most impacting factors in all projects. Factors stakeholders, team dynamics and commitment, communication, staff experience and technical ability, experience of previous project, responsibilities outside project, configuration, security, defects and changes of previous implementation, quality of requirements, complexity of requirements, volatility of requirements are vital factors that need to be catered in sprint effort estimation of agile projects.

4 Discussion

This section presents justifications for the need of specific factors in sprint effort estimation.

  • Stakeholders

Based on the justifications of most projects’ scrum masters, responses from stakeholders get delayed when they are absent during a specific period of the ongoing sprint due to other commitments or holidays. Many scrum masters also share the opinion that this factor impacts a project if the product owner (PO) who is a project’s key stakeholder does not understand the principles of agile or is reluctant to invest himself in the project’s activities. The PO is responsible not only for representing the business on an agile project but also for well maintaining the product backlog and working in collaboration with the team so as to maximize value of the project.

  • Team dynamics and commitment

According to scrum masters, lack of team dynamics and commitment reduces team effectiveness and team performance, thus affecting effort estimation. Lack of team dynamics and commitment often occurs in projects due to conflicts between team members, personal issues, health problems and lack of motivation.

  • Communication

Most projects’ scrum masters respond that communication is a major factor when a project is being developed with distributed teams of different cultures and at different sites. The team spends more time in communicating with each other for the synchronization of activities.

  • Staff experience and technical ability

Effort estimation is hugely impacted with the turnover of qualified staffs in an ongoing sprint. Scrum masters find that teams with good technical expertise work more efficiently by saving time in problem solving. From the survey, many projects’ teams consist of novice people who require time to rise in competence.

  • Experience of previous project

All new projects are impacted by this factor as team members consume time in doing investigations during implementation and this reduces their working pace.

  • Responsibilities outside of the project

Some team members may have additional tasks outside the project such as contributing to other activities of the company. It may also happen that skilled developers need to help in other projects or train novice team members.

  • Configuration

Most answers from scrum masters are based on the configuration of a project for its deployment on multiple environments after its implementation. Configuring a project for deployment consumes time.

  • Security

Most sprints include a level of security that needs to be catered, thus increasing the sprint effort. Functional security like user authentication, user and administrator view are common in all projects. Code security is imperative so as to reduce the security risks and vulnerabilities that occur due to coding errors. It is also determined that this factor includes database security which is essential to prevent data breaches of the project. Security of sensitive information is the primary concern for customers.

  • Defects and changes of previous implementation

Scrum masters justify that defects in previous sprints may cause changes in implemented functionalities and this increases the current sprint’s effort. The team needs to correct defects in implemented functionalities in order to prevent extensive reworks or other functional defects from arising.

  • Quality of requirements

Effort estimation is affected when the team misunderstands customer’s requirements which lack clarity. The team spends time in implementing features that are out of scope, and this finally results in rework. In most cases, it also happens that customer realizes pitfalls in requirements when seeing the working software.

  • Complexity of requirements

A requirement can have a complexity of level low, medium or high for its development, depending on its nature. All requirements have a level of complexity of development, thus affecting all sprints.

  • Volatility of requirements

During a sprint, the scope is kept constant and all changes are treated as new requirements. If a change means more value to the customer, the change is accepted if it is small (up to a number of hours) and has been identified at least 2–3 days prior to the end of the sprint. The change should be well aligned with the value proposition of a story in the sprint. Major changes in scope are treated as new stories in subsequent sprint.

  • Data transaction

According to scrum masters, the team often caters for data transaction as part of technical complexity when estimating a sprint. Thus, this factor is combined in the technical complexity effort estimation of a sprint. Among the 15 selected projects for the survey, it is deduced that this factor has less impact.

  • Operation ease

Design of interfaces is normally done before the implementation phase. The effort needed for its implementation is catered as part of technical complexity of requirements for a sprint. Further enhancement in terms of GUI asked by customer is taken as new requirements in future sprints.

  • Process

Companies with well-established processes rarely change. This factor has less impact on its projects. According to scrum masters, any changes in processes should be considered after the completion of a sprint.

  • Management

Top management affects mainly decisions regarding a whole project, for example funding of the project, technologies, resources and processes. The effort estimation for the implementation of requirements of a sprint is rarely impacted by this factor.

  • Environmental factors

Scrum masters are of the opinion that these factors are more or less constant. Nowadays, most companies integrate ergonomics into all their operations for the health, safety and well-being of employees. Employees too adopt a more flexible approach to their workplaces and try to adjust to their settings.

  • Working time

Many scrum masters state that this factor impacts projects when team members have to work beyond office hours. Productivity is decreased when team members have to work for longer hours to meet deadlines.

5 Future Works

Based on the identified factors, a predictive model will be developed for sprint effort estimation using machine learning techniques. The following methodology will be used to implement the model:

  • Literature Review: An in-depth literature review will be carried out so as to understand different approaches for software effort estimation. Systems integrating machine learning techniques in agile effort estimation systems will be studied.

  • Analysis: The analysis phase will consist of determining the requirements of the prototype. A critical analysis of existing agile effort estimation systems and the problems associated with these systems will be carried out. A model will be proposed to cater for the observed problems in effort estimation. The requirements of the proposed model, including the technologies and techniques adopted for its implementation, will be described. Factors collected from the survey as discussed in Sects. 3 and 4 will be used to determine effort estimation of a sprint more precisely.

  • Design: This phase will consist of designing the proposed model. Based on identified sprint factors, a dataset will be built to train different machine learning techniques for the estimation of effort. Machine learning algorithms and methods used for the model will be described in detail.

  • Implementation: Based on the design, the model will be implemented and the estimates obtained from different machine learning techniques will be gathered and analyzed.

  • Testing: The model will be evaluated by using different performance measures, and the results obtained will be carefully analyzed. The results will be represented with the help of graphs and interpreted accordingly. Further improvements for the model will also be discussed.

6 Conclusion

In today’s software industry, it is observed that most projects are adopting agile methodologies due to its enriched practices. Effort estimation of such projects is challenging. There are various recent studies that have been carried out for agile effort estimation based on factors. These studies focus on the correctness of project estimates. This paper identifies twelve key factors among many more factors that influence sprint effort estimation. The selected factors for a sprint are strongly justified by professional scrum masters. It is important for estimators to understand the reasons for integrating these factors in effort estimation of an agile project’s sprint in order to achieve good accuracy of estimates. As future work, a predictive model will be developed for sprint effort estimation based on the identified factors using machine learning techniques.