Cd25472480
Upcoming SlideShare
Loading in...5
×
 

Cd25472480

on

  • 255 views

IJERA (International journal of Engineering Research and Applications) is International online, ... peer reviewed journal. For more detail or submit your article, please visit www.ijera.com

IJERA (International journal of Engineering Research and Applications) is International online, ... peer reviewed journal. For more detail or submit your article, please visit www.ijera.com

Statistics

Views

Total Views
255
Views on SlideShare
255
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Cd25472480 Cd25472480 Document Transcript

    • Saravana. K.M, G. N. Basavaraj, Rajkumar , Dr. A. Kovalan / International Journal of Engineering Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com Vol. 2, Issue 5, September- October 2012, pp.472-480 Case Study On Agile User Stories Prioritization Using Imaginative Standard Saravana. K.M1, G. N. Basavaraj2, Rajkumar3, Dr. A. Kovalan4 1 Lead Engineer, Global Exchange Service ITC Pvt Ltd, Bangalore, Karnataka, India 2,3 Assistant Professor, Dept. of ISE, Sambhram Institute of Technology, Bangalore, Karnataka, India 4 Assistant Professor, School of CSE, Periyar Maniammai University, Thanjavur, TamilNadu, IndiaAbstract Aim of Agile User Stories Prioritization Requirements that might initially seem secondary toengineering actions are contribute to business customers turn out critical for the operational successvalue that is described in terms of return-on- of the product. Re-implementing the architecture ofinvestment of software product and it is very the software product at the later stage would add upessential for a software. For a product to be to an over-expensive or a delayed project.successful, it is very important to identify the It suggests a conceptual model of the Agile Usercorrect equalizer among the competing quality Stories Prioritization Process from customer‟s scopeUser Stories. From the customers view, the action of vision. We make the note that we furnish a newof continuous User Stories prioritization creates prioritization technique and wethe very core of today’s agile process. In this paper 1. Redefine our view of requirements and theirwe deliver several case studies on Agile User (re)prioritization by addressing them from aStories Prioritization (AUSP) methods to afford a customers‟ scope of vision, andconceptual model for understanding the inter- 2. We suggest a model that reflects this particulariteration prioritization approach in terms of focus and demonstrates unified process toinputs and outcomes, and finds problem and discussing the prioritization attemptsolutions pertinent to Agile User Stories independently from the particular method that isPrioritization. used. These permits the customers to spot concealed issues ahead of time enough in theKeywords: Agile development, requirements project, and assists them make the prioritizationprioritization, Agile User Stories Prioritization decisions.engineering, inter-iteration decision-making process, Essentially, in agile software projects, thevalue based approach, exploratory case study. development process is a value creation process that depends on active customer participation. The1. INTRODUCTION business value creation is checked both through the Continuous requirements prioritization final product as well as through the process itself. Asprocess from the customer‟s scope of vision forms the previous studies show [2], the continuousessential of today‟s agile approaches. An essential prioritization of requirements during the project actsfeature of any agile approach is an expressed focus on as fundamental role in accomplishing business valuemaking business value for the customer [1]. Agile creation. Requirements (re)prioritization at inter-software process practitioners deem this approach iteration time is the means to align expert decisions toespecially valuable for the software producers in a the business strategy that aims the business value.circumstance that admits extremely uncertain Requirements engineering is a decision-centricrequirements, experimentation with fresh process [5], and decision support plays a vital role indevelopment technology, and customers willing to enabling the delivery of business value to customersexplore the ways in which developing product can [6]. Hence, decision support is crucial inassist their business goals. accomplishing value to customers. While exhibiting the project to as low a In this paper, we demonstrate an empiricaldanger as potential. Awesomely, researchers [7, 8] in investigation of this phenomenon by means of anAgile User Story Engineering case studies also exploratory case study. Using a conceptualidentified that the creation of software product value framework for Agile User Stories Prioritization thatthrough requirements prioritization decision making developed earlier [3], we investigated real-worldis only partially realized. These two characteristics of cases in companies. The overall research objectiveAgile User Story Engineering pose at least two was to uncover how mid-course requirementsdisputes: prioritization aims in industry and what beliefs of1. Continuous reprioritization more frequently than business value are included in it. The case study is not leads to project imbalance, and motivated by previously published results [3] from a2. Customers, by and large, relate the concept of systematic literature review on prioritization methods business value to characteristics that meet their in agile projects. This paper is a step towards functional requirements, so non-functional understanding how Agile projects produce business 472 | P a g e
    • Saravana. K.M, G. N. Basavaraj, Rajkumar , Dr. A. Kovalan / International Journal of Engineering Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com Vol. 2, Issue 5, September- October 2012, pp.472-480value to the customers or to the product owners 1. The customer is an integral component of thethrough the requirements prioritization activity. We team and should be on-site with the team.have set out to answer the following research 2. The customer provides user stories and then talksquestions (RQs): about each requirement directly with teamRQ1: Which roles and responsibility are involved in member.the requirement prioritization process decision- 3. The customer is responsible for all businessmaking? decisions including prioritizing user storiesRQ2: How companies are using business value- development.driven decisions in Agile User Story prioritization? 4. The small 2-3 week iterations permit the user toRQ3: Which are the fundamental futures to the acquire their requirements established onrequirement prioritizing process from customers concrete working software.perspective in Agile projects? 5. The customer regularly tests the software toRQ4: What are the main characteristics of the project verify it works as expected.settings for the Software requirements prioritization To illustrate how agile projects continue, weprocess? describe below an example of how Scrum [15, 16]RQ5: What are the other project values adds from the treats requirements prioritization. Scrum is anrequirements prioritization process? We answer it by iterative and agile incremental process modelexpressing out an exploratory multiple case studies. including values, artifacts, roles and meetings. TheThis research constitutes a further step to contribute main roles in Scrum are:to the understanding of Agile User Stories 1. The “Scrum Master”, who assures that the Scrumreprioritization at inter-iteration time. process is used as aimed and who enforces the This paper is structured as follows: section 2 project management practices;motivate this research in more detail and furnish 2. The “Product Owner”, who symbolizes thebackground on related work in the field of Agile stakeholders;value-driven requirements prioritization engineering. 3. The “Team”, a cross-operational group whoSection 3 reviews related work on business value- execute the work activities as the actual analysis,driven requirements prioritization engineering design, implementation, testing.methods, used in Agile software development, Agile approaches explicitly aim to deliverSection 4 presents the results and assesses our business value to the customer early and regularlyanswers to the research questions and discusses across the complete project [17, 12, 14]. In this way,implications for researchers and practitioners, Section the return on investment can be generated much5 summarizes future research directions that we earlier in the development process. A fundamentalidentified based on the case study and concludes the practice of Agile development contributes to thispaper. early business value delivery is the continuous and business value-driven requirements prioritization2. LITERATURE REVIEW from customer‟s view. The project commences with a In this related work subdivision summarizes product backlog which is an initial requirements liston the state of study with regard to the reply to our and is prioritized by business value. It also comprisesfive research questions specified in the introduction. approximate estimations of development effort.To the best of our knowledge, there is no systematic Business value is determined by the Product Ownerempirical research around how requirements and development effort is determine by the Team.prioritization process is really executed in agile Each repetition commences with a sprint backlogprojects. which comprises only those requirements which are Our main objectives for designing a model to be implemented during this sprint. We make sureof Agile User Stories Prioritization from a customer the sprint backlog is frozen and not altered until theview arises from the practices of continuous sprint is complete. This means that (i) reprioritizationrequirements prioritization, with firm customer happens on the sprint planning meeting at theparticipation, are a comparatively recent phenomenon beginning of each sprint only, and (ii) later on thisand accordingly are only partly understood. As the time no re-prioritization happens on the daily ScrumAgile literature [9, 10, 11] suggests, never earlier in meeting. At this meeting, business values driven andthe software engineering history, the customer has development effort of the requirements are re-been that actively and reliably needed in the estimated and the sprint backlog for the next sprint isrequirements prioritization as he/she in Agile designed. At the end of a sprint cycle, two meetingssoftware development. are held: the “Sprint Review Meeting” (where theThe Agile manifesto [13] place the customer‟s role is completed work is presented to the stakeholders) andvery vital in making decisions around “what to build”. the “Sprint Retrospective” (which serves theIn the minimalist philosophy of XP, a prominent agile objective to make continuous process improvements).process, the following is encouraged for the Surprisingly, researchers in Agile User Storiescustomer‟s role [12]: engineering case studies establish that the creation of software product value through requirements 473 | P a g e
    • Saravana. K.M, G. N. Basavaraj, Rajkumar , Dr. A. Kovalan / International Journal of Engineering Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com Vol. 2, Issue 5, September- October 2012, pp.472-480prioritization decision-making is only partly RQ5: What are the other project values adds fromunderstood [7, 8]. the requirements prioritization process? TheRQ1: Which roles and responsibility are involved in introduction of risk management in the developmentthe requirement prioritization process decision- process and improving communication [20] are twomaking? The Agile manifesto [13] holds the of the objectives of Agile and iterative development.collaboration with the customer vital. XP [12], a The primary types of risk which Agile/iterativeprominent agile process, encourages that the development aims to mitigate are change/volatilitycustomer is responsible for all business value and uncertainty [8]. Change means the introduction ofdecisions making, including requirements new requirements or the alteration of existing ones,prioritization. Even though decentralized decision- which can be induced by discovering and by externalmaking involving all team members [2] is a change. Uncertainty can be subordinate to instabilitycontributing principle in agile development, it is the of requirements or lack of technical experience, bothcustomer who builds the final decisions. The of which lead to uncertain budget estimation.customer is represented by a so-called „on-sitecustomer‟. In the decision-making process across 3. REVIEW OF ARP TECHNIQUES ANDrequirements priorities, the development team aims PROCESSthe role of consultant by estimating budget and The analysis was persuaded out using a caseguessing technical risk. study [4] to explore and develop the decision-making process throughout a project in the circumstance ofRQ2: How companies are using business value- agile projects and changing requirements. Clearly,driven decisions in Agile User Story requirements prioritization process is a component ofprioritization? Aurum and Wohlin [18] recommend any project, independently from the developmenta value-based process, which in important across method. One of the greatest assets of an agilecoordinating customers requirements, business approach is that business value is handed over to therequirements and technical prospects when creating customer throughout the project, and the return onrequirements prioritization decisions. For example, a investment is generated much earlier. Thus any alterrecent study by Barney et al. [7] investigated the in the requirements can be taken into considerationrelease planning process to make software product and implemented into the product at an early stage.value through requirements selection. These authors This highlights the paramount importance of thediscovered the elements that decide the decisions requirements prioritization, activities.across inclusion of certain requirements for The alter in the backlog with requirementsimplementation. They are the customer and market for iteration may happen for different concludes –base of the software product, along with circumstance new market or company realities or better knowledgefactors such as maturity of the product, the about the business value certain features deliver. Thismarketplace in which it survives, and the involves an active prioritization process as well. Thisdevelopment tools and methods available. perspective is confirmed by Harris and Cohn [14], who apply tactics to reduce the budgets and increaseRQ3: Which are the key futures to the the profits through strategic learning and furnish roadrequirement prioritizing process from customers map on how to optimize business value. Theyview in agile projects? To answer it, we apply a demonstrate the essential of espousing an activegrounded-theory-based research method [19]. approach to Agile User Stories Prioritization, in order to take into consideration the essential prospect ofRQ4: What are the main characteristics of the learning in an agile project. Their focus is especiallyproject settings for the Software requirements on integrating learning and budgets of change in theprioritization process? The background across agile decision-making process.development talks about two characteristics of theproduct circumstance which determine decision- 3.1. The case study process and participantsmaking: change and project constraints. Alteration is We performed an investigative case study byexplicitly required and welcomed by Agile performing the following steps:development methods (“embrace change” [12]), or 1. Comprise a survey,vice versa, Agile approaches are selected in 2. Confirm the survey over an knowledgeablecircumstances where alteration are high [20, 8] as researcher,they assist to manage with this position and enforce 3. Implement alterations in the survey establishedschemes which cut down the budgets of alter [2]. on the advice,Project constraints like the determined limited 4. Do a pilot conference to check the applicabilityresources and time pressure are distinctive for Agile of the survey to realistic perspective,and non-Agile projects. In more prominent projects 5. Carry out semi-structured conferences withhowever, prioritization must be done on a higher specialists affording to the confirmed survey,abstraction level [20] than in small projects. 474 | P a g e
    • Saravana. K.M, G. N. Basavaraj, Rajkumar , Dr. A. Kovalan / International Journal of Engineering Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com Vol. 2, Issue 5, September- October 2012, pp.472-4806. Illustration (continuation with those contributors We deliberate 8 companies and discussed the total of that keep deeper awareness or additional specific 10 projects, with 10 customer organizations. perception). Every examinee was provided beforehand 3.2. The data analysiswith evidence on the research determination, the In this revision, the statistics used andresearch course and the privileges and duties of the continuously associated to the evolving model iscontributing case study companies. At the conference, literature on Agile User Stories Prioritization existingthe researcher and the examinee walked over the via scientific digital libraries and prominent agilesurvey which assisted to leader the interviews. The experts‟ journals. We did a semi-systematic literaturesurvey was self-possessed of three parts: the first part search using the five bibliographic databases:deliberated the prioritization process repetition that IEEExplore, ACM Digital Library, Google Scholar,each interviewee experienced in one concrete project. InterScience and Citeseer. We accompanied themThe second part comprehensive familiarity of the with the following journals: the Agile Journal [9], andinterviewees with esteem to Agile User Story the stands, committed to software development andPrioritization Process across many projects, and the Agile approaches: DrDobb‟s [21] and InfoQ [20].third part involved queries associated to the business The significant arguments we used for our searchvalue insight and value creation, as crucial part of the were: Agile, requirements, backlog, prioritization,prioritization decisions. The motivation behind this inter-iteration, decision-making, business value, risk,structure was to focus the attention of the contributors cost, features. We sketched the orientations in theon a concrete example and then make a conversion to recognized papers to get access to other pertinentgeneral observations drawn from participation in sources.other agile projects. The third part intended to Our evaluation uses the below technique tosimplify the concerns of business value as a part of deliver our case study. Below we emphasized each ofthe prioritization decision-making process. We create them in terms of its core headings and context of usetwo notes: 1. Planning Poker[36]1. No extensive alterations in both the questionnaire 2. Ranking based on product definition [24] and case study protocol took place after the pilot 3. Planning Game[12] interview, so that the pilot interview could be 4. Quality functional deployment QFD [23, 26] considered part of the case study. 5. Wiegers‟ matrix approach. Karl E. Wiegers [32]2. During the interviews there were cases when 6. Mathematical programming techniques [28] other queries arose next to those involved in the 7. MoSCoW [25] questionnaire. These queries were not previously 8. Pair-wise analysis [26] projected; however the researcher piloting the 9. Weighted criteria analysis [26] study considered them interesting and pursued 10. Analytic Hierarchy Process (AHP [30] the interview in that direction. 11. Dot voting [26] The application domains for which these 12. Binary Search Tree (BST) [22]experts developed software resolutions represent a 13. $100 allocation (cumulative voting) [27]rich mix of arenas comprising banking, health care 14. Multi-voting system [31]management, automotive industry, content 15. Ping Pong Balls [16]management, online municipality services, and ERP 16. Round-the-group prioritization [11]for small businesses. In each organization we In addition to the above practices, ourinterviewed one or more councils that were directly literature review exposed one practice, which cannotinvolved in the decision-making and the development be preserved as distinct method or technique, as itprocess. Many of the contributors accomplished might be applied in combination with any othernumerous roles in the team and thus had a technique - the practice of bucketing requirementscomprehensive experience to the entire process. The [29]. This mean‟s “bucketing” groups of maininformation about the contributing companies and functionality or areas of task support are occasionallyprofessionals is concise below: easier than feature by feature prioritization. The1. Middle-sized one company in the India (2 cases, above techniques we‟ve recognized can be considered 3 contestants) in two main clusters:2. Small-sized two companies in the USA (3 cases, 1. Techniques, straight associating requirements 3 contestants) pairwise3. Small-sized one company in China (1 contestant) 2. Techniques that group requirements dependent4. Middle-sized one company in Australia (1 on their significance. contestant)5. University one (1 scholar project) 4. CASE STUDY CONSEQUENCES6. Big-sized one consultancy in US (1 contestant) At the commencement of repetition business7. One IT department in a big governmental value of every story has to be predictable (calculated). organization in India (1 contestant) The challenge is to make the awareness or evidence, used by the specialists to execute the predictable, 475 | P a g e
    • Saravana. K.M, G. N. Basavaraj, Rajkumar , Dr. A. Kovalan / International Journal of Engineering Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com Vol. 2, Issue 5, September- October 2012, pp.472-480clear. The foundations of such evidence need to be requirements volatility will involve refactoring orrecognized, as well as the principles that describe one rework, and the estimations for theserequirement as additional treasured than another. In accomplishments have to be engaged intoorder to create the decision-makers responsive of the deliberation when scheming the business value.forces, essential the value of a story, we recommend These accomplishments are secreted for the customer,that the succeeding extra constraints to be involved to as they are not obviously involved in the project‟sthe story: backlog or work breakdown structure; they don‟t1. Points among siblings - involved by the customer deliver functionality and, correspondingly, don‟t based the hierarchy with stories (e.g. WBS) and produce business value. Estimation is executed on proficient understanding. These influences to vigorously every period prioritization occurs. This comprise marketing or other domain specialist. innovative suggestion addresses the opinion prepared2. Dependencies - utmost of the approaches defined by other authors [2] that in Agile situation the above typically do not yield into story execution instruction is founded mostly on the dependencies among requirements. Those business value. We need recognize nevertheless, that approaches which do recognize for dependencies at this point of period, we do not have any empirical are the ones which define requirements on data which recommends an exact formula of the numerous ranks of granularity. association among the preliminary business value and3. Confidence parameter - the confidence around budget, and the business value at succeeding the essential to implement the story at the repetitions. existing instant - this is a utility of the story‟s Determining on a prioritization practice in value and volatility, and replicates the level of Agile projects will be contingent on the project‟s evidence the customer has around the value of situation, the preceding skill and understanding of the the essential functionality and the possibility that project. We can deliberate at least the succeeding the story is affected by alteration in the principles when selecting a prioritization method: environment. This influence force is a percentage 1. Quantity of objects to be prioritized, or a number on a scale. Thus we address Harris 2. Quantity of stakeholders involved, and Cohn‟s [14] suggestion to submit stories 3. Level of requirements instability, with extraordinary predictable budget of 4. Foundations of evidence accessible. alteration - the ones that are extra probable to be A study by Karlson et al [33] establishes that altered can be delayed until extra and enhanced the two specific approaches, associated created on understanding around how (or even whether) to „ease-to-use‟ and „time consumption‟ of the practice, improve them is expanded and responses do not diverge the considerably concerning accuracy. knowledge also touches with the responses Describing the possibility of subsequent repetition recommended by G. Ruhe et all [35]. will depend on estimated existing value of the Particular user stories do not generate requirements, and the quantity of effort that thebusiness value straight but they are precondition for developer is able to execute in repetition (for exampleother stories as we recognized two potential solutions measured in story points).to conduct the dependencies: We progressed on real world case study in Software1. Deliberate such user stories as married to the Company in demand to answer our research questions story that generates (max) business value, or to (RQs) to assess the success factor of the product as wrap these stories as a bundle - from external is surveys. only one story noticeable, that is, separation is not thinkable. RQ1: Which roles and responsibility are involved2. Familiarize story points inside the stories of a in the requirement prioritization process decision- feature. This would mean that stories with larger making? points will have to be implemented beforehand In our case study the developer plays a the others, nevertheless of their business value. greatly extra significant role in practice than what is The excellence attributes cannot be detached suggested in the literature. Overall, the specialistsfrom other stories and to deliberate them as functional granted that the developers and testers are activerequirement, where the key principles are the contestants in the requirements decision-makingconfidence parameter. For example, if the customer processes, even nevertheless the customer hadrecognizes for sure, that the system will have significant earlier knowledge in softwarenumerous thousands users, the scalability will be development projects. We detected the subsequentaddressed at earlier phase. circumstances: The business value of a requirement is 1. The decisions were delegated fully to thediverse at diverse points in period. That is, it differs developers and testers.throughout the project, as fresh evidence strength 2. The customers required alterations or quickerattains, alterations in the market condition strength execution of certain functionality, withouthappen, thus touching the understanding the team has contributing in other prioritization actions.around the value of a story. Moreover, the 476 | P a g e
    • Saravana. K.M, G. N. Basavaraj, Rajkumar , Dr. A. Kovalan / International Journal of Engineering Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com Vol. 2, Issue 5, September- October 2012, pp.472-4803. The customers contributed during the project in a Agile and traditional requirements engineering traditional way, e.g. by appreciative alterations to processes may not be that different regarding that budget. prioritizes the requirements. The customer‟s judgment of significance concerning a specific requirement might not continuously be representative for the customer‟s organization as a comprehensive. The customer consciously or unconsciously influences the developers to implement specific requirements. The developer has no opportunity to accumulate extra objective evidence about the condition and to justice the extent to which s/he could belief the customer‟s intelligence of priorities. One contestant described her/him knowledge in a case of a customer who asked for a certain report. According to the customer, this reportFig. 1. Role and Responsibility involved in the was „very important‟. It acquired significant effortsrequirement prioritization on the developers‟ side to make it. Later it turned out, that this customer‟s demonstrative was the only We observed that the contribution of the person in the complete company analysis this report.developers in the decision-making processes isstronger in minor projects as shown Fig. 1, where the RQ2: How companies are using business value-customer is a minor organization or company. First, driven decisions in Agile User Storysuch customers don‟t own knowledge in the IT prioritization?domain and can‟t have enough money compensating The business value-creation process playsextra for IT consulting services. They may even significant role for the developers‟ organization, notdiscovery it very expensive to assign a resource to the only for the customer‟s company. The Agilerole of „on-site customer‟. In such a situation, it specialist‟s literature [3, 7] appears to share theoccurs that the customer representatives the decisions judgment that the only value-creating deliberationsinfluencing the value creation, to the developing team. that determination the development decisions areIn one of the projects that we investigated the those of creating value for the customer. During thisdevelopers acquired over the decision-making since study we prepared the dependable surveillance that,the customer didn‟t own the time and capabilities to more often than not, the value creation for thesystematically motive around the system him/her developers has been measured as well. We note thatdesirable. This makes us consider that there are the theme of the accepting about business value anddefinite patterns of appropriate influences that will the RQ2 are deliberated in superior factor in [31].always lead to delegating the decisions to thedeveloping organization. The developers own RQ3: Which are the key futures to theknowledge both in development and in the particular requirement prioritizing process from customerssubject area, as teams are focused in developing a perspective in agile projects?specific class of applications (e.g. banking, health- Our model is established on distributedcare, ERP, etc.). In the involvement of our descriptions of Agile User Stories Prioritizationinterviewees “this indications to high customer techniques and of case studies as show Fig. 2. Wefulfillment and virtuous association with the customer, executed a research process which included thewho will, ultimately, lead to prospect mutual following steps:projects”. One project manager described: 1. Identification and analysis of data sources from“Customer‟s relations are important; we need to make available literature,them happy but we don‟t just do whatsoever they ask 2. Initial and focused coding of the thoughts thatfor. Instead, we try to recognize what their problems play a role in Agile User Stories Prioritization,are, and their field, so that developer can better assist 3. Clustering of those perceptions,their wants”. In this view, the developers‟ company is 4. Conceptual modeling, andthe one to make assured that the project delivery 5. Theoretical sampling of empirical data, using theprocess runs in a way that is cost-effective for the thoughts from our subsequent conceptual model.company. If developers accommodate all desires The objective of steps 1-3 is the innovationwhich customers influence come up with at inter- of as numerous applicable categories as possible,iteration time, the company may discovery it not including their possessions. Step 4 is around themaintainable in the extended run. This surveillance pictorial demonstration of the categories and theirincreases the query about value deliberations for the relationships, and Step 5 is about „saturating thedevelopers, deliberated in detail [31]. The matter that categories‟. Categories are measured „saturated‟ whendevelopers powerfully contribute in the prioritization gathering new data no longer brings new theoreticaland decision-making gives us the suggestion that 477 | P a g e
    • Saravana. K.M, G. N. Basavaraj, Rajkumar , Dr. A. Kovalan / International Journal of Engineering Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com Vol. 2, Issue 5, September- October 2012, pp.472-480understandings nor discloses new belongings of the The use of the prioritization in agile situation is notcategories in the conceptual model. narrow to choosing the utmost important/valuable requirements for the forthcoming iteration. Our study exposed two other features that are very significant for the project‟s consequence, building the right product and incorporating new information and learning on-the-fly. Our contestants designated that in a situation of volatile or ambiguously defined requirements, the prioritization process confirms value by the change management mechanisms and by integrating learning loops in the process. 5. FUTURE WORK Further in detail, our reflection on the gapFig. 2. Requirement prioritizing from customersperspective. carried us to the succeeding research questions for the future: 1. What thoughtful of developer‟s expectations doRQ4: What are the main characteristics of the Agile customers essential to be mindful of andproject settings for the Software requirements what thoughtful of customers‟ expectations doprioritization process? The requirements prioritization processes developers essential to be responsive of, in orderdiffer concerning the procedures of customers´ to improve the value-creation process? 2. How to arrange the prioritization approaches tocontribution and collaboration in the process and two reproduce the certainty we detected?circumstance factors are size of the customer‟sorganization, and size of the project in relations of 3. In which project situations are we probable to detect that the expectations are not accurate? Toresources (budget and time). In terms of size of the recognize and enhanced understand those cases.customer‟s organization are categories as follows:1. Magnitude of customers‟ organization was minor We studied current Agile User Stories Prioritization and process particulars as the customer can‟t techniques and prepared a first effort to derive a assign resources for contribution and in the model for inter-iteration prioritization decision- maximum cases does not own the knowledge making from the viewpoint of the customer. We used this conceptual model to assembly concerns and desirable. solutions relevant to Agile User Stories Prioritization2. Magnitude of customers‟ organization was of requirements. intermediate and process particulars as Customer‟s collaboration is limited, don‟t assign resources, don‟t agree to customer on site or even 6. CONCLUSIONS to developer on site. The behavior changes only This paper recognizes and investigates the after little repetition where they see the welfares study discovered an essential gap concerning the of the agile methodology. realities of the specialists and the expectations3. Magnitude of customers‟ organization was Big prepared in Agile User Stories Prioritization Customer and process particulars as the engineering literature. We can conclude from our relationship develops more strictly defined; case study the succeeding points: alterations need contribution of higher-level 1. While an Agile software company agreements management. customers prioritize requirements, theIn terms of size of the project and size of resources requirements decision-making process can yield(budget and time) are categories as follows: only when the customer‟s interest to create1. Project resources was very limited resources in a alterations along the way is in stability with the small project and process particulars as essential developer‟s attention for a supportable business minimum of functionality is absolutely vital by 2. The existence of objective values to feed as input the end of the project. Prioritization helps to into the prioritization approaches is questionable; choose those requirements that are critical for instead, what is priority appears to be a supporting the key objective of the customer. combination of subjective value-based criteria.2. Project resources was bigger project where 3. The prioritization process instantiation differs additional resources can be deliberated and around projects at different customer companies Process particulars as the prioritization helps to and those differences appear to be related to choose the highest value requirements for the project characteristics such as size of project and next iteration. size of customers organization.RQ5: What are the other project values adds fromthe requirements prioritization process? 478 | P a g e
    • Saravana. K.M, G. N. Basavaraj, Rajkumar , Dr. A. Kovalan / International Journal of Engineering Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com Vol. 2, Issue 5, September- October 2012, pp.472-480REFERENCES Tools for Large-Scale Scrum, Addison- [1] P. Abrahamsson, O. Salo,O., J. Ronkainen, Wesley, 2008. J.Warsta: “Agile Software Development [16] Schwaber, K., Agile Project Management Methods: Review and Analysis”, VTT with SCRUM, Microsoft Press, 2004. Technical Report, 2002. [17] S.W Ambler, Agile Modeling - Effective [2] L. Cao, B. Ramesh, "Agile Requirements Practices for eXtreme Programming and the Engineering Practices: An Empirical Study," Unified Process. Wiley, New York, 2002. IEEE SOFTWARE, Vol. 25, 01, pp. 60-67, [18] A. Aurum, C. Wohlin, “A Value-Based JANUARY/FEBRUARY. Approach in Requirements Engineering: [3] Z. Racheva., M. Daneva, A. Herrmann, R. Explaining Some of the Fundamental Wieringa, “A conceptual model and process Concepts”, In Proceedings. of REFSQ, 2007, for customer-driven Agile Requirements pp. 109-115, Prioritization”, in the Proc. f 4th URL:http://www.wohlin.eu/Articles/IST03.p International Conference on Research df. challenges in Information Science, Nice, [19] Charmaz, K. Constructing Grounded France, May 2010, IEEE. Theory: a Practical Guide through [4] R.K. Yin, Case Study Research: Design and Qualitative Research, Thousand Oaks CA, Methods (1984). Sage, 2007. [5] A. Aurum and C. Wohlin, “The fundamental [20] InfoQ software development community Nature of Requirements Engineering http://www.infoq.com/Agile. Activities as a Decision-Making Process,” [21] Dr Dobb‟s portal http://www.ddj.com/ Information and Software Technology, vol. [22] Ahl, V. "An Experimental Comparison of 45, Nov. 2003, pp. 945- Five Prioritization Methods." Masters 954,doi:10.1016/S0950-5849(03)00096-X. Thesis, School of Engineering, Blekinge [6] A. Ngo-The and G. Ruhe, “Decision Institute of Technology, Ronneby, Sweden, support in requirements engineering,” in 2005. Engineering and Managing Software [23] Crow, K.,: “Customer-focused Development Requirements. A. Aurum and C. Wohlin, with QFD”, URL: http://www.npd- Eds. Berlin, Springer Verlag, pp. 267-286, solutions.com/qfd.html 2005. [24] Fraser, J., Setting Priorities, April 23, 2002, [7] Barney S., Aurum A., C. Wohlin, A Product URL:http://www.adaptivepath.com/ideas/ess Management Challende: Creating Software ays/archives/000018.php. Product Value through Requirements [25] Getting Started With Use Case Modeling, Selection, Journal of Software Architecture, An Oracle White Paper, May 2007 54 (2008), pp. 576-593. http://www.oracle.com/technology/products/ [8] K. Petersen and C. Wohlin, “A Comparison jdev/collateral/papers/10g/gswUseCaseMod of Issues and Advantages in Agile and eling.pdf. Incremental development between State of [26] Gottesdiener, E., At a Glance: Other the Art and an Industrial Case,” J. of Prioritization Methods, EBG Consulting, Inc. Systems and Software, vol. 82, 2009, pp. www.ebgconsulting.com. 1479-1490. [27] Leffingwell, D., Widrig, D., Managing [9] Agile Journal http://www.Agilejournal.com/ Software Requirements: A Use Case [10] Augustine, S., Managing Agile Projects, Approach, 2nd ed. Boston, MA: Addison- Prentice-Hall, 2005. Wesley, 2003. [11] Berteig, M., Methods of Prioritization, [28] Li, C., Akker, J.M. van den, Brinkkemper, S. March 20, 2006 in Agile Advice Online & Diepen, G. (2007). Intergrated Practitioners Forum, requirement Selection and Scheduling for http://www.Agileadvice.com/archives/2006/ the Release Planning of a Software Product. 03/methods_of_prio.html. In Requirements Engineering: Foundations [12] Beck, K. eXtreme Programming Explained: of Software Quality (REFSQ 07) (pp.93- Embrace Change, Addison Wesley, 2000. 108). Springer-Verlag Berlin Heidelberg. [13] Agile Manifesto, http://Agilemanifesto.org/ [29] Patton, J., Finding the forest in the trees, (last access: 10 Feb 2010). Conference on Object Oriented [14] R.S. Harris and M. Cohn, “Incorporating Programming Systems Languages and Learning and Expected Cost of Change in Applications, 2005, San Diego, CA, USA, Prioritizing Features on Agile Projects,” pp: 266 – 274, ISBN:1-59593-193-7. Proc. XP 2006,pp. 175-180. [30] Saaty, T.L., The Analytic Hierarchy Process, [15] Larman, Scaling Lean & Agile McGraw-Hill, New York, 1980. Development: Thinking and Organizational [31] Tabaka, J., Collaboration Explained: Facilitation Skills for Software Project 479 | P a g e
    • Saravana. K.M, G. N. Basavaraj, Rajkumar , Dr. A. Kovalan / International Journal of Engineering Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com Vol. 2, Issue 5, September- October 2012, pp.472-480 Leaders. Addison Wesley 2006. ISBN-13 M.Tech Degree in Computer Science & 978-0321268778. Engineering from Bapuji Institute of Technology [32] Wiegers, K., "First Things First: Prioritizing Davangere, Visveswaraiah Technological Requirements," Software Development, vol. University Belgaum. Presently he is serving as 7, no. 9, Sept. Assistant Professor in the department of 1999;www.processimpact.com/pubs.shtml#r Information Science and Engineering at equirements. Sambhram Institute Of Technology, Bangalore. [33] Karlsson, L., Thelin, T., Regnell. B., His areas of interest are wireless communication, Berander, P., Wohlin, C., Pair-wise sensor networks. (basavarajgn@gmail.com) comparisons versus planning game partitioning--experiments on requirements Rajkumar is native of prioritisation techniques, empirical Software Bidar, Karnataka, India. He Engineering, Volume 12 Issue 1, 2007. received his B.E Degree in [34] Racheva, Z.,M. Daneva, L. Buglione, Computer Science and Complementing Measurements and Real Engineering from VEC, Options Concepts to Support Interiteration Bellary, Gulbarga Decision-Making in Agile Projects, to University Gulbarga and appear in the Proceedings of the M.Tech in Computer Euromicro08 conference, Sept.2008 Parma, Engineering from SJCE Italy. Mysore, Visvesvaraya Technological University [35] Ruhe, G., J. McElroy, G. Du, A Family of Belgaum. Presently he is serving as Assistant Empirical Studies to Compare informal and Professor in the department of Information Optimization-based Planning of Software Science and Engineering at Sambhram Institute Releases, Proceedings of the 2006 Of Technology, Bangalore. His areas of interest ACM/IEEE international symposium on are wireless communication, sensor networks. Empirical software engineering, Riode (pyage2005@gmail.com) Janeiro, Brazil, pp: 212 – 221, ISBN:1- 59593-218-6. Kovalan received his B.Sc. [36] S. BHALERAO, S. BHALERAO, degree in Computer Science International Journal of Computer Science from Bharathidasan and Applications, 2009 Techno mathematics University, Tiruchirappalli, Research Foundation Vol. 6, No. 1, pp. 85 - India, in 1995, the M.C.A. 97 degree in Computer Applications fromAuthor Profile. Bharathidasan University, Saravana K.M received his Tiruchirappalli, India, in 1998, and the Ph.D. B.E. degree in Computer degree in Educational Technology from Science and Engineering from Bharathiar University, Coimbatore, India in 2007. Visveswaraiah Technological He was a Software Engineer during 1998 – 2001. University, Belgaum, India, Now, he is a an Assistant Professor, Department M.Tech degree in Computer of Computer Science and Applications, and Deputy Director in CSAS (Center for Students‟ Science and Engineering from Administrative and Services), Periyar Visveswaraiah Technological Maniammai University, Vallam, Thanjavur, University, Belgaum, India, and Pursing Ph.D. India. His research interests include e-Learning, degree in Computer Science and Engineering Ontology, VLE, and Online Learning. from Periyar Maniammai University, India. He is Lead Engineer in the reputed organization Global Exchange Service ITC Pvt Ltd, Bangalore. His research interests include Software Engineering, Network Security (mailtosaravan@gmail.com). Basavaraj G. N is native of Davangere, Karnataka, India. He received his B.E Degree in Computer Science and Engineering from Kalpataru Institute of Technology Tumkur, Bangalore University and 480 | P a g e