Ashwin Kumar_MSE 697 Final

Approach to tackle Scrum Sprint Target Prioritization using AHP-GP
Prof. Ahmad Sarfaraz,
Ashwin Kumar Mosale Narayanaswamy
Manufacturing Systems Engineering and Management
California State University, Northridge
sarfaraz@csun.edu
ashwinkumar.mosalenarayanaswamy.18@my.csun.edu

Abstract
Project management has always been involving multi-criterion decision making situations that
use various techniques to make sound decisions. The decision making process has crucial
influence on the success of software projects as it requires speedy and short term decisions. Over
recent decades, agile software development (ASD) methodologies have been in the mainstream
for software development projects. Scrum among other agile methodologies is most used. This
study uses a combination of Analytic Hierarchy Process (AHP) and Goal Programming to create
a model which assists choosing the targets of a Scrum Sprint while considering the viewpoints of
all the involved stakeholders. AHP is a decision aid which can tackle problems involving
multiple objectives and is a useful decision tool to when there is uncertainty. Goal programming
measures the minimization of undesired deviations from targets. Therefore, it is the purpose of
this paper to help reach unanimity among the stakeholders for choosing certain goals using
weights obtained by AHP as inputs to Goal Programming model. This is first done by identifying
the most important criteria of a sprint and also considering four major alternatives a scrum team
have. Further, an aggregated model that takes into account all the viewpoints is built, indicating
the stakeholders would reach unanimity.
Keywords
Multi Criteria Optimization; Agile Software Development; Integrated AHP-GP; Scrum Sprints
1. Introduction
The evolution of organization, management, and production processes is moving towards more
complexity every day (AR Sarfaraz,2012) Management has always been involving complex
decision making situations that require selective abilities (Kamal M. 2001). A project’s essence,
the type of project and its timeline are important factors that have an influence on the failure of
agile methods (Chow & Cao, 2008). Agile is a set of methods based on incremental and iterative
development (Agile Alliance,2001). Agile methods in software development have drawn
significant consideration, given the ever-changing business environment, cost and competitive
pressures (Duka, 2013) challenging organizations on a daily basis. The need for producing better,
cost-effective software solutions and the necessity of delivering them faster has led major
software organizations to adopt agile development or scrum (Benefield, 2008). Organizations
delivering software projects in scrum development face the challenging task of selecting the
most appropriate goals to be set for a cycle (sprint). Delivery managers need to identify and
select from among several different backlogs, bugs and sprint user stories.
New Projects are great candidates for Scrum. Regular two to four-week sprint review
meetings give them a chance to view the latest product, clarify new requirements and define or
change the scope of the following iteration (Mohammed A. Bindrees, 2014) If your project
doesn't foresee any major alterations, then Scrum is certainly an overkill. You might even
question if an agile approach is the right tool at all. More traditional waterfall workflow can be
considered. It is very simple to understand and use. But in a waterfall model, each phase must be
completed fully before the next phase can begin. Kanban is great in many ways where Scrum has
limitation. It is a lean method, which means one of its main principles is to eliminate any waste.
There are no repeat steps, no sprint meetings and therefore no story pointing, only one

continuous flow. Kanban fits well when we have reached a certain level of maturity with many
process with as usual tasks, similar defects, smaller unrelated user stories and have less cross
functional teams
Scrum really pays off for projects which:
• have stakeholders who change their minds frequently
• require a product owner/ client response loop
• use stakeholders' feedback to priorities the next sprint
• have a cross functional team
Scrum might not be right fit for all projects, but looking at the choice of methodologies it is more
than likely that it will fit for most projects. A prioritized list of work items is a key artefact of
any agile development process. Take a SCRUM backlog as example, armed with such lists, the
team will be working on the most important tasks at any given time. The problem, however, is
that assigning preferences to details of a sprint doesn’t support a simple recipe. Prioritization aids
the implementation of a software system with privilege for requirements of each stakeholder (V
Ahl 2005). The act of prioritizing is the art of prioritizing. As with any art, there are always tips
and tricks. To prioritize requirements, stakeholders will have to compare the alternatives in order
to determine relative significance through a through weighting system (M. Kobayashi, M.
Maekawa 2001). These comparisons become complicated with increase in the number of
prerequisites (N.W. Kassel, B.A. Malloy 2003). AHP uses pair-wise likeliness ranking which
involves differentiating every possible choice to every other option for head to head
differentiation. This method allows team participation (Ramanathan, 2001), minimizes
manipulation/inconsistency which is often found in other weighting structure methods and is
more rapid and easily understood by all. AHP uses a set of criteria to analyse and rank
alternatives relative to each other, whereas GP lets decision makers to combine multiple and
potentially contrasting or independent objectives into one model that then attempts to yield the
best solution. The combined AHP-GP is used here to achieve the goal constraints while
minimizing the underutilization of the AHP scores.
1.1 Scrum Development
Among Agile Development Methodologies most widely accepted are Scrum, Crystal, Extreme
Programming and other methodologies (Begel, A. and N. Nagappan 2007). The word ‘scrum’
originated from a tactic in the game of rugby (K. Schwaber and M. Beedle ). Scrum is a
lightweight procedural framework for agile development, and the most commonly-used (what is
scrum link). SCRUM enforces individual responsibility, encourages the team members to set and
achieve short term targets, gives them a sense of ownership over the project, and helps them
increase productivity in the same amount of time. Scrum development is divided into sprints.
Each sprint begins with a planning meeting. In the forum, the product owner and the software
team agree upon the progress to be accomplished during the sprint. The software team has
decision making right when it comes to determining how many activities can realistically be
taken up in the sprint, and the product owner approves on what measure the needs are to be met
for the product to be accepted and authorized. The timespan of a sprint is decided by the scrum

master, the team's coordinator. Scrum Master is also responsible for ensuring that any
impediments are removed and altered in the process to keep the team operating as productively
as possible (Warsta et al, 2002). Traditionally, a sprint lasts 15 to 30 days. During the sprint, the
team holds daily scrum ceremony lasting 15-30 minutes to discuss advancement and
conceptualize solutions to problems. During any sprint only the scrum master has the power to
interject or hinder the sprint. At the end of the sprint, the team exhibits the finished work to the
project owner and the project owner measures the reached targets at the sprint meeting to make
the objective “done” or refuse the work to be delivered to “customer” (Michael Karlesky, Mark
Vander).
Figure 1. A normal scrum cycle
2. Methodology
2.1 Analytical Hierarchical Process
AHP is a systematic approach to analysing a problem that involves the consideration of the
multiple criteria in a hierarchical model. Decision-making is a comprehensive process that is
essential in everyday work we do (Saaty, 2004). AHP is a versatile decision aid which can
handle problems involving both multiple objectives and is a useful decision tool to merge variety
of evaluation data when uncertainty prevails (Zahi Abu-Sarhan 2011). AHP constitutes of,
1) Structure the hierarchy model for the problem by breaking it down into order of
complementing decision components
2) Define the factors and construct a pairwise likeliness matrix for them; each option on the
same position is compared with other criteria with respect to their significance to the main
objective

3) Establish a combination correlation matrix for alternatives with respect to each objective in
the separate matrices
4) Inspect the stability of the judgment inaccuracies by calculating the consistency ratio
5) Calculate the weighted average ranking for each decision option and select the one with the
highest score (Nidhi 2006)
2.2 AHP Formulation
The first step in AHP is construction of a pair-wise likeliness matrix. For this case, each of the
important processes of sprint should be compared against the other alternatives formed on each
collective measure separately. Error! Reference source not found. indicates an example of the
preference matrix for Nth selection criterion. Xij indicates the rank of option i with respect to
option j, based on Nth selection criterion and Xji is the reciprocal of Xij. After conducting the pair-
wise likeliness for each option, matrixes should be normalized by diving every score by
summation of the scores in same column. The relative priority of each option will be the mean of
normalized score within each row.
Table 1 - Preference matrix for Nth criterion
Criterion N 1 2 3 4
1 X11 X12 X13 X14
2 X21 X22 X23 X24
3 X31 X32 X33 X34
4 X41 X42 X43 X44
Table 2 - Preference matrix for selection criteria
Criterion
1
Criterion
2
Criterion
3
Criterion
4
Criterion
1
Y
11
Y
12
Y
13
Y
14
Criterion
2
Y
21
Y
22
Y
23
Y
24
Criterion
3
Y
31
Y
32
Y
33
Y
34
Criterion
4
Y
41
Y
42
Y
43
Y
44

These steps should also be used for the selection options to find the respective preference.
Error! Reference source not found. shows inclination matrix for pick criteria. Here Yij
indicates the rank of option i with respect to option j and Yji is the reciprocal of Yij.
The procedure described above gives us three sets of information including overall scores
of each option with respect to each measure, overall ranking of possibilities based on all
specifications and tallying of the criteria among themselves. This information will be then used
in the AHP-GP model.
2.3 Goal Programming
Goal programming is a type of linear programming model in which the objective function
measures the minimization of undesired deviations from targets (Michael Godfrey, Andrew
Manikas 2014). Decision makers often deal with conflicting team members. Goal programming
is a mathematical programming model that helps decision makers finds an optimum solution to
solve multiple and often conflicting problems (Charnes, Cooper and Ferguson 1955). The
purpose of using GP model is to reach goals as per given priorities by applying constraints to
each objective. The model first aims to achieve the first goal. Once the goal is met the values or
the deviational variables are added as constraints and the process is repeated until all goals are
met.
It became a widely applied technique due to its capability to handle decisions of numerous
contrasting goals. Also, the actual purpose of a goal programming prototype may consist of non-
identical elements of measurement. If the decision maker is more concerned in direct correlation
of the objectives, then the weighted goal programming is used.
2.4 Goal Programming Formulation
In process of evaluating sprint activities, the first goal is not to violate restrictions and limitations
associated with the problem which vary depending on the project requirements. On this study we
decided to define four factors to be considered in our decision. Rework is the first system
limitation defined in this model as it is a crucial factor for project completion. Complexity of
product is second restriction in this model. The GP model also aims to maximize
communication and re-use deliverables which are two most important concerns. Project
failures are numerous in practice, many a times budget and schedule overruns are the major
cause for projects to fail (Kouroush Jenab,Sam Khoury,Ahmad Sarfaraz 2012). So here we will
consider extra time and costs that come up when there is a delay. In these equations 𝑑𝑖
−
and 𝑑𝑖
+
are deviational variables representing how much below and above the specification will be
achieved respectively.
∑ 𝑎𝑖 𝑥 𝑖 + 𝑑𝑔1
−
− 𝑑𝑔1
+
= 𝐺1𝑛
𝑖=1 (1)
∑ 𝑏𝑖 𝑥 𝑖 + 𝑑𝑔2
−
− 𝑑𝑔2
+
= 𝐺2𝑛
𝑖=1 (2)
∑ 𝑐𝑖 𝑥 𝑖 + 𝑑𝑔3
−
− 𝑑𝑔3
+
= 𝐺3𝑛
𝑖=1 (3)
∑ 𝑑𝑖 𝑥 𝑖 + 𝑑𝑔4
−
− 𝑑𝑔4
+
= 𝐺4𝑛
𝑖=1 (4)

∑ 𝑒𝑖 𝑥 𝑖 + 𝑑𝑔1
−
− 𝑑𝑔1
+
= 𝐺5𝑛
𝑖=1 (5)
Where,
G1- Overall Rating Goal
G2 – Design Phase Rating Goal
G3 – Coding Phase Rating Goal
G4 – Testing Phase Rating Goal
G5 – Requirement Gathering Phase Rating Goal
The overall objective including the AHP constraints can be stated as:
𝑀𝑖𝑛( 𝑍) = 𝑃1(𝑑𝐴+
+𝑑𝐵+
+ 𝑑𝐶−
+ 𝑑𝐷−
+ 𝑑𝐸−
+ 𝑑𝑃+
)
2.5 Combining AHP and GP
AHP and GP integration is used to help companies rank and select suppliers (Sharma and
Balan 2013). Specifically, AHP is used to evaluate weights for each criterion, which then feed
into the GP model that selects the best available alternative. Similar combined model is used to
determine the best location for building a new facility (M. A. Badri,1999). In both the above
cases, AHP is used to calculate weights and inputs before feeding them into the GP model. The
goal programming alone does not provide enough information about decision maker preferences
in objective function. In order to overcome this problem, we have combined to combine AHP
and GP (Lin, Pourmohammadi and Sarfaraz 2015).
AHP and GP is also used to evaluate quantitative and qualitative factors in selecting the
best suppliers and allocating the optimum order quantities among them” (Percin 2006). This
paper will take the same approach to decide the best among the alternatives. The model
presented in this paper will split quantitative and qualitative factors between AHP-GP and allow
the GP portion of the model to readily adapt to decision makers’ preferences.
In the combined model, the deviational variables associated with AHP model are
included in the objective function. In comparison to GP model, combined model has two more
set of constrains and deviational variables.
AHP method is used to derive ratio scales from paired comparisons between user stories.
The input can be obtained from weight of subjective opinion from team members and the
product owner’s preference. In AHP-GP model, there are two more set of constraints and
deviational variables. The first set is based on AHP overall ranking and second set is based on
each of the criteria in AHP model.
2.6 AHP-GP methodology for Scrum Development
a) Identifying user stories / alternatives from the view point of all the stakeholders

b) Building the hierarchy for each alternative and using the AHP method to compare pair wise
c) Estimating priority by assigning criteria weights and by finding the consistency of the index
d) Using the weights for comparing performance of the options with respect to the available
choices as inputs to Goal Programming model.
3 Objective
The Agile team makes most commitments, building a shared decision-making condition on the
basis of varying experiences, nature, and attitudes of team members. Chin, G. (2004). Cockburn,
A. and J. Highsmith (2001). The Goal of this research paper is to improve the quality of
prioritizing precisely the work will be achieved during a sprint. We are applying pair wise
likeliness calculating AHP model and Goal Programming to examine variations in choosing the
alternative. The aim of the study is to analyse development teams’ abilities in prioritizing user
story alternatives keeping in mind the release needs for a particular iteration/sprint. There is
substantial evidence reported in literature that the expert estimates tend to be over-optimistic
(Jørgensen M. A 2004). The poker evaluation used by normally does not completely remove the
over-hopeful (Moløkken–Ostvold 2008). It is agreed that the Product Owner will take only those
stories that were completely reliable and robust for the end users.
4 Case Study
4.1 Problem Description
Development starts by defining and analysing the requirements for the software (Duka,
2013). Tasks are completed sequentially, step-by-step, from requirements analysis to
maintenance (Purcell, 2012). Requirements are largely unstable. A review of the software
development unit uncovered several issues involving the agile software development and
delivery process. Due to fast-paced changes in the technology industry, however, the agile
development cycle suffered from incompatibility between delivered functionality and end-user
assumptions. Using this method, the requirements are reviewed by an analyst, the coder coded,
the designer designed, and so on. The complexity of each release increased as the scrum
backlogs grew. More requirements were subject to change or addition during the release
timeframe. The releases, however, were not fulfilling changing requirements, and customer
expectations, and the timeframes between them were unacceptable. As a consequence, managers
were looking for a better solution to declining team-spirit and hardships in responding to
frequent changes and demands.
The most important ingredients for building a team are no communication gap, common views,
active participation, equal ownership and collective goals. (Jeff Sutherland, Guido Schoonheim,
N. Kumar, V. Pandey, S. Visha 2009). On complex development projects, it can take a new
engineer several months to come up to full productivity. (Abdel-Hamid 1996). Identifying the
single most important impediment, removing it before the end of the next, put it in the Sprint
Backlog as a user story with acceptance tests that will determine when it is Done. (Jeff
Sutherland, Neil Harrison, Joel Riddle 2014) Then evaluate the state of the story in the Sprint
Review like any other story can reduce the rework and improve quality. Software Product Line
Engineering is an approach for the scheduled and standard reuse of software components or

platforms for a line of products. (Antonio Martini, Lars Pareto, Jan Bosch 2013). By using SPLE
we can decrease the amount of work in future sprints by building reusable items in each sprint.
From many other studies we came to conclusion that Rework, Complexity of product,
communication and re-use deliverables are the most important concerns to that needs to be.
4.2 Problem Formulation
In this section, selecting each criteria and alternatives problem will be formulated. It illustrates
how the combined AHP-GP model can be applied to a real world cases.
4.3 AHP Matrix
For pairwise comparison of alternatives and decision criteria we have the below matrices from
Table 3 and. Fig 2 explains the goal, criteria and decision alternatives. Table 4 has pairwise
comparison at criteria level. Tables 5-13 have pairwise comparison of alternatives at each phase.
Table 3 - Preference matrix for selection criteria
Overall
Goal
Selection of right targets for SPRINT
Criteria Design Coding Testing
Requirement
Gathering
Decision
Alternatives
Rework Rework Rework Rework
Complexity Complexity Complexity Complexity
Re useable
deliverables
Re useable
deliverables
Re useable
deliverables
Re useable
deliverables
Communication Communication Communication Communication
Figure 2: Goal, Criteria and Decision Alternatives

Table 4 - Pairwise Comparison of criteria
Most Imp How much more important Rating
Design – Coding Coding Moderately 3
Design – Testing Design Moderately 3
Design - Requirement Gathering Design Extremely 7
Coding – Testing Coding Important 5
Coding - Requirement Gathering Coding Extremely 7
Testing - Requirement Gathering Testing Important 5
Table 5 - Pairwise Comparison of alternatives during Design Phase
Design
Rework – Complexity Complexity Moderately 3
Rework - Re usable deliverables Rework Moderately 3
Rework – Communication Rework Extremely 7
Complexity - Re usable deliverables Complexity Important 5
Complexity –Communication Complexity Important 5
Re usable deliverables –
Communication
Re usable
deliverables
Moderately 3
Table 6 - Pairwise Comparison of alternatives during Coding Phase
Coding
Rework – Complexity Complexity Extremely 7
Rework - Reusable deliverables
Re usable
deliverables
Moderately 3
Rework – Communication Communication Moderately 3
Complexity - Re useable deliverables Complexity Extremely 7
Complexity –Communication Complexity Important 5
Reusable deliverables –
Communication
Re usable
deliverables
Moderately 3

Table 7 - Pairwise Comparison of alternatives during Testing Phase
Testing
Rework – Complexity Rework Moderately 3
Rework - Re usable deliverables Rework Moderately 3
Rework – Communication Rework Moderately 3
Complexity - Re usable deliverables
Re useable
deliverables
Important 5
Complexity –Communication Communication Important 5
Communication
Communication Extremely 7
Table 8 - Pairwise Comparison of alternatives during Requirement Gathering Phase
Requirement
Gathering
Rework – Complexity Complexity Moderately 3
Rework - Re useable deliverables
Re useable
deliverables
Moderately 3
Rework – Communication Communication Extremely 7
Complexity - Re useable deliverables Complexity Moderately 3
Complexity –Communication Communication Extremely 7
Communication
Communication Extremely 7
Table 9 - Pairwise Comparison matrix during Design Phase
Design
Rework Complexity Re useable deliverables Communication Priority
Rework 1 1/3 3 3 0.24
Complexity 3 1 5 5 0.54
Re useable deliverables 1/3 1/5 1 3 0.135
Communication 1/3 1/5 1/3 1 0.076
4 2/3 1 ¾ 9 1/3 12

Table 10 - Pairwise Comparison matrix during Coding Phase
Coding
Rework 1 1/7 1/3 1/3 0.06
Complexity 7 1 7 5 0.63
Re useable deliverables 3 1/7 1 3 0.19
Communication 3 1/5 1/3 1 0.12
14 1 ½ 8 2/3 9 1/3
Table 11 - Pairwise Comparison matrix during Testing Phase
Testing
Rework 1 3 3 3 0.42
Complexity 1/3 1 1/5 1/5 0.08
Re useable deliverables 1/3 5 1 1/7 0.16
Communication 1/3 5 7 1 0.34
2 14 11 1/5 4 1/3
Table 12 - Pairwise Comparison matrix during Requirement Gathering Phase
Requirement Gathering
Rework 1 1/3 1/3 1/7 0.06
Complexity 3 1 3 1/7 0.17
Re useable deliverables 3 1/3 1 1/7 0.11
Communication 7 7 7 1 0.66

14 8 2/3 11 1/3 1 3/7
Table 13 - Pairwise Comparison overall scores
Design Coding Testing Requirement Gathering Overall Priority
Rework 0.24 0.06 0.42 0.06 0.1614
Complexity 0.54 0.63 0.08 0.17 0.5111
Re useable deliverables 0.135 0.19 0.16 0.11 0.1683
Communication 0.076 0.12 0.34 0.66 0.16668
To measure the degree of the pair-wise comparison, the consistency index must be calculated in
Table 14. It would be acceptable if the consistency index is less than 0.1.
Table 14 – Consistence of the overall scores
Average 4.247
Consistency Index 0.082425654
Consistency Ratio (RI = 0.9) 0.09158406
4.4 The Extra Costs:
The cost criterion is the total extra cost for each alternative irrespective of the phase. The
objective is to minimize this cost to $9/hr. Table 15 has the costs involved.
Table 15 – Extra Cost/hr. involved for each alternative
Alternative Cost/hr.
Rework 20
Complexity 8
Re useable
deliverables
5
Communication 5
20* 𝑥1+ 8 * 𝑥2 + 5 * 𝑥3 + 5* 𝑥4 ≤ 9 (6)

4.5 The Extra Time:
The time criterion is the total extra time for each alternative in a sprint irrespective of the phase.
The objective is to keep the sprint time to be 2 weeks or 80hr. Table 16 has time requirements.
Table 16 – Time in hours involved for each alternative
Alternative Time
Rework 15
Complexity 50
Re useable
deliverables
5
Communication 5
15* 𝑥1+ 50 * 𝑥2 + 5 * 𝑥3 + 5* 𝑥4 ≤ 80 (7)
4.6 GP Formulations
20* 𝑥1+ 8 * 𝑥2 + 5 * 𝑥3 + 5* 𝑥4 ≤ 9 (6)
15* 𝑥1+ 50 * 𝑥2 + 5 * 𝑥3 + 5* 𝑥4 ≤ 80 (7)
0.1614* 𝑥1 + 0.5111 * 𝑥2 + 0.1683 * 𝑥3 + 0.16668 * 𝑥4 + 𝑑𝐴−
- 𝑑𝐴+
= 0.511 (8)
0.24 * 𝑥1+ 0.54 * 𝑥2 + 0.135 * 𝑥3 + 0.076* 𝑥4 + 𝑑𝐵−
- 𝑑𝐵+
= 0.54 (9)
0.06 * 𝑥1+ 0.63 * 𝑥2 + 0.19 * 𝑥3 + 0.12 * 𝑥4 + 𝑑𝐶−
- 𝑑𝐶+
= 0.63 (10)
0.42 * 𝑥1+ 0.08 * 𝑥2 + 0.16* 𝑥3 + 0.34 * 𝑥4 + 𝑑𝐷−
- 𝑑𝐷+
= 0.42 (11)
0.06 * 𝑥1+ 0.17 * 𝑥2 + 0.11 * 𝑥3 + 0.66 * 𝑥4+ 𝑑𝐸−
- 𝑑𝐸+
= 0.66 (12)
𝑥1+ 𝑥2 + 𝑥3 + 𝑥4 + 𝑑𝑃−
− 𝑑𝑃+
= 1 (13)
4.7 Objective Function
𝑀𝑖𝑛( 𝑍) = 𝑃1(𝑑𝐴+
+𝑑𝐵+
+ 𝑑𝐶−
+ 𝑑𝐷−
+ 𝑑𝐸−
+ 𝑑𝑃+
) (14)
5 Conclusion and Discussion
Solving the AHP-GP combined model using TORA, shows that under the current constraints X4
which represent Communication should be given most importance and the best alternative that
suits and fits the requirements. In this paper an AHP model was used to weigh different criteria

and sub-criteria that are involved in the scrum sprint. The AHP model was also used to prioritize
the criteria and Sub-criteria as well as comparing four different alternatives.
A GP-AHP combined model was solved to ensure achieving the optimum solution so that
selecting the alternative based on the AHP weights incorporates the given constraints. We can
further use this method to multiple sprints in a development process, to find the best alternative
that would not only help reach targets of the present sprint but also the upcoming sprints. In
general, there are some aspects of software development project can benefit from above
approach. When it comes to methodologies, each project is different. One thing is clear: that
there is no “one-size-fits all” solution.
References:
1. Abdel-Hamid, T.K., The Slippery Path to Productivity Improvement. IEEE Software,
1996.
2. AR Sarfaraz, K Jenab International Journal of Enterprise Information Systems (IJEIS) 8
(1), 1-16 International Journal of Enterprise Information Systems (IJEIS), volume 8 issue
1 (1 January 2012),
3. Antonio Martini, Lars Pareto, Jan Bosch 2013, Communication Factors for Speed and
Reuse in Large Scale Agile Software Development
4. Begel, A. and N. Nagappan (2007). Usage and Perceptions of Agile Software
Development in an Industrial Context: An Exploratory Study. Proceedings of the First
International Symposium on Empirical Software Engineering and Measurement, IEEE
Computer Society: 255-264
5. Benefield, G. (2008). Rolling Out Agile in a Large Enterprise. In Proceedings of the 41st
Annual Hawaii International, Conference on System Sciences, 461–461. IEEE.
doi:10.1109/HICSS.2008.382
6. Charnes, Abraham, William W. Cooper, and Robert O. Ferguson. 1955. “Optimal
estimation of executive compensation by linear programming.” Management science 1
(2): 138-151.
7. Chin, G. (2004). Agile project management: how to succeed in the face of
changing project requirements, A Division of American Management Association
8. Chow, T., & Cao, D. B. (2008). A survey study of critical success factors in agile
software projects. Journal of Systems and Software, 81(6), 961–971.
9. Cockburn, A. and J. Highsmith (2001). "Agile software development, the people factor."
Computer 34(11): 131-133.
10. Duka, D. (2013). Adoption of agile methodology in software development. In
Proceedings of 34th International Convention on Information and Communication
technology, electronics and microelectronics. IEEE.
11. Jørgensen M. A review of studies on expert estimation of software development effort //
Journal of Systems and Software, 2004. – Vol. 70. – No.1, 2. – P. 37–60.
12. Jeff Sutherland, Guido Schoonheim, N. Kumar, V. Pandey, S. Visha 2009, Linear
Scalability of Production between San Francisco and India
13. Jeff Sutherland, Neil Harrison, Joel Riddle 2014, Teams that Finish Early Accelerate
Faster: A Pattern Language for High Performing Scrum Teams
14. Kamal M. Application of the AHP in project management. International Journal of
Project Management, 2001, v19, pp19-27.

15. Kouroush Jenab,Sam Khoury,Ahmad Sarfaraz,Manufacturing Complexity Analysis with
Fuzzy AHP,International Journal of Strategic Decision Sciences, 3(2), 31-46, April-June
2012 31
16. K. Schwaber and M. Beedle, Agile Software Development with Scrum, Upper Saddle
River, NJ, Prentice – Hall, 1st Edition, Oct 2001
17. M. A. Badri, Combining the analytic hierarchy process and goal programming for global
facility location-allocation problem 1999
18. Michael Godfrey, Andrew Manikas 2014, INTEGRATING SUSTAINABILITY INTO A
GOAL PROGRAMMING EXERCISE
19. Michael Karlesky, Mark Vander, “Agile Project Management (or, Burning Your Gantt
Charts)”, Embedded Systems Conference Boston (Boston, Massachusetts) ESC 247-267,
October 2008
20. Mohammed A. Bindrees, Robert J. Pooley, Idris S. Ibrahim, Nick K. Taylor, Re-
Evaluating Media Richness Theory in Software Development Settings
21. Moløkken–Ostvold K., Haugen N. C., Benestad H. C. Using planning poker for
combining expert estimates in software projects // Journal of Systems and Software,
2008. – Vol. 81. – No. 12. – P. 2106–2117. 16.
22. M. Kobayashi, M. Maekawa, Need-based requirements change management, in: Proc.
ECBS 2001 Eighth Annual IEEE International Conference and Workshop on the
Engineering of Computer Based Systems, 2001, pp. 171–178.
23. N.W. Kassel, B.A. Malloy, An approach to automate requirements elicitation and
specification, in: Proc. of the 7th IASTED International Conference on Software
Engineering and Applications, Marina Del Rey, CA, USA, 3–5 November 2003.
24. Nidhi Tiwari. Using the Analytic Hierarchy Process (AHP) to Identify Performance
Scenarios for Enterprise Application, March 2006
25. A combined AHP-GP model for selecting and awarding design-build construction
contracts Patrick Lin, Hamid Pourmohammadi and Ahmad R. Sarfaraz
26. Percin, Selcuk (2006). “An application of the integrated AHP-PGP model in supplier
selection.” Measuring Business Excellence 10, no. 4. pp.34-49.
27. “Principles behind the Agile Manifesto," The Agile Alliance, 11 2 2001. [Online].
Available: http://agilemanifesto.org/principles.html. [Accessed 29 5 2014].
28. Purcell, J. (2012). Comparison of software development lifecycle methodologies. SANS
Institute.
29. Ramanathan, R., 2001. A note on the use of the analytic hierarchy process for
environmental impact assessment. Journal of Environmental Management 63, 27−35.
30. Saaty, T. L. (2004). Decision Making – The Analytical Hierarchy and Network Process.
Journal of Systems Science and Systems Engineering, Vol. 13, No. 1, 1
31. Sharma, Sanjay, and Srinivasan Balan (2013). “An integrative supplier selection model
using Taguchi loss function, TOPSIS and multi criteria goal programming.” Journal of
Intelligent Manufacturing 24, no. 6. pp.1123-1130
32. V. Ahl. An experimental comparison of five prioritization methods – investigating ease
of use, accuracy and scalability, Master’s Thesis, School of Engineering, Blekinge
Institute of Technology, Sweden, August 2005
33. Warsta, J., Abrahamsson, P., Salo, O., & Ronkainen, J., Agile Software De-velopment
Methods, VIT Publications 478, 2002.

34. Zahi Abu-Sarhan. Application of Analytic Hierarchy Process (AHP) In The Evaluation
and Selection Of an Information System Reengineering Projects. International Journal of
Computer Science and Network Security, 2011,v11(1), pp172-177.
35. http://taha.ineg.uark.edu/tora.html
36. http://www.cprime.com/resources/what-is-agile-what-is-scrum/
Appendix
Software called TORA is used to get solution for the AHP-GP combined model.
Fig 3: TORA Output
Fig 4: TORA Output

Ashwin Kumar_MSE 697 Final

More Related Content

What's hot (20)

Similar to Ashwin Kumar_MSE 697 Final (20)

Ashwin Kumar_MSE 697 Final