Software development methods aim to increase the development team’s productivity, shorten the time to market, reduce development costs, and improve customer satisfaction. To achieve the above goals, agile software development, also known as agile development, has gradually aroused public discussion since the 1990s. It advocates adaptive planning and evolutionary development, shares the same software process values, and encourages rapid and flexible responses to changes through early delivery and continuous improvement [1]. Agile development emphasizes moderate planning, human-oriented cooperation, face-to-face communication, self-organization and management, and rapid development [2]. Software organizations adopt large-scale agile practices ^[3][4][5][6][3,4,5,6] to replicate the success of agile methods on team projects at the organizational level.

Although the agile software development method can tolerate changes in requirements and can effectively and quickly solve problems, increase output, and shorten the entire development timeline, it also has some shortcomings which may lead to project failures. For example, requirement identification and initial planning is the first challenge of Scrum [7]. Another challenge of Scrum is the lack of attention to design. Scrum pays less attention to requirement engineering in the analysis and design phase. In addition, its lack of traceability of documents and files and configuration management may affect product quality or lead to project failure. Software product line engineering (SPLE) ^{[8][9][10][11]}[8,9,10,11] uses product-line methods to produce products for customers with different needs. Software product-line engineering aims to develop software products at a minimal cost ^[8][12][8,12] and improve software quality by increasing the reuse of existing software components [13].

Agile means fast, light, and dynamic. Agile methods are more effective and faster when responding to changes than traditional software development methods ^[14][15][16][16,17,18]. They emphasize individual interactions between processes and tools, self-organizing teams, continuous release of new software features, and customer collaboration ^[17][19]. Agile methods maintain rigorous engineering processes and adopt best practices while helping stakeholders work with software developers to build, deploy, and maintain complex software ^[18][20]. They emphasize adapting to changes rather than predicting ^[19][21]. The focal aspects of agile methods are simplicity and speed ^[15][17]. Agile software development methods generally have the following characteristics: incremental: small software releases with rapid cycles; cooperative: customers, developers, and relevant stakeholders work and communicate together closely; straightforward: the method itself is easy to adopt and well documented; and adaptive: the ability to deal with changes.

According to the Agile Status Survey ^[20][22], Scrum was reported as the most widely practiced agile methodology. At least 72% of respondents currently practice the Scrum method or a hybrid approach containing Scrum. Scrum was first introduced by Takeuchi and Nonaka ^[21][23] in the context of product development. The term Scrum is borrowed from the rugby game, which means that only by maintaining an overall forward method, like passing the rugby ball within the team, can it cope with the challenges of the current complex market ^[22][24]. The Scrum framework proposed by Jeff Sutherland and Ken Schwaber ^[23][25] is an agile method that can deal with changes by developing and reviewing software increments iteratively. Unlike the waterfall model, which breaks down project activities into different phases, Scrum focuses on developing a set of high-value features incrementally and iteratively through each Sprint to obtain customer feedback faster ^[24][26].

The Scrum team is a small cross-functional, self-organizing team that uses iterative and incremental processes for the project or product development. Team members are responsible for creating and adapting the overall process within this structure. The management representative of the team is the Scrum Master. The primary responsibility of the Scrum Master is to eliminate obstacles to the team and ensure that Scrum practices are followed. Product Backlog is the priority list of all requirements or user stories to be implemented in the project; the Product Owner has the right to determine the priority of the user story ^[19][21]. Grooming is managing product backlog with prioritized requirements and estimating the amount of work to complete the requirements ^[25][27].

Sprint is a time-boxed development period based on product goal and complexity, usually 1–4 weeks. The Scrum team builds and tests product increments with new features that can be released in each Sprint. Sprint begins with a Sprint planning meeting where the product owners, Scrum Master, and Scrum team members determine what needs to develop. The Scrum team then uses Sprint goals in internal meetings to obtain a list of requirements in the Sprint backlog. A successful Sprint depends on whether Sprint goals and the requirements in the Sprint backlog are achieved and satisfied.

During the Sprint, the Scrum master holds a 15 min “Daily Scrum” or “Daily Standup Meeting” with the Scrum team to review project progress. Each team member will answer three questions ^[23][25]: 1. What has been done since the last meeting? 2. What will be done before the next meeting? 3. What are the obstacles in the process?

Each Sprint provides an incremental version of a potentially deliverable product. The team produces software that is coded, tested, and usable at the end of each Sprint. The Scrum team will hold a Sprint review meeting to show their results during the Sprint. Next, the Scrum team evaluates its work and processes in a Sprint retrospective meeting to prioritize improving the team’s processes before the next Sprint ^[26][28].

Agile software development methods also have some challenges. For example, the challenges of Scrum are how to identify requirements, how to conduct preliminary planning, and the lack of focus on design ^[27][29]. Scrum pays less attention to requirement engineering in the analysis and design phase ^[28][30]. In addition, it has poor traceability in document archives, incomplete version control, and configuration management, all of which may be potential factors that lead to project failure and even affect subsequent system maintenance and requirements changes.

Software reuse involves creating new software from existing software products that improve product quality by combining reliable and quality software components. A software product line (SPL) is a set of software-intensive systems that share features or functions generated from a group of pre-defined and reusable shared core assets ^[10][29][10,31]. Software product line engineering (SPLE) ^{[8][9][10][11]}[8,9,10,11] uses product line methods to produce products for customers with different needs. A product line is created by combining commonalities to efficiently produce products by integrating or reusing shared core assets to meet customer needs. Large-scale customization is transparent in software product line engineering, customers can obtain unique products through their specific needs, and their common needs will be evaluated before production starts ^[29][31].

Software product line engineering aims to develop software products by reusing existing software components [13]. Different techniques and methods ^{[30][31][32][33][34][35]}[32,33,34,35,36,37] can be used to develop various software products in multiple domains. Several studies ^{[36][37][38][39][40]}[38,39,40,41,42] explore how to integrate agile methods and software product line engineering. There are two complementary development processes in software product line engineering: the domain engineering process and application engineering process. The domain engineering process defines and realizes the commonality and variability characteristics of the product line. Its purpose is to develop the shared core software assets and a common and reusable product line platform to promote the systematic and consistent reuse of all finished products and components. The application engineering process binds the product line’s variability according to specific applications’ needs. It builds a single application product or a series of product applications by reusing shared core software assets, products, or product components from domain engineering ^[41][43]. The domain engineering process comprises five sub-processes: product management, domain requirement engineering, domain design, domain realization, and domain quality assurance ^[8][36][8,38]. Developers identify domain variability models and implement and test reusable domain artifacts in a product line platform. The application engineering process comprises four sub-processes: application requirement engineering, application design, application realization, and application testing. Developers design application variability models and build application artifacts according to customers’ needs.