Search

Metrics are key elements that can give us valuable information about the effectiveness of agile software development processes, particularly considering the Scrum environment. This study aims to learn about the metrics adopted to assess agile development processes and explore the impact of how the role performed by each member in Scrum contributed to increasing/reducing the perception of the importance of these metrics. The impact of years of experience in Scrum on this perception was also explored. To this end, a quantitative study was conducted with 191 Scrum professionals in companies based in Portugal. The results show that the Scrum role is not a determining factor, while individuals with more years of experience have a higher perception of the importance of metrics related to team performance. The same conclusion is observed for the business value metric of the product backlog and the percentage of test automation in the testing phase. The findings allow for extending the knowledge about Scrum project management processes and their teams, in addition to offering important insights into the implementation of metrics for software engineering companies that adopt Scrum. [ABSTRACT FROM AUTHOR]

The competition in the software market demands that the time required for any software product to reach the market be reduced if the product is to survive competition from other developers. The pursuit of this goal has led to the adoption of agile software development methodologies. While other agile methodologies provide guidelines as to the software engineering (SE) practices to be used during the development lifecycle, Scrum does not. The purpose of this study is twofold: first, to identify the usage and level of importance of software engineering practices in the Scrum development environment; and second, to investigate how Scrum teams adopt an appropriate set of SE techniques and whether a hybrid Scrum/Extreme Programming (XP) methodology is an appropriate approach to take. This research was conducted by examining sample data from five organizations using the Scrum methodology. The sample included a range of industries including communications and embedded systems, financial asset management, software development houses and consulting firms in South Africa. The study employed a mixed method approach. A key finding was that, regardless of the fact that Scrum does not explicitly recommend engineering practices, there was extensive use of these practices by all of the participating organizations. The study also found that the lack of software engineering practices in Scrum does not constitute a barrier to a successful adoption of Scrum, provided the 'inspect and adapt' principle inherent in Scrum is properly followed. The study discusses the findings, explains the implications and suggests future research. [ABSTRACT FROM AUTHOR]

Software requirement engineering (SRE) is the initial stage of the software engineering process and entails several challenges relating to the identification, implementation, evolution, and management of requirements for the development of software systems that meet the desired functionality quality standards. Agile software development (ASD) is a well‐known software development process that follows a lightweight and adaptive methodology to support the incremental development of software systems. Since the ASD follows an adaptive procedure (ie, a flexible, nanostructured, and dynamic approach) of software development, it becomes challenging to perform SRE that follows a structured approach for managing software requirements throughout the life cycle of software development. The primary challenges for SRE, while pursuing an ASD, include, but are not limited to, identification of incomplete requirements, implementation of vague requirements, prioritization of secondary functional requirements, and compromise on users' involvement that negatively impacts the software system's functionality and quality. To overcome these challenges, some of the recent research efforts have focused on managing different phases of SRE during software development using the ASD. However, there is a lack of solutions that provide software engineers/practitioners with a solution. Besides, frameworks to effectively manage all the phases of SRE as per the needs of the ASD are needed. We propose a framework that unifies joint requirements document (JRD) and SCRUM to incrementally (a) identify, (b) implement, (c) evolve, and (d) manage system requirements throughout the software development cycle. We have used the action research method to qualitatively validate the proposed framework based on data and user requirements collected from a product‐focused (multinational) Norway‐based software company. The results of the validation are based on statistical analysis that reflects the usefulness of the proposed framework for SRE in ASD‐based software engineering and development. Future research is the possible application of a machine learning approach (es) in the intended context for agile requirements elicitations. [ABSTRACT FROM AUTHOR]

Background: Although agile and Scrum have been important frameworks in software engineering for over a decade, little research has explored how teams use Scrum language within their sprints. Literature review: Most explorations of Scrum communication have been collected through self-reported means. These studies are inherently unable to explore how Scrum teams use Scrum-centric language in their meetings in ways that adhere or run counter to standard Scrum practice. Research questions: 1. In what ways is Scrum reflected in the language used by team members in various sprint meetings? 2. What associations exist between the job title of team members and their use of Scrum language? 3. What does a discourse analysis reveal about the ways in which this team uses language to value and discount Scrum? Research methodology: For three sprints over 10 weeks, I recorded meetings of 27 Scrum team members. I transcribed these meetings, developed a codebook for assigning Scrum language categories, conducted an interrater reliability agreement on the data, completed a correspondence analysis on how Scrum language associates with meeting types and job titles, and conducted a discourse analysis to determine in what ways these teams value and discount Scrum. Results/discussion: Scrum language was found in all recorded meetings across all three sprints, with much language found in the planning meetings. Few associations existed between Scrum language and job title, suggesting that Scrum at this engineering firm is an egalitarian process. In addition, the discourse analysis revealed that this engineering firm valued User Story and Sprint Execution language while discounting Capacity and Story Pointing language. Conclusions: Although this group broadly adheres to Scrum practices about 68% of the time, this study finds that several current standard components of Scrum are routinely discounted. This exploratory study suggests that more research into the in-situ use of Scrum language in engineering workplaces is necessary to better inform engineering professionals about the communicative expectations of Scrum and to better enable engineering communication educators to prepare future engineers for Scrum realities. [ABSTRACT FROM AUTHOR]

Nowadays, considerable attention is paid to agile methods as a means to improve management of software development processes. The widespread use of such methods in professional contexts has encouraged their integration into software engineering training and undergraduate courses. Although several research efforts have focused on teaching Scrum through simulating a software development project, they covered only the learning of programming practices within a Scrum team. Furthermore, few studies tackle nontechnical skills other than the development practices themselves. The work presented here introduces an original Scrum-based training model enhanced with agile coaching to maximize student performance. This was validated by a case study on a capstone project in a Scrum course. This paper summarizes the positive results of introducing agile coaching, which resulted in approximately 22% more coverage of software engineering practices. In addition, a survey data showed that, compared to students who did not receive coaching, coached students gained valuable insight into the internalization of Scrum, problem solving, and guidance by means of checkpoint meetings. [ABSTRACT FROM PUBLISHER]

Although traceability information is vital to many software engineering activities, agile development approaches rarely use it because of the extra effort required. In this industry case study, the authors report the results of applying their lightweight semiautomated method that integrates traceability into software architecture developed with an agile process like Scrum. [ABSTRACT FROM PUBLISHER]

Many smaller companies cannot afford the time and effort to change their development processes all at once. In some cases, companies are not aware of the fact that many aspects of agile development are already in place. The aim of this work was to evaluate if an evolutionary transition to agile software development is suitable for small companies. We conducted a case study with a small company to start their step‐by‐step agile transition. Initially, three agile software development practices were introduced. Based on the assessment of improvements, the transition continued with three Kanban practices. Experiences with the improvement process and the selected practices were elicited by means of qualitative interviews for data collection. Our case study reports details on the implementation of the first practices as well as the way the resulting agile transition has taken so far. The positive experiences reported by all employees during the agile transition indicate that an evolutionary transition is suitable for small companies. The experiences concerning the transition process and the positive effects of the selected practices motivate practitioners to start their own agile transition. [ABSTRACT FROM AUTHOR]