###### Abstract  
SPL scoping is the activity for bounding Software Product Lines (SPL), gathering heterogeneous knowledge from diverse sources. For achieving an agreement among different stakeholders, a commonly scope must be understood and committed to. However, gathering this knowledge from stakeholders with individual interests is a complex task. This paper reports the experience of scoping the SPL of a small Colombian software company, applying and evaluating a collaborative method called CoMeS-SPL. The company was looking to develop a set of products from a product previously developed with great potential to be adapted and sold to different customers. From a collaborative relationship university-enterprise model, the research groups that developed CoMeS-SPL proposed to use it answering to the company needs for defining an organization-suitable reuse scope around its platform called CORA. Both parties joined in the scoping co-production of the first SPL of the company. This method implied that the company would perform new tasks and involve other roles different for those who are used to defining the scope of a single product. The company actors considered that they obtained a useful scope and perceived the collaboration as valuable because they shared different knowledge and perspectives. The researchers were able to provide feedback on their proposed model, identifying successes and aspects to improve. The experience allowed strengthening the ties of cooperation with the company, and new projects and consultancies are being carried out. software product lines; SPL scoping; collaborative work; collaboration engineering; empirical study; experience report; empirical software engineering +
Footnote †: _Applied_  
An essential activity in the development of an SPL is defining its reuse scope (SPL scoping) [3], which specifies the application domain and identifies the product portfolio with the variations among them and plans the reuse infrastructure [4]. However, scoping an SPL is a difficult and risky activity because of the complexity and the variety of different factors to be considered, and some of these normally are unknown by the technical team [4]. As a consequence, SPL scoping requires the participation of non-technical experts who usually do not take part in the development team [5]. SPL scoping depends on the knowledge and experience of roles involved in gathering the information of the target domain (context), the possibilities of development, and market conditions [5; 6]. Therefore, this activity requires the interaction of participants who have partial and different knowledge because none of the scoping participants has all the necessary knowledge and experience to obtain a complete and useful scope [7]. The correct scope of an SPL depends on balanced decision-making by the participants [8] and, thus, the diversity of participants is a critical factor. It is because this activity involves marketing issues [8] as well as technical management practices of the SPL [1]. The implications of this duality have been analyzed by different authors [9; 10; 11; 12], considering that communication and collaboration are fundamental aspects to achieving the participation of people from a variety of organizational areas, each one defending his interests [9; 11; 12]. However, to the best of our knowledge and understanding, SPL scoping approaches that have considered collaborative practices have not been sufficiently formalized as organized collaborative practices or do not specify unequivocal shared artifacts. There is a lack of available methods to help answer the question: How could a software organization collaboratively perform SPL scoping activity? Although there are approaches for guiding decision-making software engineering activities in a collaborative way [13], these approaches are general proposals that do not describe elements of the method engineering (work products, roles, and tasks) and none of these approaches is specific or focuses on scoping an SPL.