The World of Agile Software Development

Abstract

Software engineering is a relatively new field. Technology is going through rapid improvement and best development practices and methods are constantly being created. These characteristics are reasons which make software projects difficult to manage. Developers and managers have struggled to find suitable models and practices, but troubles have persisted. Missed deadlines and failure of projects is common in the software engineering industry. Software projects cannot be carried out in the same way as projects in traditional industries and thus new methods and practices are required. Agile software development has brought new insight into the way software projects are being approached and offers effective ways to deal with the complexity of software development. Agile is a framework that promotes development iterations throughout the life-cycle of a project. It minimizes risk by developing software in short amounts of time. This paper presents an overview of Agile Project Management & Development Methods.  

The purpose of this paper is to compare traditional waterfall project standards and deliverables with those in Agile

1. Introduction

For decades, software development projects have followed the classic “waterfall” methodology in which software development initiatives were carefully analyzed, designed, documented, coded, tested, and ultimately delivered to the customer. It may sometimes take years after inception. By then, it was not uncommon for business needs to have changed and for the resulting system to fall short of customers’ expectations. According to the Standish Group, software development projects have an overall success rate of 34%. In response to this rather disappointing approach to software development, “Agile” methodologies – which are light on documentation and formality - began to emerge in the 1990’s. Scrum, which is one of several Agile approaches, was first developed and presented in 1995 so it is relatively novel when compared with traditional software development processes which have been used for decades.

Software development is not a defined process; it differs from physical engineering processes. A physical engineering process consists of distinct phases. The design phase is difficult to predict and requires creativity and imagination. The primary activities in the design phase are intellectual. The design phase is followed by planning for the construction phase, and then by the construction phases itself. The primary activities in the construction phase are physical, and it is much easier to plan and predict than the design phase. In many physical engineering disciplines construction is much bigger in both cost and time than design and planning. For example, when you build a bridge, the cost of design is about 10% of the total job, with the rest being construction. For the analogy between software development and physical engineering to hold, we need to be able to separate design from construction, be able to produce a predictable schedule, design artifacts that are complete enough for construction to be straightforward, and be able to perform construction with people of lower skills (who are hopefully cheaper to employ). Construction also needs to be sufficiently large in time and effort to make this worthwhile. The situation in software development is quite different. Different experts report the following breakdown of Software development by activity:

· Analysis 16%

· Design 17%

· Code/Unit Test 34%

· System/Integration Test 18%

· Documentation 8%

· Implementation/Install 7%

2. The Pitfalls of Traditional Methodologies

Traditional methodologies try to be predictive - to create a schedule at the beginning of a project and to conform to this schedule for the life of the project [1].Complex software systems can be built in a sequential, phase-wise manner where all of the requirements are gathered at the beginning, all of the design is completed next, and finally the master design is implemented into production quality software. This approach holds that complex systems can be built in a single pass, without going back and revisiting requirements or design ideas in light of changing business or technology conditions. Yet a common complaint is “the problem with this project is that the users keep changing their minds”. In the physical world people accept that requirements need to be fixed because it's intuitively obvious to them that, because of the expensive construction phase, it's very expensive to make changes after a certain point.

Figure 1: Traditional Sequential Approach.

However, software is much less tangible. Not only is it hard to be precise about what's needed, it's also hard to see why it should be difficult to change later. Customers expect software to be soft. Traditional methodologies establish procedures that discourage requirements changes, they resist change. This helps them maintain a predictable schedule, but it does nothing to ensure that the final results meet the customer’s real, changing needs.

3. Emergence of Agile Software Development

During the 90s a number of different people realised that things had somehow changed [2]. These people became interested in developing software methodologies that were a better fit with the new business. Although the details of these methodologies differ, they all share certain underlying principles, to the extent that these methodologies are often now grouped under the title “agile methodologies”.

3. Agile Software Development

 Agile practitioners pride themselves on highly productive, responsive, low ceremony, lightweight, tacit knowledge processes with little waste, adaptive planning and frequent iterative delivery of value. Agile follows iterative approach having overlapping phases of software development as in figure 2.

Figure 2. Iterative Approach

The methodologies falling under the “agile” umbrella all address these issues in slightly different ways, however the agile methodologies do have common underlying values and principles. The Agile Alliance expressed the values in the Agile Manifesto[3].

· Individuals and interactions over processes and tools

· Working software over comprehensive documentation

· Customer collaboration over contract negotiation

· Responding to change over following a plan

4. Agile Principles

Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. Some of the principles behind the Agile Manifesto[4] are:

• Customer satisfaction by rapid, continuous delivery of useful software.

• Working software is delivered frequently (weeks rather than months).

• Working software is the principal measure of progress.

• Even late changes in requirements are welcomed (this does not mean code & run. Instead removing an existing feature or moving a deadline forward to accommodate late/unplanned feature requests.

• Close, daily cooperation between business people and developers

• Face-to-face conversation is the best form of communication (Co-location)

• Projects are built around motivated individuals, who should be trusted

• Continuous attention to technical excellence and good design

• Simplicity

• Self-organizing teams

• Regular adaptation to changing circumstances

5. Agile Life Cycle

Agile methods break tasks into small increments with minimal planning, and don't directly involve long-term planning. Iterations are short time frames that typically last from one to four weeks. Each iteration is worked on by a team through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders[6].Multiple iterations may be required to release a product or new features as shown in Figure 3.

Figure 3: Multiple iterations to release a product in Agile development

This helps minimize overall risk, and lets the project adapt to changes quickly. Stakeholders produce documentation as required. An iteration may not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration.

Agile methods emphasize face-to-face communication over written documents when the team is all in the same location. When a team works in different locations, they maintain daily contact through videoconferencing, voice, e-mail, etc. Most agile teams work in a single open office (called bullpen), which facilitates such communication. Team size is typically small (5-9 people) to help make team communication and team collaboration easier. Larger development efforts may be delivered by multiple teams working toward a common goal or different parts of efforts. This may also require a coordination of priorities across teams.

6. Agile Burn-down Chart

The Burn-down Chart is used as a tool to guide the development team to successful completion of a Sprint on time with working code that is potentially shippable as a product. On a Agile project, the team tracks its progress against a release plan by updating a release burn-down chart [7] at the end of each sprint.

Figure 4: Agile Burn-down Chart

The horizontal axis of the release burn-down chart shows the sprints as in figure 4; the vertical axis shows the amount of work remaining at the start of each sprint. Work remaining can be shown in whatever unit the team prefers--story points, ideal days, team days, and so on. The cost of curve in Agile is as shown in figure below.

Figure 5: Cost of Change Curve

Agile visionary Kent Beck challenged the traditional cost of change curve evidenced by Barry Boehm [1] over twenty years ago. Beck’s method espouses that the cost of change can be inexpensive even late in the project lifecycle while maintaining or increasing system quality as shown in Figure 5.

Conclusion: The demands of the world we live in require more information to be available faster than any time in history. To remain competitive, an organization must be able to respond to this demand. Agile software development methodologies have demonstrated their ability to help information technology organizations respond to this growing demand for their services. Agile methodology is intended to achieve results that are often not possible using traditional approaches. These methods build in processes intended to clear the tracks for the express development train to move at extreme speeds. Agile methods get results by Removing impediments to progress, Assuring prompt and timely decision making, Isolating the project and team members from irrelevant issues, Utilizing all resources and expertise required to achieve success and Focusing the attention of team members on the extreme project and nothing else.

References:

[1] “Agile Software Development”, Alistair Cockburn, Pearson Education, 2002.

[2] “Agile Software Development Methods”, Pekka Abrahmson, Outi Salo, Jussi

       Ronkainen, Juhani Warsta, VTT Publications 478, ESPOO 2002.

[3] Beck, K. Manifesto for Agile Software Development. WWW page of the Agile 

     Manifesto: http://agilemanifesto.org/., Oct 2007.

[4] Beck, K. Principles of the Agile Manifesto. WWW page of the Principles of the Agile  

     Manifesto: http://agilemanifesto.org/principles.html., Oct 2007.

[5] Agile Alliance. WWW page of the AgileAlliance: http://www.agilealliance.org/,

      Oct 2007.

[6] “The Agile System Development Life Cycle”,Scott W.Ambler, Ambysoft,  

      Managing  Agile Projects, 2005.

 [7] “An Introduction to Agile Software Development” Victor Szalvay, Danube  

       Technologies, November 2004.

[8] “Agile Software Development Methods: Review and Analysis,” Abrahamsson, 

      Pekka, Outi Salo, Jussi Ronkainen, and Juhani Warsta  Proceeding of ESPOO 2002.

Estimation In SCRUM Using Project Delay-Related Factors

Abstract:The key measures of any project about its perfectness are ability to complete in the scheduled time and within the estimated cost. Cost and effort are important factors whenever a project is developed. The estimation of cost and effort is a difficult task in Agile environment. The Scrum is the widely used method of Agile. Most of the software development organizations are using Scrum these days but these are facing problems related to estimation. It has been observed that the current estimation method in Scrum mostly rely on historical data from past projects and expert opinion but in absence of historical data and experts these methods are not efficient. So there is need of an algorithmic method, which can calculate cost and effort of the software project. In this direction S.Bhalero, Maya Ingle [2] has considered some project-related factors that calculate the cost as well as effort of the project for a general Agile environment. However, several other delay related factors may affect the Scrum environment. In this work an Algorithmic estimation method is being proposed considering various factors that can delay the project thereby estimating the more accurate release date, cost, effort and duration for the project specifically for Scrum. The effectiveness and feasibility of the proposed algorithm has been shown by considering case study in which different levels of factors are taken and compared.

1. INTRODUCTION

Agile development is now accepted globally as the best way to develop, maintain, and support software systems. Scrum is designed to add energy, focus, clarity, and transparency to project planning and implementation. Scrum is a simple frameworkused to organize teams and get work done more productively with higher quality. It allows teams to choose the amount of work to be done and decide how best todo it, thereby providing a more enjoyable and productive working environment. Scrum is composed of the following project management practices: The Product Owner creates the requirements, prioritizes them, and documents them in the Product Backlog during Release Planning. In Scrum, requirements are called features. Scrum teams work in short iterations. When Scrum was first defined [1, 2], iterations were 30-days long. More recently Scrum teams often use even shorter iterations, such as two-week iterations. In Scrum, the current iteration is called the sprint.The estimation of cost, effort, size and duration of a software project in a sprint is a difficult task. The accurate estimations of software are critical for both developer and customer. Ignorance of estimation methods may cause serious effects like exceeding the budget, notdelivered on time, poor quality and not right product. So estimation of software is important that involves the determination of effort (person-month), duration (in months) and cost (in rupees). Moreover it becomes more complex when requirements of the project are changed continuously.There is a fundamental problem applying accurate estimation and tracking due to the quality of baseline plan and unclear project scope for scrum project due to volatile requirements. In Scrum, the estimation is done by historical data from past projects which are not efficient. However, there may be various project related factors that may affect the project estimation. Moreover, people related factors may also affect the project development as per Agile principles. Therefore, delay-related factors that can cause delay in a project must be considered while estimating in Scrum environment. Thus an algorithmic method that quantifies various project delay related factors has been proposed in this work.

 In Section II currently used estimation technique for Scrum is discussed. In Section III related work in field of Scrum estimation is described and in Section IV problems related to estimation in Scrum are discussed andSection V describes proposed Sprint-points, factors and algorithm. In Section VI feasibility of our algorithm is shown, Section VII contains the Conclusion and future work.

2. SCRUM ESTIMATION TECHNIQUES

Estimation is the process that is used to estimate the cost, effort and the time taken to complete the project which is going to be developed. The process of estimation starts from the planning phase and refined throughout the project. Agile methods adopt the practice of accepting last minute changes in the software through gathering the requirements in iterative and incremental manner [13]. Some approaches of estimation in Agile are in table below.

                                              TABLE I -  Agile Estimation methods

S.No	Approaches of Agile Estimation
	Name of approach	Working	Problem
1.	Learning-oriented Approach	This approach is based on the collective learning from previous estimation experience and knowledge of several managers drawn from the results of many specific projects.	This method is not used as it may provide very unrealistic estimates.
2.	Expertise-based Approach	In this technique an expert compare the project with similar past projects based on personal memory.	It requires opinion of multiple experts.
3.	Regression methods	This model is based on regression data and developing regression equations to make estimates.	It does not promote good software engineering practice.
4.	Bottom-Up	In this method each component of the software system is separately estimated and the results aggregated to produce an estimate for the overall system.	How the system is decomposed into different components

3. RELATED WORK

S.Bhalero, Maya Ingle [2] proposed an algorithm for cost estimation by incorporating various factors with different intensity levels. These factors include mainly project domain, configuration, performance, complex processing, data transaction, operation ease, multiple sites and security. But various factors like communication skill, managerial skill, and familiarity in team are missing.

      Jamieson [8] pointed out a number of problems with current estimation models in scrum. First, the procurer must often allocate the budget without sufficiently understanding the requirements. Thus, the budget often does not reflect the true scope of the effort, resulting in heavy and costly change management, budget over-runs, and delays. The most established methods of estimating the cost of software development require more data than is typically available to the supplier bidding on a tender from the procurer, resulting in misunderstandings, inaccurate quotes, and frequently, an adversarial relationship between the procurer’s contract manager and the supplier.

Benediktsson [11] investigated the impact of software development approach on the resulting product and its attributes by comparing V-model (VM), evolutionary model (EM), incremental model (IM), and extreme programming (XP).His findings were that XP and Scrum method provides more quality and productivity.

      Williams et al. [7, 9] investigated the usage of a subset of XP [5] practices at a group in IBM. The product developed at IBM using XP was found to have significantly better pre-release and post-release quality compared to an older release. The teams using XP reported an improvement in productivity, schedule, cost and effort estimation. In addition, customers were more satisfied with the product developed using XP because the teams delivered more than what the customers had originally asked for.

Heemstra [10] surveyed 364 organizations and found that only 51 used models to estimate effort and that the model users made no better estimate than the non-model users. Also, use of estimation models was no better than expert judgment.

       Finnie and Wittig [12] applied artificial neural networks (ANN) and case-based reasoning (CBR) to estimation of effort. Using a data set from the Australian Software Metrics Association, ANN was able to estimate development effort within 25% of the actual effort in more than 75% of the projects.

4. PROBLEM IN EXISTING METHODS OF ESTIMATION

In Scrum environment the problem is that as a story point is a relative value, the total story point value can fluctuate with a slight variation in the baseline story point. To set the base use story, the agile team finds the simplest user story and determines story points of other user stories based on the baseline. If the baseline story point changes, other story points also have to be changed. Thus, an absolute value like sprint point is needed rather than a relative value of story-point. Based on the critical study of various research discussed above, several problems are there in existing estimation and tracking methods for scrum software developments.

First, in Agile environment, at the initial stage of a project, there is high uncertainty about various project attributes. The estimates produced at early stages are inaccurate, as the accuracy depends highly on the amount of reliable information available to the estimator. Agile estimation methods may lead to the errors in case of inexperienced Agile team. Therefore, there is strong need of analyzing the factors that affect the estimation of theAgile project[15].

         The second problem is Effort Estimation. Estimations are done in units of time while to estimate how much each team member can spend effective time for sprint related work is more important. The fact is that no one can sit at one place to complete the job without attending meetings, lunch breaks, unexpected breaks, checking emails and phone calls etc.

         The third problem is Release Date Estimation. The Release planning is the activity to calculate the actual release date so that the final product is handed over into use for the customer. In Scrum Estimation technique a release plan is made but it doesn’t consider various factors like velocity, cost-benefit ratio etc.

          The fourth problem is that story-points cannot be easily related to the time duration because story points represent the amount of work and the velocity differs from team to team. Thus, sprint-points are needed that can be used to calculate cost and effort.

         In Scrum environment, at the initial stage of a project, there is high uncertainty about various project attributes. The estimates produced at early stages are inaccurate, as the accuracy depends highly on the amount of reliable information available to the estimator. Scrum Estimation methods may lead to the errors in case of inexperienced Agile team. Therefore, there is strong need of analyzing the factors hat affect the estimation of theAgile project.

5. PROPOSED DELAY-RELATED FACTORS

In this project some delay related factors have been proposed that can affect the estimation of cost and effort of the project.These factors are as below:

1.       Complexity

2.       Security

3.       Technical Ability

4.       Expected Ambiguity in Detail

5.       Expected Changes in Environment

6.       Team Members Responsibilities Outside the Project

1. Complexity:-Complexity defines the uncertainty of the project; high complexity means the project is highly uncertain. Complexity can be technical complexity that includes number of technologies involved, another can be complexity related to story points and another can be the management complexity that project staffing, etc. Complexity is a major factor as it increases cost, size and duration of the project.

2. Security:Security is the most important factor and there are many aspects of security. Security can be network security, functional security, code security and documentation security. Security should always be taken as the highest priority factor.

3. Technical Ability: The technical ability means the ability to understand the specific kind of activity, one involving method, techniques, processes, procedures, software, etc. It also means having a good knowledge of specific tools and emerging technologies. If a team consists of technically skilled members, it reduces the learning time and thus reduction in the duration of the project.

4. Team Members Responsibilities outside the Project: Team members have lots of responsibilities outside the project. Shifting between the projects may be done and due to this the duration of the project is affected.

5. Expected Ambiguity in Requirements:Sometimes lack of clarity in the requirements causes the change in duration as well as cost of the project. Requirements are gathered in the beginning of the project and on that basis the task is performed, but if the requirements are not clear no task can be started. This increases the duration of the project.

6. Expected Changes in Requirements: Scrum promotes changing requirements that mean at any point of time in the project new requirements can be added. Due to change in requirement there may be a situation where there will be need for more tools and hence increase in the team member and thus the changing requirements increases the cost and duration of the project.

6.PROPOSED ALGORITHM

 The proposed algorithm explains the various steps involved in estimating a project in Scrum environment.

·         Identify the delay related factors which effect the effort in Scrum environment where

P={ p₁,p₂,....p_i,…….p_n } where 1<i<=n

·         Identify the unadjusted value of Story-points related to each level in Scrum environment

where UVSP = {p₁ + p₂ + p₃ + …..+ p_n }

where L_i (1<=i<=3)

·         Compute the estimated story points(ESP) as

ESP=BSP+0.1(UVSP)

Where BSP is Baseline story Points

·         Compute velocity from first iteration as

Velocity=ESP/story point completed

·         Compute new velocity by considering delay-related factors

V=velocity*d

·         Estimated Development Time (EDT) = ESP/Velocity (in Days)

·         Release Date=Start date + EDT

7. CASE STUDY

In this section the feasibility of our algorithm is shown by a case study in which the prioritization order of user story is calculated. We have considered the user stories of enable quiz which is a technical quizzing solution; for companies that hire engineers and it will allow them to better screen job employees and assess their internal talent for skills development.

                                Table 2: Calculation of I/E

Story	Importance	Hours factor	I/E
1.As a manager, I want to browse my existing quizzes	10	7	10/7=1.42
2.As a manager, I can make sure I’m subscribed to all the necessary topics for my skills audit.	4	3	4/3=1.33
3. As a manager, I can add additional technical topics to my quizzes.	1	16	1/16=0.0625
4.As a manager, I want to create a custom quiz bank	8	8	8/8=1
5. As a manager, I want to create a quiz so I can use it with my staff.	5	4	5/4=1.25
6. As a manager, I want to create a list of students from an Excel file so I can invite them to take the quiz.	7	5	7/5=1.4
7. As a manager, I want to create a list of students online.	6	8	6/8=0.75
8. As a manager, I want to invite a set of students.	3	8	3/8=0.375
9. As a manager, I want to see which students have completed the quiz.	9	6	9/6=1.5
10. As a manager, I want to see how the students scored on the test so I can put in place a skills improvement program.	2	16	2/16=0.125

8. RESULTS

By using Delay-related factors decelerated velocity is calculated on the basis of which effort and cost is calculated. The Delay-related Factors are taken at low level. So Unadjusted value of Story-points is 6 ,On the basis of the project delay done by these factors Velocity Factor  is calculated which is further used in calculations of The effect caused by these factors.

                                  Table 3: Velocity Factor

S.No	Delay-Related Factors	Medium level	VF
1.	Complexity	UVSP=6	0.93
2.	Security	UVSP=6	0.94
3.	Technical Ability	UVSP=6	0.97
4.	Expected Ambiguity in Detail	UVSP=6	0.98
5.	Expected Changes in Environment	UVSP=6	0.96
6.	Team Members Responsibilities Outside the Project	UVSP=6	0.96

·         Unadjusted Value (UV) = All the six factors  at medium level so UVSP=6*6= 36

·         Total User-stories=10

·         BSP=300

·         Project Start Date=1^st Januaury,2014

·         Estimated Story Points (ESP) =BSP+0.1(UVSP) =300+0.1(36)=303.6

·         Initial Velocity = 5 SP / Day

·         AvgVF=Average of VF of all the 6 factors=0.95667

·         Decelerated Velocity (DV) =V*AvgVF=5*0.95667=4.78330 SP/ Day

·         Estimated Development Time (EDT) =ESP/DV=303.6*8/4.78330=507.76 Hours

·         Project End date=14 Jan 2014 

7. IMPLEMENTATION

The case study is implemented in a Agile Management tool in Excel. The snapshots of the results are as in Figure 1, Figure 2 and Figure 3.Figure 1 shows the list of available developers, testers, technical writers, business analyst, test manager, project manager and configuration manager and there available capacity in person days. Figure 2 shows how the release date is calculated using the test management tool.In figure 3 deacelerated velocity is calculated by using the velocity factor.

                   Figure 1: Capacity Management

Figure 2: Release date

                    Figure 3: Velocity Factor

7. CONCLUSION

The purpose of this research work is to develop an algorithm for estimation which can calculate accurate cost, effort and duration of the project. In this paper resistance factors in Agile environment are proposed that impact the estimation of the project. Estimated value of Story points highly depends on the value of these factors. In this project work project delay related factors are proposed that impact the estimation of release date in a project in agile environment. The release date calculation of user-stories highly depends on the value of these factors. In this work the decelerated velocity is calculated on the basis of these factors.The approach developed is really simple and easy to understand and can be effectively used for release date calculation in Agile environment. By this method release date of small and medium size project can be calculated efficiently. In the future the other factors which are important for users can be considered; thereby making correct and efficient estimations of time.

REFERENCES

[1] Beck, K., & Fowler, M. (2000). Planning Extreme Programming.Upper Saddle River, NJ: Addison-Wesley Professional.

[2]S. Bhalereo,Maya Ingle,”Incorporating Vital Factors In Agile Estimation Through Algorithmic Methods”, International Journal of Computer Science and ApplicationsTechnomathematics Research Foundation Vol. 6, No. 1, pp. 85 – 97,2009

[3]Mike Cohn, “Agile Estimating and Planning",Addison-Wesley,2005.

[4] Mike Beedle“Agile Software Development with Scrum”, Ken Schwaber, Prentice Hall, 2001, pp. 100-101

[5] Mike Beedle , Martine Devos ,Yonat Sharon ,Ken Schwaber, Jeff  Sutherland, “SCRUM:  An extension pattern language for hyper productive software development”, 2000.

 [6] P. Abrahamsson, Koskela, J., "Extreme Programming: A Survey of Empirical Data from a Controlled Case Study", Proceedings of International Symposium on Empirical Software Engineering, pp. 73-82, 2004.

[7] L. Layman, L. Williams, and L. Cunningham, "Motivations and Measurements in an Agile Case Study", Proceedings of ACM SIGSOFT Foundation in Software Engineering Workshop Quantitative Techniques for Software Agile Processes (QTE-SWAP), Newport Beach, CA, 2004.

 [8] Jamieson, D., K. Vinsen, G. Callender, “Agile Procurement to Support Agile Software Development, Proceedings of the 35th IEEEInternational Conference on Industrial Informatics,2005.

 [9] L. Williams, W. Krebs, L. Layman, A. Antón, and P. Abrahamsson, "Toward a Framework for Evaluating Extreme Programming", Proceedings of Empirical Assessment in Software Eng. (EASE), Edinburgh, Scot., pp. 11-20, 2004.

[10] F. J. Heemstra, “Software cost estimation”, Information and Software Technology, vol. 34, no.10, pp. 627-639, 1992

 [11] O. Benediktsson, D. Dalcher, and H. Thorbergsson,“Comparison of Software Development Life Cycles: A Multiproject Experiment,” IEEE Proceedings – Software,vol 153, 2006, pp. 87-101.

[12]G. R. Finnie, G. E. Wittig, “AI tools for software development effort estimation”, Software Engineering and Education and Practice Conference, IEEE Computer Society Press, pp. 346-353, 1996.

[13] RashmiPopli, Naresh Chauhan,” Research Challenges of Agile Estimation” Journal of Intelligent Computing and Applications” July-   Dec 2012.

[14] RashmiPopli, Naresh Chauhan,” “Scrum- An Agile Framework”, International Journal of Information Technology and Knowledge Management (IJITKM) ISSN: 0973-4414", Vol-IV, Number-I, 20 Aug 2010.                                           [15] RashmiPopli, Naresh Chauhan,”Sprint Point Based Estimation in Scrum”International Conference on Information Systems and Computer Networks ISCON-2013,at GLA Mathura,March 2013.