Development of a web application in an agile team improving the user story effort estimation process

In this master thesis work is presented my experience in a French consultant company during a six-month internship. The goal of the internship was to develop a web application in an Agile team. The main functionality of the application is the management of clients and consultants of the company. The agile team was composed by six interns developers at their first working experience. The thesis work extends the internship report committed at the end of the stage, where there are illustrated the main steps of the development. Particularly, are added the chapter 4, describing an activity research made in parallel during the stage, and the sections where are described tools used for the deployment (kubernetes, terraform and helm). The team started from scratch, defining the microservice architecture of the system and choosing the technologies that most suited each microservice. The application was deployed in a cloud environment, exploiting all its advantages: more flexibility, easier maintenance and users that do not need to directly manage resources. Developers were in charge of setting up the cloud infrastructure. The development followed the DevOps philosophy: tools like Terraform and pipelines have been used in order to automatize operations. The research activity, that was carried out in parallel with the development, proposes a possible approach to improve the user story estimation process. It proposes metrics and possible indicators that could badly affect this process. The possible indicators of bad estimations proposed are: 1) "New technology": when a user story requires the introduction of a new technology. 2) "Spike", user story that requires also to implement transversal tasks. 3) "New functionality", when a user story introduces a new set of functionalities. During the development were collected both quantitative data, such as effort in hours spent on each user story, and qualitative data, like developers’ feedback. These data were analysed and discussed before each sprint planning and, particularly, in a special meeting at the middle of the development in order to see if, with a more experience in the project and with the analysis of data collected, the estimation process improved. Developers’ feedback, i.e. difficulties encountered during the implementation, were collected in order to identify the most common reasons of bad estimations. What came out is that the role of the Product Owner is crucial and must not be underestimated; 15 user stories out of a total of 20 identified were badly estimated because the goal of the story was not clear during the planning or client's needs were not fully understood. Furthermore, a factor that most influenced the team was the lack of experience of developers. The activity demonstrated that the effort estimation process could be improved by collecting and analysing data. The number of user stories bad estimated decreased over time, no more exceeding 2 bad estimations per sprint. Regarding the possible indicators of bad estimations, not significant conclusions can be drawn about because there were no strong correlations. However, the team thinks that developers must pay attention when estimating a user story that introduces a new set of functionalities or requires to perform transversal tasks. In the first case, the team has to make sure that the new functionality's goals are clear to every developer. In the second case, the team must discuss possible difficulties and factors that could affect the implementation of transversal task.