Agile Product Line Engineering: The AgiFPL Method
Hassan Haidar
, Manuel Kolp
and Yves Wautelet
LouRIM-CEMIS, Université Catholique de Louvain, Belgium
KULeuven, Faculty of Economics and Business, Belgium
Keywords: Software Product Line Engineering, Agile Software Development, Agile Product Line Engineering, AgiFPL,
Scrum, Scrumban, Features.
Abstract: Integrating Agile Software Development (ASD) with Software Product Line Engineering (PLE) has resulted
in proposing Agile Product Line Engineering (APLE). The goal of combining both approaches is to overcome
the weaknesses of each other while maximizing their benefits. However, combining them represents a big
challenge in software engineering. Several methods have been proposed to provide a practical process for
applying APLE in organizations, but none covers all the required APLE features. This paper proposes an
APLE methodology called AgiFPL: Agile Framework for managing evolving PL with the intention to address
the deficiencies identified in current methods, while making use of their advantages.
Over the past years, the software industry has been
searching for methods, processes and techniques to
increase the delivery of high quality software while
reducing development costs. Several paradigms have
been proposed in order to fulfil this target. “Agile
Software Development” (ASD) and “Product Line
Engineering” (PLE) are well-known approaches
proposed by researchers and practitioners for dealing
with the growing complexity of information systems
and handling competitive needs of the IT industry (da
Silva et al., 2011). The popularity of both approaches
and their positive results have motivated researchers
to find ways for integrating them (Farahani, 2014)
leading to “Agile Product Line Engineering”
The main goal of APLE is to maximize the benfits
of each individual approach and to fulfil their
common goals (Hanssen, 2011). Moreover, combi-
ning ASD and PLE presents a significant advantage
in terms of “synergy” in which, each approach
addresses the weaknesses of the other. But, among the
proposed APLE methodologies, only few have
proposed a specific process for this combined
approach, and can hence be actually referred truly to
as APLE methodologies (Asadi, and Ramsin, 2008).
After reviewing the literature on APLE and
anlysing, comparing and evaluating the relevant
APLE methodologies, each method can be considered
as presenting strengths and weaknesses. Furthermore,
the study of the existing APLE methods has revealed
that no single method covers all the needed APLE
In this context, this paper proposes an APLE
methodology called AgiFPL (Agile Framework for
managing evolving SPL). The intention behind the
definition of this APLE method is to address the
deficiencies identified in current methods, while
making use of their advantages.
1.1 Research Method
In order to achieve our target we started by
identifying, studying and evaluating the relevant
APLE methodologies that exist in the literature.
(Díaz et al., 2011) and (da Silva et al., 2011) have
already surveyed several APLE methods in their
systematic literature reviews. (Farahani and Ramsin,
2014) have presented a recent study in which they
surveyed and analyzed APLE methodologies in a
more precise and systematic manner through using
“criteria-based evaluation”. Based on that, we made
an iterative evaluation of the methodologies based on
a “criterion set”. The results of the evaluation
performed in each iteration have allowed us to obtain
a deeper insight into the features of the
methodologies. The results are therefore used to
identify new criteria and thus enriching the criterion
set. Indeed, the results of this criteria-based
Haidar, H., Kolp, M. and Wautelet, Y.
Agile Product Line Engineering: The AgiFPL Method.
DOI: 10.5220/0006423902750285
In Proceedings of the 12th International Conference on Software Technologies (ICSOFT 2017), pages 275-285
ISBN: 978-989-758-262-2
Copyright © 2017 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
evaluation have highlighted the strengths and
weaknesses of each methodology, have specified the
features expected of APLE methodologies, and have
identified the shortcomings of methodologies. Thus
these results could be used for improving current and
future APLE methodologies.
Secondly, we have studied and evaluate some
ASD methodologies such as, Scrum (Cohn, 2013),
XP, Scrumban (Ladas, 2009). We aim with this
evaluation to identify methods or reusable method
chunks that could help us to produce our intended
APLE. The results of this evaluation are used as a
basis for selecting and assembling reusable method
chunks, instantiating abstract process frameworks,
and extending existing methodologies in order to
define the bespoke APLE methodology.
Thirdly, after designing and defining the
proposed APLE we aim to validate it by establishing
an exhaustive case-study that shows the applicability
of the bespoke APLE. Due to lack of space, we only
present a short illustration in this paper.
1.2 Contributions
As said this paper is an effort to propose an adequate
APLE method that addresses the lacks and
deficiencies (see Section 4) of classical APLE
methods. For this purpose, we focus on the agile
methods Scrum (Cohn, 2013) and Scrumban (Ladas,
2009) as basis for AgiFPL as they adapt well to
software evolution and they are widely used by the
agile community. In addition, we focus on the
requirement engineering disciplines of I-Tropos
(Wautelet, 2008) (i.e. Organizational modeling and
Requirement Engineering) in order to define the RE
process of AgiFPL.
According to (Asadi et al., 2012) and (Hersari et
al, 2010) software development methodologies
consist of two integral parts: a “modeling language”
and a “process”. The modeling language part
provides the syntax and semantics used for expressing
the products, whereas the process prescribes the flow
of activities that should be performed and explains
how the products should be produced, enhanced and
exchanged along this flow. The agility feature of
APLE methods has deemphasized the role of
modeling, and hence the modeling language. In the
proposed APLE, we presented an adequate
Requirement Engineering (RE) process for both
Domain Engineering (DE) and Application
Engineering (AE). The proposed RE process of
AgiFPL make a trade-off between the requested RE
elicitation and the agility feature. The target of this
RE process is to introduce a suitable reuse strategy
and reduce the upfront design during the AgiFPL
development process. Moreover, for the process part
AgiFPL integrates Scrumban for the DE and Scrum
for the AE.
The paper is structured as follows. Sections 2 and
3 overview PLE and ASD. Section 4 highlights the
nowadays context of APLE. Section 5 presents our
AgiFPL framework. Section 6 introduces an
illustration with part of case study. Finally we
conclude the paper in Section 7.
Software Product Line Engineering or Product Line
Engineering (SPLE or PLE) provides an efficient way
to build and maintain portfolios of systems that share
common features and capabilities.
There are two essential phases to develop SPLs:
Domain Engineering (DE) and Application
Engineering (AE) (Pohl et al., 2005).
DE is the phase of creating a set of reusable assets
for building systems in a specific problem domain
(Díaz et al., 2011). It determines the scope and
handles the commonalities and the variability, i.e.
defines the core-assets, points of variations, and
expected variants for all the products of the PL (Kang
et al., 2010). DE is summarized in the following set
of activities or practices (O’Leary et al., 2009):
1. Domain Identification and Scoping;
2. Requirements Engineering;
3. Feature Modelling;
4. Architecture Design;
5. Core-Assets Development;
6. Traceability Management;
7. Evolution and Maintenance.
The AE phase consists of developing products
through systematic reuse of core-assets by deriving
the PL variability points, i.e. reusable assets are
extended from variability points with the selected
variants for a specific product (Clements and
Northrop, 2001 ; Pohl et al., 2005). AE is summarized
in the following set of activities and practices (Díaz
et al., 2011):
1. Release Planning (plan for product
2. Product Configuration (model application,
architecture application, platform
3. Product Development;
4. Test, Integration and Deployment;
ICSOFT 2017 - 12th International Conference on Software Technologies
5. Traceability Management;
6. Evolution and Maintenance.
Figure 1 shows a framework for PLE, which
divides the product line into DE and AE.
Figure 1: The Software Product Line Engineering
framework (Pohl et al., 2005).
Agility is an umbrella term for a variety of agile
methods that are based on the Agile Manifesto (Shore
and Warden, 2007) principles and values. Agile
Software Development (ASD) is an approach that is
intended to enable rapid and flexible development of
small-scale software solutions from scratch, usually
addressing a single, well-defined customer
(Sommerville, 2011). Documentation, including
plans, is kept at a minimum, and work is organized in
short iterations developing the software product in
increments, which is continuously tested in
collaboration with customers and potentially
refactored (See Figure 2).
Figure 2: Basic ASD process (Shore and Warden, 2007).
External stakeholders such as clients and third-
party actors participate in nearly the whole period of
a development project (Larman, 2003).
All these methods, such as Scrum, XP, and
Scrumban implement iterative incremental life
cycles, share common values, and principles with
each one of them defining their own practices. We
only focus in on Scrum and Scrumban since we will
use them in the design of AgiFPL.
3.1 Scrum
In Scrum, projects move forward through aggressive
deadlines via a series of iterations called sprints to
implement dynamic requirements pulled from a
backlog. Each sprint is typically two to four weeks
long, at the end of which, the performed work should
create something of tangible value to the stakeholders
(Chon, 2013; Kenneth, 2013). Each sprint has a
sprint-planning meeting at the sprint beginning in
which the Product Owner and Team plan together
about what to be done for the sprint. The result is the
sprint backlog, a list of User Stories and tasks that
must be performed to achieve the sprint goal.
3.2 Scrumban
Scrumban proposes a transition method for moving
software development teams from Scrum to a more
evolved development framework. Since the
introduction of Scrumban, organizations have layered
the Kanban Method alongside Scrum to help them
achieve several different kinds of outcomes (Ladas,
2009 ; Reddy, 2016).
There has been growing interest in whether the
integration of Agile and PL could provide further
benefits and solve many of the outstanding issues
surrounding software development (da Silva et al.,
The following methods are proposed as APLE
methods and are considered as relevant:
Component-Driven Development (CDD) –
(Ramsin and Paige, 2008 ; Wang, 2005);
Extend FAP – (de Souza and Vilain, 2013);
RiSE Process for Product Line Engineering
(RiPLE-SC) – (Balbino et al., 2011);
A-Pro-PD – (O'Leary et al., 2010);
Agile Product Line Engineering: The AgiFPL Method
Tailoring the Scrum Development Process
to Address APLE – (Díaz Fernández et al.
An Iterative Model for Agile Product Line
Engineering – (Ghanam and Maurer, 2008);
Extreme Product Line Engineering –
(Ghanam and Maurer, 2009);
Agile Approach for Software Product Lines
Scoping – (da Silva, 2012);
Agile PuLSE-I – (Carbon et al., 2006);
Agile product line planning – (Noor et al.,
Reactive Variability Management in Agile
Software Development – (Ghanam et al.,
The main shortcomings (deficiencies) (Farahani,
2014) of these methodologies concern the following
groups of criteria:
1. General criteria (e.g. modelling language,
the process);
2. Criteria related to the characteristics of
agile methods (teams, flexibility, leanness
3. Criteria related to the PL characteristics
(DE activities, AE activities, core assets,
scope, features, etc.);
4. Criteria related to the common goals of
agile and PL (on-time software delivery,
software quality, HR management,
management of changes in requirements,
5. Criteria related to issues arising due to the
combination of the two approaches (Reuse
approach, basis of the methodology, etc.).
Reviewing the existent APLE methodologies
shows the need of a new approach that cover all the
following APLE characteristics (Díaz et al., 2011;
Farahani and Ramsin, 2014):
7. Full coverage of the generic software
development lifecycle;
8. Comprehensive and precise definition of
the methodology;
9. Sufficient attention to the non-SDLC
activities (umbrella activities);
10. Prescription of a specific modeling
11. Provision of model examples;
12. Attention to learning at project and
portfolio levels;
13. Attention to active user involvement;
14. Management of expected and unexpected
The intention behind our AgiFLP framework is to
develop a proper APLE methodology which
combines agility with PLE effectively, and embodies
the advantages of both approaches.
This section presents how our APLE is tackled by
means of a tailored Scrum, and Scrumban in which
the DE and AE processes are performed in an iterative
and incremental way. To overcome the PL-
architecture challenge and reducing the upfront
design, it is necessary to define the mechanisms and
strategies to be applied during the APLE development
process. This is why our contribution is based on two
main aspects: requirement engineering (RE) and
development process. In fact, using a goal-oriented
requirement engineering approach (GORE) such as
i*, will provide the mechanism to easily evolve PL-
architectures in an agile context and will establish a
suitable reuse strategy. Furthermore, adopting
Scrumban and Scrum for the development processes
in DE and AE will establish the agility of our method.
AgiFPL is thus an agile methodology designed to
improve the agility within the PLE and to meet
effectively any new emerged business expectations.
The main goal of AgiFPL is to move teams from the
classical approach to a more evolved APLE
In addition, the proposed approach adopts
forecasting and metric models and some project
management practices in order to address some
management issues.
In other words, on the one hand, for the DE stage,
AgiFPL implement an iterative process that uses i*
approach with Scrumban. On the other hand, for the
AE stage, AgiFPL implement also an iterative
process that use the Scrum approach with i*.
AgiFPL is a two a tier framework where the first
layer modelled in Figure 3, is dedicated to the
Domain Engineering (DE) and the second one,
modelled in Figure 4, is dedicated to the Application
Engineering (AE). Moreover, the framework
considers two spaces i.e. Problem Space and Solution
Space. Note, that each process of AgiFPL is based on
an iterative and incremental development.
ICSOFT 2017 - 12th International Conference on Software Technologies
Figure 3: Domain engineering (DE) process according to AgiFPL.
Agile Product Line Engineering: The AgiFPL Method
5.1 De Tier
The DE tier is detailed in Figure 3. First, the “Software
Vendor” has a business strategy for the domain. This
strategy is built from market trends, potential
investment opportunities and core-business
improvements. The domain strategy constitutes the
main base to define the scope of the domain and start
the phase of “Domain requirement engineering”
The strategy pushes to start the DRE phase, first
step in the problem space. DRE is a sub-process that
aims to understand the problem space by studying the
settings of the organizations related to the domain.
Roles involved in this sub-process are “Domain
Experts”, “Domain Sensei” and “Development Team”.
During this sub-process, the people involved model the
target domain in terms of social actors and their
intentions. In addition, when the “Software Vendor”
adopts a new or modified strategy, the “Domain
Experts” pull this strategy and upgrade the “Domain
After receiving all the documentations and models
delivered at the end of the DRE phase, the “Domain
Design” (DD) phase starts. The DD phase takes the
reference RE models as input and creates a reference
architecture for the product line’s platform, which
gathers the common assets. At this phase, the scope of
the domain and the architectures have to be
determined, i.e., decide which products should be
covered by the product line and, consequently, which
features are relevant and should be implemented as
reusable artefacts. The DD phase contains two primary
tasks: domain scoping and domain modelling.
Once commonalities and variabilities are
identified and feature models are generated at the DD
phase, “Domain Experts” defines the “Features
Backlog” (FB). During this phase, the persons
involved document features in “User Stories” (US)
format (Cohn, 2004). At this stage, stories contain
rough estimates of both business value and
development effort. At the end of this stage, the
“Domain Experts” build a “Selected Backlog” (SB)
with defined capacity from the FB. The SB represents
a list of work the “Development Team” must address
next. It has a defined capacity limit. As soon as
capacity is available, it is filled up with user
stories/features from the top of the FB.
After building the SB, the “Domain Experts” and
“Development Team” hold the “Planning 1” meeting
in order to shape stories and estimate “Cycle Time”.
“Planning 1” is considered as the “WHAT”:
Whenever the “Domain Experts” pulls new user
stories into the SB. After this, the “Development
Team” should understand the different features.
Therefore, the team is able to estimate the complexity
of each user story.
Once “Planning 1” takes place, the “Development
Team” structures the “Stories in Progress Backlog”
(SIP Backlog) with defined capacity (K[n]). The SIP
Backlog is a list of user stories, which the
development team currently addresses. Team
members pull user stories from the selected backlog
when there are no more remaining tasks in the task
After structuring the SIP Backlog, the “Domain
Sensei” and “Development Team” hold the
“Planning 2” meeting. With “Planning 2” starts the
“Domain Implementation or Production of Common
Assets” phase. The “Planning 2” is considered as the
“HOW”: Whenever team members pull new user
stories into the production flow. During the “Planning
2” meeting, the team establish the “Production
Flow” consisting of the following components:
1. Task Backlog;
Task in Progress with defined capacity (max
k[6]). Once the “Task in Progress” is done,
team members pull tasks from “Task
3. Task Done with “Parking Lot”. Once the
story is completed (Story complete?)
“Development Team” members pull user
stories from the “SIP Backlog”.
4. Story Testing with defined capacity (max
5. Stories Done;
During the “Production Flow”, the “Domain
Sensei” and “Development Team” hold a “Daily”
meeting, which is a short, time-boxed meeting, taking
place every day at the same time.
Whenever the team ships an increment
(Increment Ready?), the “Domain Experts”, “Domain
Sensei” and “Development Team” hold a “Review”
meeting in order to review the work accomplished.
The team uses this meeting to present and review the
work it has completed since the last delivery. Usually,
it also includes a demonstration of the features
created during the latest increment or iteration. Once
the features are implemented as reusable artefacts
(Models, Source Codes,…), these are placed in the
“Common Assets Warehouse”.
After any “Review”, the “Scrumban Sensei”
holds the “Retrospective” meeting to reflect on the
past production cycle in order to ensure continuous
process improvements. The “Domain Sensei” always
asks two questions in the retrospective:
1. What went well during the last cycle?
2. What should improve in the next cycle
ICSOFT 2017 - 12th International Conference on Software Technologies
Figure 4: Application engineering (AE) process according to AgiFPL.
Agile Product Line Engineering: The AgiFPL Method
During the “Production Flow”, whenever a
problem occurs, the “Domain Sensei” organizes an
“Andon” meeting whenever problems in the
production flow occur.
5.2 AE Tier
The AE tier, represented in Figure 4 includes several
product lines where the outputs are client applications
(products). At this stage, “App i Owners” and “App i
Stakeholders” are more involved in the development
Hereafter, we describe the AgiFPL proposition
for the “Line i” which deliver at the end the “App i”.
In fact, AgiFPL propose a simple agile. Each line of
the AE tier will follow this process.
First, an “App i Owner” comes with an idea of
what he/she wants to create. The App Line process
starts and lunches the “App i Requirement
Engineering” (ARE i) phase. This phase has two main
1. The “App i Owner”, “App i Stakeholders”,
“Line i Master”, and “Development Team i”
study the “Organization i” in order to
understand the motivations and rationales that
underline the “App i” requirements.
2. The “App i Owner” idea could be large,
therefore, through an activity called
“Grooming”; it is broken down into a set of
features that are collected into a prioritized list
called the “App backlog”.
The requirement assets produced in “Domain
Engineering” constitute some basis, but they will not
satisfy all “App Owners” and “App Stakeholders”
requirements. The gap between what is available and
what is required must be analysed, and a trade-off
decision has to be taken for each unsatisfied
requirement. At the end of the ARE phase two types
of features coexist:
1. Features that exist and could be selected from
the “Common Assets Warehouse”. The set of
these is called “Selection of Features” (SoF).
2. Features that are required for the development
of the application and does not exist in the
“Common Assets Warehouse”. Since these
features are defined during the ARE phase, the
set of these is called “Definition of Features”
Consequently, the building of the “App backlog” is
finished and it contain an ordered list of documented
US that the team maintains for an “App”. Note that
all new reusable artefacts issued from the AE process
have to be classified in the “Common Assets
Once the “App backlog” is finished, the work is
performed in “Sprints” up to a calendar month. The
work completed in each sprint should create
something of tangible value to the customer or user.
The “Sprint” starts with the “Sprint Planning”
(WHAT? And HOW?). The “App i Owner”, “Line i
Master” and “Team Development i” perform the
“Sprint Planning” in order to determine the most
important subset of “App backlog” items to build in
the next sprint. During the sprint planning, the “App
i Owner” and “Development team i” agree on a sprint
goal that defines what the upcoming sprint is
supposed to achieve.
At the end of the “Sprint Planning”, the “Sprint
Backlog” is defined and the “Definition of Done”
(DoD) list is established. In fact, DoD is a checklist
of activities required to declare the implementation of
a story to be completed.
Once the concerned people consider the “Sprint
Planning” as finished and agree on the content of the
next sprint, the “Development Team i”, guided by the
“Line i Master” coaching, performs all the task-level
work necessary to get the tasks done. This step is
called “Sprint Execution”.
Every day during the sprint, ideally at the same
time, the “Development Team i” members hold a
time-boxed “Daily” meeting. This “inspect-and-
adapt” activity is sometimes referred as the daily
The “Sprint” results are considered as a
“Potentially shippable App increment”, meaning that
whatever the “Development Team i” has agreed to do
is really done according to its agreed-upon definition
of done.
At the end of the “Sprint”, there are two additional
“inspect-and-adapt” activities:
1. “Sprint Review”: The goal of this activity is to
inspect and adapt the product that is being built.
Critical to this activity is the conversation that
takes place among its participants. The
conversation is focused on reviewing the just-
completed features in the context of the overall
development effort.
2. “Sprint Retrospective”: This activity
frequently occurs after the sprint review and
before the next sprint planning. Whereas the
sprint review is a time to inspect and adapt the
product, the sprint retrospective is an
opportunity to inspect and adapt the process.
Once the “Sprint Retrospective” is completed, the
whole cycle is repeated again — starting with the next
sprint-planning session, held to determine the current
highest value set of work for the team to focus on. At
the end of the “Sprint” the “Line i Master”,
ICSOFT 2017 - 12th International Conference on Software Technologies
“Development Team i”, and “App i Owner” perform
a “Backlog refinement”: (max. 60 min) used to
introduce and estimate new backlog items and to
refine existing estimations as well as acceptance
criteria. It is also used to break large stories into
smaller ones.
After an appropriate number of sprints have been
completed, the “App i Owner’s” vision will be
realized and the solution can be released.
In order to validate our proposed APLE method, we
suggest introducing briefly a case study based on the
Odoo open source ERP platform (Odoo Inc., 2017).
In fact, Odoo offers an All-in-one ERP management
software which fits small and medium companies and
our APLE method (AgiFPL) could be applied within
Due to lack of space, we only present a simple
example concerning “NST Shipping” which is a
maritime transporter that Odoo to implement their
cross functional business processes. In the requested
ERP, several modules and application are needed for
supporting NST activities, e.g. “Invoicing
Application” and “eTracking service”.
Odoo has an initial huge “Common Assets
Warehouse”. Among the reusable artefacts of Odoo
we found the “Invoicing Module”. Therefore, several
modules of NST ERP would be found in Odoo’s
common assets warehouse.
Once NST signs the contract of the NST ERP
implementation with Odoo, the Odoo “Line Team”
will proceed following the AE phase of AgiFPL.
Based on the results of the “ARE step” and “NST App
Backlog” the “Line Team” will recognize that the
requested “eTracking service” does not exist in the
“Common assets Warehouse” and there are no similar
artefact among the reusable ones. Therefore, the
“Line Team” will start the process of developing this
service. In other words, the team will transform the
related requirement model (See Figure 5) into a
feature model and then into USs and organize these
USs in the App Backlog. Then they will follow the
process until delivering the final version of the NST
Following AgiFPL method, this “Goal Model” of the
eTracking service will be transformed into a feature
model (FM). Figure 6 shows the FM for the
eTracking service” module.
As said above, this FM for “eTracking Service”
will be transformed to USs in order to define the “App
Backlog”. According to the “Planning” the
development of this App will take a “Sprint” of 2
weeks. Table 1 shows the “Sprint” plan.
At the end of the sprint the final version of the
“eTracking service App” will be integrated to the
NST ERP. In addition, all reusable artefacts generated
from this step will be stocked on the “Common assets
As mentioned in this paper, our contribution is to
propose a new proper APLE approach that addresses
the deficiences identified in current APLE methods,
while making use of their benefits. The proposed
APLE approach is called AgiFPL (Agile Framework
for managing evolving PL).
In order to design this APLE approach we have
reviewed the most relevant APLE approaches from
the literature. In addition, we present as an illustration
part of a case study in order to show how we intend
to validate our approach.
Further work undergoing to complete AgiFPL
approach. For instance, we are working on adopting
and developing metrics for performance.
Furthermore, we are developing tools that will
facilitate the implementation of AgiFPL. Also, we try
to simplify the RE processes by adopting adequate
frameworks that fit the agility of our proposal.
Table 1: Sprint plan.
Week 1
One of the first
Meeting with NST
Sprint post-mortem
1 Monday Technical meeting
Development sprint
2 Tuesday
3 Wednesday
4 Thursday
5 Friday
Week 2
1 Monday
2 Tuesday
3 Wednesday Internal demo
Sprint “planning 2” and
review meeting
4 Thursday Fix change requests
5 Friday Retrospective
Project Status Meeting
Agile Product Line Engineering: The AgiFPL Method
Figure 5: Goal Model (i* SR model) for eTracking service.
Figure 6: Feature Model for eTracking Service.
Asadi, M., Bagheri, E., Mohabbati, B., and Gašević, D.
(2012). Requirements Engineering In Feature Oriented
Software Product Lines: An Initial Analytical Study. In:
Proc. SPLC ‘12, 2, pp. 36-44.
Balbino, M., de Almeida, E. S., and de Lemos Meira, S. R.
(2011). An Agile Scoping Process for Software Product
Lines. In: Proceedings of International Conference
SEKE2013, Miami (USA) pp. 717–722.
Carbon, R., Lindvall, M., Muthig, D., and Costa, P. (2006).
Integrating Product Line Engineering and Agile
Methods: Flexible Design Up-front vs. Incremental
ICSOFT 2017 - 12th International Conference on Software Technologies
Design. In: Proc. of International Workshop on Agile
Product Line Engineering collocated with International
Software Product Line Conference, pp. 1–8.
Cohn, M. (2013). Succeeding with Agile: Software
Development Using Scrum. 1st ed. Upper Saddle River,
NJ: Addison-Wesley Professional.
da Silva, I. F., Neto, P., O'Leary, P., de Almeida, E., and de
Lemos Meira, S.R. (2011). Agile Software product
lines: a systematic mapping study. Software: Practice
and Experience, 41(8) 2011, pp. 899–920.
da Silva, I. F. (2012). An Agile Approach for Software
Product Lines Scoping. In: Proceedings of
International Software Product Line Conference,
SPLC2012, Salvador, Brazil pp. 225–228.
de Souza, D. S., and Vilain, P. (2013). Selecting Agile
Practices for Developing Software Product Lines. In:
Proceedings of International Conference SEKE2013,
Boston (USA) pp. 220–225.
Díaz, J., Pérez, J., Alarcón, P. P., and Garbajosa, J. (2011).
Agile product line engineering—A systematic literature
review. Software: Practice and Experience, 41(8), pp.
Díaz Fernández, J., Pérez Benedí, J., Yagüe Panadero, A.,
and Garbajosa Sopeña, J. (2011). Tailoring the Scrum
Development Process to Address Agile Product Line
Engineering. In: Proceedings of JISBD2011, Spain:
Farahani, F. F., and Ramsin, R. (2014). Methodologies for
Agile Product Line Engineering: A Survey and
Evaluation. In: Proceedings of the 13th International
Conference SoMeT_14, Amsterdam: IOS Press BV, pp.
Ghanam, Y. and Maurer, F. (2008). An Iterative Model for
Agile Product Line Engineering. In: Proceedings of the
12th SPLC2008, Ireland: Limerick, pp. 377–384.
Ghanam, Y., and Maurer, F. (2009). Extreme Product Line
Engineering: Managing Variability and Traceability via
Executable Specifications. In: Proceedings of Agile
Conference, AGILE '09, IEEE Computer Society, USA:
Washington DC, pp. 41–48.
Ghanam, Y., Andreychuk, D., and Maurer, F. (2010).
Reactive Variability Management in Agile Software
Development. In: Proceedings of Agile Conference,
AGILE '10, Portugal: Guimarães, pp. 27–34.
Hanssen, G. K. (2011). Agile software product line
engineering: enabling factors. Software: Practice and
Experience, 41(8), pp. 883–897.
Hanssen, G. K., and Fægri, T. E. (2008). Process fusion: An
industrial case study on agile software product line
engineering. Journal of Systems and Software, 81(6),
pp. 843–854.
Kenneth, S. R. (2013). Essential Scrum: A Practical Guide
to the Most Popular Agile Process. Upper Saddle River,
NJ: Addison-Wesley Professional.
Kolp, M., and Mylopoulos, J. (2001). Software
architectures as organizational structures. In: Proc.
ASERC Workshop on” The Role of Software
Architectures in the Construction, Evolution, and Reuse
of Software Systems”, Edmonton, Canada.
Kolp, M., Giorgini, P., and Mylopoulos, J. (2002).
Organizational multi-agent architectures: a mobile
robot example. In: Proceedings of the first international
joint conference on Autonomous agents and multiagent
systems: part 1, pp. 94-95.
Ladas, C. (2009). Scrumban - Essays on Kanban Systems
for Lean Software Development. 1st ed. Seattle, WA:
Modus Cooperandi Press.
Larman, C. (2003). Agile and Iterative Development—A
Manager’s Guide (Agile Software Development
Series), Cockburn A, Highsmith JJ (eds). New Jersey:
Mohan, K., Ramesh, B., and Sugumaran, V. (2010).
Integrating Software Product Line Engineering and
Agile Development. IEEE Computer Society, 27, pp.
Mylopoulos, J., Kolp, M., and Giorgini, P., (2002). Agent-
oriented software development. In: Hellenic
Conference on Artificial Intelligence, pp. 3-17.
Noor, M. A., Rabiser, R., and Grünbacher, P. (2008). Agile
product line planning: A collaborative approach and a
case study. Journal of Systems and Software, 81(6), pp.
O'Leary, P., McCaffery, F., Thiel, S., and Richardson, I.
(2010). An Agile process model for product derivation
in software product line engineering. Journal of
Software: Evolution and Process, 24(1) 2012, pp. 561-
Pohl, K., Böckle, G., and van der Linden, F.J. (2005).
Software Product Line Engineering: Foundations,
Principles and Techniques. Berlin: Springer-Verlag,
pp. 3-88.
Ramsin, R., and Paige, R. F. (2008). Process-centered
Review of Object Oriented Software Development
Methodologies. ACM Computing Surveys, 40(1), pp.
Reddy, A. (2016). The Scrumban [r]evolution: getting the
most out of Agile, Scrum, and Lean Kanban. 1st ed.
New York: Addison-Wesley Professional.
Sommerville, I. (2011). Software Engineering. 9th ed.
Boston: Addison-Wesley.
van der Linden, F., Schmid, K., and Rommes, E. (2007).
Software Product lines in Action: The Best Industrial
Practice in Product Line Engineering. Berlin: Springer-
Agile Product Line Engineering: The AgiFPL Method