XP Release Planning Model
Using Fuzzy Logic
Mr. Mubarak Al-rashoud
Dr.mahmmoud Kamel
Dr. Ibrahim Bediwi
King Abdul Aziz University
Faculty of Computer Science and information system
Abstract
The goal of XP incremental manner , is to deliver the most profitable requirements in the early releases . This is
achieved by applying release planning process . XP release planning has two problems : its limitation in terms of its
scalability , and its informality . The first problem is clear when there are competing stakeholder interests. In this case
many point views and opinions are raised , which lead to conflicts among different stakeholders . The second problem
raises because the requirements in XP are described in terms of ‘user stories’. The user stories are an informal
description of user requirements. In the release planning process, the user stories are prioritized using only one factor ,
which is the perceived value of the user . However, deciding which user stories will be delivered in a certain release ,
does not only depend on the stories values , but also depends on many variables that have a complex relationship.
Different stakeholder and technical precedence constraints have to be taken into account . Simultaneously, available
and required effort for each increment has to be balanced. This paper employs fuzzy theory to present a model to
generate XP release plan . The inputs to this model are stakeholders decision weights , stories values and priorities of
the different stakeholders , as well as, the risk associated with each story. In addition to that , other two constrains are
considered: precedence constrains , where some requirements cannot be implemented until another is completed , and
coupling constrains , where one requirement should be implemented in the same increment as another one .
1.Introduction
Extreme Programming (XP) is a new, lightweight software development approach
that advocates rapid iterations , rapid feedback, rigorously tested cod , team courage
and high-bandwidth communication with end users , to maximize team productivity ,
delivered product value and customer satisfaction , and to minimize delivery time ,
management overhead and risk of rapidly changes of requirements .[1][3]. XP
delivers the product in a set of releases . A release is a version of a system with
enough new features that it can be delivered to users outside the development group.
A release represents perhaps one to three months of work. [3]. Using short releases
gives many advantages. "First, requirements can be prioritized so that the most
important ones are delivered first , and benefits of the new system gained earlier.
Consequently, less important requirements are left until later , and so if the schedule
or budget is not sufficient the least important requirements are the ones more likely to
be omitted. Second, the customers receive part of the system on early and so are more
likely to support the system and to provide feedback on it. Third, being smaller, the
schedule/cost for each delivery stage is easier to estimate. Fourth, user feedback can
be obtained at each stage and plans adjusted accordingly. Fifth, perhaps most
importantly, an incremental approach allows for a much better reaction to changes or
additions to requirements".[5]. However , It is not worthy to use XP incremental
manner unless there is a technique that specifies the most profitable requirements. In
other words a technique has to be found to optimize the selection of stories that would
be implemented. Actually there is not problem when there is only one customer , and
when there are no constrains that control the operation of stories prioritization. But
the situation is different when there are competing stakeholder interests . [4]. In this
case many point views and opinions are raised , which lead to conflicts among
different stakeholders. On the other hand technical constrains have clear affects in
planning process. For example , it is not possible to start implementing a story , unless
the prerequisite stories of this story is already finished , even though it is less
valuable to the customer . These different variables present in beginning of each
release where release plan is produced , as figure 1 shows [5].
Priorities
&
Priorities
Refined &
Extended
&
Priorities
Refined &
Extended
&
Constraints
Constraints
Constraints
&
&
&
Requirements
Requirements
Requirements
Release 1
Release 2
Release 3
...........
Figure 1
Thus, these different variables must be considered by any solution of the release
planning problem. The release planning problem is addressed and illustrated formally
in [4] and [5] . The authors in [4] propose a hybrid approach which is called erelease planning combining the strengths of computational intelligence with human
intelligence supported . In [5] a method is called EVOLVE is proposed , this method
aimed at the continuous planning of incremental software development based on a
genetic algorithm. The authors stated that, in the release planning process three main
considerations that need to be taken in account which are the technical precedence
inherent in the requirements, the typically conflicting priorities as determined by the
representative stakeholders, as well as the balance between required and available
effort. The authors in [6] , develop a cost-value approaches for prioritizing
requirements. They use the Analytic Hierarchy Process (AHP) to compare the
customer alternatives in a stepwise fashion and measure their contribution to the
customer objectives. In the section 2 of this paper the different variables of the release
problem will described . also the statement of problem will be presented . in the
section 3 a model uses fuzzy theory will be presented . conclusions will be presented
in section 5 .
2. Formulation Problem of XP Release Planning
As it is stated above many variables are considered to make the decision about
planning a release these variables is defined by ruhe in as follow
 Stakeholders evaluations
"Each stakeholder gives two kinds of evaluation. First one is the perceived value of
each requirement to each stakeholder (expected relative impact on business value of
the final product). The other one is prioritization according to the degree of urgency
(time criticality) of each requirement to each stakeholder. It is assumed that a software
system is initially specified by a set R1 of requirements, i.e. R1 = {r1; r2…rn}: At
this stage (k=1) we wish to allocate requirements to the next and future releases. In
later phase k>1 , an extended and modified set of requirements Rk will considered as
starting point to plan for release or increment k (abbreviated by Inck ). The
requirements are competing with each other (to become implemented). Their
individual importance is considered from the perspective of q different stakeholders
abbreviated by S1, S2… Sq. Each stakeholder Sp is assigned a relative importance
  (0, 1). The relative importance of all involved stakeholders is normalized to one
ie
∑p = 1...q  p =1. Each stakeholder Sp assigns a priority denoted by
Prio (ri, Sp, Rk) =1 means highest priority in term of set of requirements ri  Rk
from the perspective of stakeholder Sp . Typically, different stakeholders have
different priorities for same requirements. The requirements by themselves are
assumed to be understandable by all stakeholders and sufficiently detailed to estimate
the effort for their implementation. Similarly, each stakeholder Sp assigns a value
denoted by Value (ri, Sp , Rk)  {1,2,......,  } to requirement ri as part of set
of requirements Rk at phase k of the planning approach. Value(ri , Sp , Rk) =1 means
highest priority in terms of the supposed impact of requirement ri to the final business
value of the final product, taken from the perspective of stakeholder Sp.
 Effort constraint
Effort estimation is another function assigning each pair (ri , Rk) of requirement ri
as part of the set Rk the estimated value for implementing this effort, i.e. effort( ) is a
function: (ri , Rk) → R+ where R+ is the set of positive real numbers. Typically
project releases are planned for certain dates. This introduces a size constraint Sizek in
terms of available effort of any released increment Inck: We have assumed that the
effort for an increment is the sum of the efforts required for individual requirements
assigned to this increment. These results in constraints
∑r (i)  inc(k)
effort(ri,Rk)<= Sizek for all increments Inck.

Precedence and other dependency constraints
Let us first define ωk which assign each requirements ri of set Rk to the number s of
its increment incs , i.e. ωk : ri Є Rk → ωk(ri)=s  {k,k+1,k+2,....}.
Precedence and other dependency constraints are clear in a typical real world project
where some requirements must be implemented before others. There might be logical,
technical or resource related reasons that the realization of one requirement must be in
place before the realization of another. Since we are planning incremental software
delivery, we are only concerned that their respective increments are in the right order.
More formally, for all increments k we define a partial order  k on the product set
Rk X Rk such that (ri,rj)   k implies ωk(ri) ≤ ωk(rj) .With similar arguments as
earlier there might be logical, technical or resource related reasons that the realization
of one requirement must be in place in the same increment as another one. Again,
since we are looking at incremental software delivery, we are only concerned that
their respective increments are in the right order. More formally, for all increments k
we define a binary relation  k on Rk such That (ri ,rj)   k implies that ωk(ri)
= ωk(rj)." [5]
In addition to the previous factors, the risk constraint should be considered . The risk
constraint is defined formally as follow:
 Risk Constraints
Risk estimation is another function assigning each pair (ri , Rk) of requirement ri as
part of the set Rk the estimated value for risk of implementing this requirement , i.e.
Risk( ) is a function: (ri , Rk) → R+ where R+ is the set of positive real numbers.
Typically each requirement has a risk to implement it. The risk has big impacts on
speeding up or delaying the implementation of a requirement. Because it might be
found a requirement with a high value and high urgency but with high risk of
development. More formally, for all increments k we define a binary relation  k on
Rk such That (ri, rj)   k
Risk(ri) ≤ Risk(rj) implies that ωk(ri) ≤ ωk(rj).
3.Problem Statement for Software Release Planning
"At any phase k we assume an actual set of requirements Rk. Taking into account all
the notation, concepts and constraints as formulated above, we can now formulate our
problem as follows:
For all requirements ri  Rk determines an assignment ω*
with ω*(ri) =s  {1, 2,…} to increments Incs such that
(1) ∑r (i)  inc(m) effort(ri,Rk)<= Sizem for m=k,k+1,k+2,........
(Effort constrains)
(2) ω*(ri) ≤ ω*(rj) for all pairs (ri,rj)   k
(Precedence constraints)
(3) ω*(ri) = ω*(rj) for all pairs (ri,rj)   k
(Coupling constraints)
(4) A = ∑p=1......q  p [ ∑r (i),r(j)  R(k) penalty (ri,rj,Sp,Rk, ω*)]
min ! with penalty(ri,rj,Sp,Rk , ω*) :=
(4.1) 0 if [prio(ri , Sp , Rk)- prio(rj , Sp , Rk ) ][ ω*(ri) – ω*(rj)]>0
(4.2) | prio(ri , Sp , Rk)- prio(rj , Sp , Rk ) | if ω*(ri) – ω*(rj)
(4.3) | ω*(ri) – ω*(rj)| if prio(ri , Sp , Rk)= prio(rj , Sp , Rk )
(4.4) [prio(ri , Sp , Rk)- prio(rj , Sp , Rk ) ][ ω*(ri) – ω*(r j)]
Otherwise
(5) B=∑p=1......q  p [ ∑r (i) € R(k) benefit (ri,Sp , ω*)]
max ! with
benefit (ri,Sp,Rk, ω*) = [  - value(ri , Sp , Rk)+1] X [ - ω*( rj) +1] and  = max
{ω*( ri) : ri  Rk}
(6) C(α)=( α-1)A+ αB
max ! with α  (0,1) .
(7) Determine K best solution from C(α1) , C(α2) , C(α3)
With 1≤K≤10 and 0< α1< α2< α3<1." [5].
(8) ωk(ri) ≤ ωk(rj) for all pairs (ri,rj)   k (Risk constraint)
The function (4) is to minimize the total penalties defined as the degree of deviation
of the monotonicity property between requirements. Monotonicity property between
two requirements is satisfied if one requirement is evaluated more promising than
another, and this is true also for the sequence of the assigned increments. The function
(5) is to maximize the total benefit. For a fixed stakeholder, the benefit from the
assignment of an individual requirement to an increment is the product of some value
difference and some difference in increment numbers. The product is the higher, the
earlier the requirement is released and the more impact on final business value is
supposed. Finally the overall objective function (6) for one fixed value of a is to
maximize a linear combination of (4) and (5). The case of α close to 0 means to give
a (strong) priority to stakeholder priorities. In a similar way, α close to 1 means a
(strong) priority is given to the achieved benefits of assignment ω*.
4. XP Release Planning Using Fuzzy theory
Release planning problem is a decision making problem since many stakeholders
participate in the planning effort, which lead to difficulties to reach the same decision
about the prioritizing of the user stories. The application of fuzzy set theory is a good
alternative to solve this problem , because the problem is vague by its nature , since
many stakeholders give their estimations to a specific piece of requirement. The
estimation is based on human taste and human linguistics. For example , when the
customer says " user story X is important and user story Y is very important " . There
is no precision and certainty in this kind of estimations. "On other hand, the
application of fuzzy set theory in real world decision-making problems has given very
good results. Its main feature is that it provides a more flexible framework, where it is
possible to solve satisfactorily many of the obstacles of lack of precision" [2] .
Figure 2 shows the proposed model that uses fuzzy system to optimize the solution of
release planning problem. The model goes through four steps:1) For each user story , specify coupled and preceding user stories , and represent
them using graph data structure.
2) Use fuzzy system to generate a numerical decision (rank) , to order the user
stories according to their effect on the final product .
3) Maintain the values of the user stories ranks to meet the precedence constraint.
4) Determine the scope of the release .
US
Stakeholders Estimation
Specify
Coupling
and
Precedence
Constraints
Determine
Release
Scope
Maintain
(USRP)
USRP
USFRV
Explored User
Stories
Release Plan
Development Team Risk
Estimation
Figure 2 proposed Model
4.1 Specify coupling and precedence constraints
Matrix implementation of graph is used , to represent coupling and precedence
relationship , among different user stories. If there are n user stories , then user
stories matrix US is defined of n X n dimension. To represent coupling constraint the
following simple algorithm is used:If Coupled (usi & usj)
US[I,j] =US[j,i] = 'C'
Else if Precedence (usi & usj)
US [i, j] ='P'.
4.2 User Story Ranking Process (USRP)
USRP is a process that uses fuzzy system to give each user story a (User Story Final
Rank (USFR)). USFR is a numeric number that shows the degree of importance of the
story. As this number increases , as its order in the release plan decreases. USRP takes
stakeholders evaluations (the value and priority of each user story), as well as the
estimated risk (estimated by the developers) as input variables. Depending on many
rules , the USFR is generated. If there are coupled stories , then they are treated as one
unit in the ranking operation . i.e. the stakeholders are asked to give one value and
one priority for each group of coupled stories. That means the USFR are equal for all
coupled stories. For sake of simplicity , USRP assumes three levels of stakeholders:
level1 represents a stakeholder with high decision weight (for instance top
management). Level2 represents stakeholders with medium decision weight (for
instance departments' engineers) .While level3 represents stakeholders with low
decision weight (for instance operators). As figure 3 shows USRP is constructed of
many fuzzy processes.
Lev1PrioEst
Lev1PrioValEstPro
Lev1EstAggregate
Lev1ValEst
Lev1PrioEst
Lev2PrioValEstPro
Lev2EstAggregate
USPrioValAggragatePro
USW
Lev1ValEst
Lev1PrioEst
Lev3PrioValEstPro
Lev3EstAggregate
Lev1ValEst
USFRPro
USFR
Risk
Figure 3 USRP
Each fuzzy process has its inputs variables, its rules and its output variables. The
output variable of a processes might be an input variable to another process. All
fuzzy processes are based intuition method , which depends on the innate intelligence
and understanding of the human. Triangular fuzzy numbers are used. The choice is
backed not only by its simplicity , but also by its closeness to the human natural way
to estimate the importance of the things under uncertainty , using three possible
values: important , not important and the most likely important . the universe of
discourse for all processes is defined to be [0..5] where : 1 is the bottom value , 3 is
the intermediate value and 5 is the top value . While 2 and 4 are the intermediate
values between two adjacent judgments. These processes are defined as follows:

Stakeholder Priority and Value Estimation Process (SHPrioValEstPro):
takes a stakeholder evaluation of the priority and the value for a certain user story as
inputs , and output a single numeric , that represents the aggregation of the degree of
value and the degree of the urgency for that user story. For each stakeholder level
there is an instance of SHPrioValEstPro : Lev1PrioValEstPro , Lev2PrioValEstPro
and Lev2PrioValEstPro . Therefore there are three output variables :
Lev1EstAggregate , Lev2EstAggregate and Lev3EstAggregate . Table 1 shows the
membership functions of input variable and output variables . Also it shows the
rules that control the output of SHPrioValEstPro .
Inputs
Low High
And Rules
Low
Required
High
Required
Output
and
Critical
and
Small
and
Critical
Low
0
Important
Important
and
5
and
Medium
Priority
High
Important
Required
and
Critical
MFs
and
Low
Important
High
V Important
0
and
Critical
Large
Medium
0
Very
Important
and
Large
Small
important
Important
5
5
LevnEstAggr
V Important
egate
V
n  {1,2,3}
alue MFs
Table 1

User Story Priority and Value aggregate Process (USPrioValAggragatePro):
takes the output variables of SHPrioValEstPro instances (Lev1EstAggregate ,
Lev2EstAggregate and Lev3EstAggregate) as inputs to generate an aggregation
(weight) of the priorities and values , that are estimated by all stakeholders
levels, for a certain user story . User Story Weight (USW) is The output variable
of USPrioValAggragatePro . the membership functions of input variable and
output variables and the rules
that control the output of
USPrioValAggragatePro are shown in table 2
Inputs
And Rules
Output
Required
important
Very
Important
Required
Small
Important
Small
V Important
Small
Required
Small
Important
Small
V Important
Small
Required
Small
Important
Medium
V Important
Medium
Required
0
5
Lev1EstAggreg
Required
Important
ate
Required
important
Small
Very
Important
0
V Important
Required
Medium
Important
Medium
V Important
Medium
Required
Medium
Required
0
5
Lev2EstAggreg
Important
ate
Important
Required
Required
important
Very
Important
Required
Medium
Important Medium
Important
Medium
V Important
Medium
Required
Medium
Important
Medium
V Important
Large
V Important
V Important Medium
0
5
Required
Lev3EstAggreg
Large
Important
V Important
Important
ate
V Important
Required
Large
Large
Large
V Important
Important
Large
V Important Large
Table 2
Medium
Large
5
USW

User Story Final Ranking Process (USFRPro): takes the output variables of
USPrioValAggragatePro (USW) , and the Estimated risk for each user story
as inputs . USFRPro generates a User Story Final Rank (USFR), which
represents the degree of importance of that story to the final product . USFR is
an aggregation of the priority , value and the risk associated with each user story
. The membership functions of input variable and output variables and , the
rules that control the output of USFRPro are shown in table 3.
Inputs
Small
Medium
And Rules
Not Risky
and
Large
and
Small
Risky
and
0
5
Definitely Risky
USW
Not
Risky
Risky
Not Risky
Definitely
Risky
0
Should have
Nice to have
Nice to have
Should have
and
Medium
Risky
0
Definitely Risky
Not Risky
and
Large
Should have Must have
Nice to have
Nice to have
and
5
Risk MFs
and
Output
and
Risky
and
Definitely Risky
Nice to have
Must have
5
USFR
Must have
Should have
Table 3
After applying USRP we need to adjusts USFR values to reflect the precedence
constraints that defined in section 3
4.3 Maintaining USFRs
In this process the ranks of user stories are maintained to achieve precedence
constraints. To do this let us define User Story Final Rank Vector (USFRV) of
dimension n to hold USFRs for n user stories . If usi is a precedence of usj
US[usi][[usj] ='P' . However , in some cases it could be found that
USFRV[usi ] < USFRV[usj] that means theoretically , usj should be implemented
earlier than usi , which is against the truth . Therefore USFRV contents should be
maintained to achieve precedence among different user stories . In other words the
following condition have to be meet : USFRV[usi] = USFRV[usj] + σ . The value of
σ should be less than the minimum difference between two USFR for all user
stories. The reason behind that is to eliminate the impact of maintaining process , to
be only on the stories that have precedence among each others . The following
algorithm is applied to find σ .
σ = Max (USFRV)
for (i=1 , i<= n, i++)
for (j=i , j<=n , j++)
if (ABS(USFRV[i] – USFRV[j]) < σ ) then
σ= ABS(USFRV[i] – USFRV[j])
end if
end for
end for
σ= σ/ Max (USFRV)
the following algorithm uses the value of σ and the contents of US to maintain the
USFRV .
for (i=1 , i<= n, i++)
for (j=i , j<=n , j++)
if ((US[i][j]='P' ) && (USFRV[i]<USFRV[j]))
USFRV[i]=USFRV[j]+ σ
End if
End for
End for
4.4 Determining the scope of the release
The scope of a release is the user stories that will be implemented in that release . In
this moment , all user stories are already ordered according to their effects to the final
product . Also each effort needed to implement each user story is already estimated .
in this stage release size is declared . The release size is the time that is specified to
finish the release . figure 4 shows the algorithm to determine the scope of the release
.
USFRV
….
Set Release Size
User stories List
Pickup user story with
max(USFR) .
Add to the Release Scope
Delete user story
No
Release Plan
subtract the effort needed to
implement this story from
release size
Release size <=0
Yes
5. Conclusion
End
The corner stone of XP process is the release planning. It is not worthy to apply XP
incremental fashion, if the customer does not receive the most important features in
the early releases . The problem of XP release planning is clear when there are
many stakeholders with different opinions and judgments . In this case, many
variables control release planning problem : the priorities and the values of the
requirements , from different stakeholders point views , and the risk associated
with each requirement . Furthermore the precedence's and coupling among
requirements have a clear effect on release planning process . Release planning is a
vague problem. It has a high degree of vagueness and uncertainty. Therefore fuzzy
theory is good choice to solve this problem. The proposed model that is presented
by this paper , is combined of four areas : I) specifying coupled and preceding
user stories For each user story, and represent them using graph data structure.
II)Using fuzzy system to generate a numerical decision (rank) , to order the user
stories according to their effect on the final product . III) Maintaining the values of
the user stories ranks to meet the precedence constraint. And IV) Determining the
scope of the release . in addition to that , the effort that is needed to finish the
release (release size) should be considered when the scope of the release is specified
.
6. References
[1] K. Beck, Extreme Programming Explained . Addison Wesley, Reading,
MA,2001.
[2] C.Cheng . A simple Fuzzy Group Decision Making Method . IEEE International
Fuzzy System Conference , 1999.
[3] William C, Wake, Extreme Programming Explored . Adison-Wesley Boston,
MA,2000.
[4] J.Denzinger, G.Ruhe, Decision Support for Software Release Planning Using eAssistants , journal , the journal of Decision Support Systems,2004.
[5] D.Greer, G.Ruhe, Software Release Planning: an evolutionary and iterative
approach, journal . the journal of Information and Software Technology 46 , 243253, 2004.
[6] J. Karlsson, k. Ryan , A Cost-Value Approach for Prioritizing Requirements .
IEEE software, 1997, pp. 67–74.
[7] T.J.Ross “Fuzzy logic Engineering application”. John Wily & sons
[8] George Klir “Fuzzy Sets and Fuzzy Logic Theory and Application ” .Prentice
Hall