INTRODUCTION TO USER STORIES

BY PANKAJ KAMTHAN

1. INTRODUCTION
It is more helpful [...] to recognize that the solution is located in the computer and its software, and the problem is in the world outside. [...] The computers can provide solutions to these problems because they are connected to the world outside. [...] To study and analyse a problem you must focus on studying and analysing the problem world in some depth, and in your investigations you must be willing to travel some distance away from the computer.

Michael A. Jackson In this document, the notion of user story is explored. 2. THE DYNAMIC NATURE OF SOFTWARE ECOSYSTEM

It is not the strongest of the species that survives, nor the most intelligent, but the one most responsive to change.

Not Charles Darwin1 The development of every software system takes place in an ecosystem [Brooks, 1987; Messerschmitt, Szyperski, 2003]. This ecosystem consists of a number of elements. The elements, properties of these elements, and the relationships between these elements, are prone to change over time, as they have over the years. For example, general public, information appliances (devices) with access to the Internet, domains such as electronic commerce, small-and-medium sized software enterprises, and geographically distributed teams, are elements that are present today, but were not part of the ecosystem of software developed in the 1960s or the 1970s.

URL: http://www.darwinproject.ac.uk/six-things-darwin-never-said .

The variabilities in this ecosystem must be, as appropriate, reflected throughout software development, including in the approaches for developing software systems. In particular, the methodologies for software development must evolve and adapt over time. The changes in vision at a higher level often manifest themselves in changes at a lower level. In particular, changes in methodologies for software development leads to changes in process workflows, especially in practices and approaches to those practices. The beginning of something 3. THE INCEPTION OF AGILE METHODOLOGIES AND USER STORIES

The Agile Manifesto2, in general, and the inception of agile methodologies for software development [Highsmith, 2002; ISO/IEC/IEEE, 2012], in particular, is a response and result of a number of changes in software ecosystem in the past decade or so. In this document, an agile project [Highsmith, 2009] is a software project based on the values and principles of the Agile Manifesto. The rest of the terminology can be derived similarly. For example, an agile requirement is a requirement pertaining to a software system based on an agile project. In certain agile methodologies, agile requirements are, indeed, user stories. 4. DEFINITION OF REQUIREMENT Definition [Statement]. A declarative sentence that is either true or false. For example, a question is not a statement. A sentence is a grammatical entity, whereas a statement is a logical entity. There are a number of definitions of requirement, including the following.

URL: http://agilemanifesto.org/ .

DEFINITION 1 Definition [Requirement] [IEEE, 1990]. (1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2). DEFINITION 2 Definition [Requirement] [ISO/IEC/IEEE, 2012]. [A] statement which translates or expresses a need and its associated constraints and conditions. 5. DEFINITION OF USER REQUIREMENT There are a number of definitions of user requirement, including the following. Definition [User Requirement] [ISO/IEC, 2010]. [A requirement that provides] the basis for design and evaluation of interactive [software] systems to meet identified user needs. From a software engineering perspective, user requirements comprise both functional and non-functional requirements based on user needs and capabilities [ISO/IEC, 2010]. There are requirements for (both non-software-intensive and) software systems that are not necessarily related to a user [Maiden, 2008]. In other words, the set of user requirements for a software system is a (proper) subset of software requirements of that system. This is illustrated in Figure 1.

Figure 1. The set of user requirements is a (proper) subset of software requirements. For example, software requirements beyond the scope of user requirements include the following: legal requirements (imposed by a government or other similar bodies), standard requirements (by virtue of commitment to the organization, or by virtue of adoption, say, at a national or international level), system requirements (related to, say, hardware/network), and so on. 6. DEFINITION OF USER STORY
To be a person is to have a story to tell.

Isak Dinesen There are a number of definitions of a user story [Cohn, 2004; ISO/IEC/IEEE, 2012; Leffingwell, 2011], including the following3. DEFINITION 1 Definition [User Story]. A high-level requirement [statement] that contains minimally sufficient information to produce a reasonable estimate of the effort to implement it. DEFINITION 2 Definition [User Story] [ISO/IEC/IEEE, 2012]. [A] simple narrative illustrating the user goals that a software function will satisfy. This definition does not highlight aspects of a user story that are unique as compared to other forms of expressing user requirements.

URL: http://www.agilemodeling.com/artifacts/userStory.htm .

REMARKS A user story reflects a particular style of expressing a user requirement for a software system. A user story reflects a shift in the direction of expressing a subset of software requirements. The shift is from introspection to extrospection. The shift is from a technical (machine) viewpoint to an anthropological (human) viewpoint. 7. THE ADVANTAGES OF USER STORIES The advantages of user stories over other approaches include the following aspects: Communication, Comprehension, Collaboration, Calculation, Connection, and Conciliation. COMMUNICATION The user stories, by elicitation of information from customers/users, emphasize verbal communication. This can lead to an improvement in the relationship between software engineers and customers/users [Alexander, Maiden, 2004, Page 268] from conversing and listening to each other that, in turn, could eventually contribute to building necessary mutual trust [Bang, 2007; Kovitz, 2003]. COMPREHENSION The user stories, from the absence of technical terminology in their statements, aim to be comprehensible to non-technical stakeholders. COLLABORATION The user stories encourage collaborative effort in human-centered approaches to the development of interactive software systems [ISO, 1999; ISO, 2010] such as participatory design [Schuler, Namioka, 1993] and user-centered agile process [Beyer, 2010, Chapter 5].

This is done by engaging customers/users as integral participants in the software process. CALCULATION The user stories can be used for estimating the progress of the team during a software project [Cohn, 2005]. The use of early software artifacts for estimation is considered useful. CONNECTION The user stories are aligned with the following values of the Agile Manifesto4: Individuals and interactions over processes and tools, Customer collaboration over contract negotiation, and Responding to change over following a plan. CONCILIATION It is evident that the disciplines of software engineering and human-computer interaction have essentially evolved independently from each other until the last couple of decades or so. (For example, an examination of the literature on patterns reveals such a division.) In spite of the fact that these disciplines have certain common goals and need each other, over the years they have conflicted, and there has been a lack of mutual support [Jokela, Abrahamsson, 2004]. This compartmentalization has not been fruitful, and indeed could have been harmful. In recent years, especially since the increasing acceptance of agile methodologies, it has been realized5 that a convergence and cooperation between the two disciplines is necessary, even mutually beneficial. To do that, there is a need for a concrete common ground. Indeed, if expressed appropriately [Beyer, 2010; Layon, 2012], user stories can act as bridge towards reducing the classical chasm between software engineering and human-computer interaction, as highlighted in Figure 2. For example, a user story could be explicitly related to a user model to underscore that the role of a user in the user story is firstclass.

4 5

URL: http://agilemanifesto.org/ . URL: http://www.delicious.com/adrianh/agile+ux ; http://www.agileproductdesign.com/ .

Figure 2. The user story bridge is relevant to the development of interactive software systems. 8. USER STORIES AND SOFTWARE SYSTEM: THE CAKE METAPHOR There are a number of possible views of a software system. If a (layered) cake represents the software system, then a (vertical) slice of that cake represents the implementation of a user story [Wake, 2002]. (The slice needs to be vertical so that the user story provides a complete functionality.) This is illustrated in Figure 3.

Figure 3. A view of a software system as a collection of implementations of user stories.

9. ORGANIZATION OF USER STORIES Definition [User Story Book]. The collection of user stories for a (single) software system. 10. A USER STORY PROCESS MODEL If the development of user stories is to be effective, it needs to be carried out systematically. For that, a User Story Process Model (USPM) [Kamthan, Shahmir, 2010] can be adopted and followed. There are a number of steps in USPM, and a number of activities in each of those steps. The following are mandatory steps of USPM: Step 1: Planning, Step 2: Meeting, Step 3: Authoring, and Step 4: Reviewing. The following are optional steps of USPM: Step 5: Publishing. There are a number of inputs to each step of USPM. The output of USPM is a set of user stories for the current iteration. USPM is interspersed, iterative, and incremental. Figure 4 summarizes the USPM.

Figure 4. The steps in a model for a user story process.

In order to obtain a user story book, the steps 1-4 need to be repeated. 11. DISSEMINATION OF USER STORIES Definition [User Story Card]. An index card on which the description of a user story is presented. An electronic user story card attempts to mimic a paper-based user story card shown in Figure 5. There are advantages and disadvantages of paper-based user story card, as well as that of electronic user story card.

Figure 5. A paper-based index card for use as a user story card. 12. USER STORY DESCRIPTION There is a need for humans and machines to communicate and use a user story. To do that, a user story must be described adequately. The description of a user story consists of metainformation and information. The typical candidate elements of metainformation include the following: Identifier Name Theme Date Author Version

The user story cards can be stored in a number of ways including a version control system (VCS), a user story management system (USMS), or a Wiki system. In these cases, the inclusion of certain metainformation may not be necessary.

The typical candidate elements of information include the following: Statement Constraint Note Priority Estimate Acceptance Criteria

There are certain elements that can be further decomposed and structured. For example, one such element is the statement. The occurrence of an element in a user story description can vary. In a user story description, some elements are mandatory, while others elements are optional. In general, a user story description must have an identifier, name, statement, priority, estimate, and acceptance criteria. The order in which the elements are listed is not significant, but a logical order of reading should be preserved. IDENTIFIER This entry includes an identifier for use (say, tracking) by both humans and machines. The identifier must be unique, at least across a user story book. The identifier usually is a number or an alphanumeric string. For example, PMS-US007 is an alphanumeric identifier. NAME This entry includes a name (or title) that acts as shorthand to the user story statement. The user story statements can, in certain cases, be rather lengthy for stakeholders to remember for the purpose of communication, or rather long to be readily placed on sticky notes for the purpose of organization. Furthermore, in an electronic environment, a user story may be navigated or searched using its name. Therefore, a name must be meaningful, evocative, pronounceable, weavable, and findable.

10

The names of user stories may need to be interwoven with text. For example, a name may appear in another software artifact. In order to distinguish a user story name from surrounding text, some orthographic convention could be followed. For example, a user story name could be presented in uppercase. Remark. If a use case model has been constructed, then the name of a use case can serve as a user story name. THEME This entry includes the theme corresponding to the user story. There can be different types user stories in a given user story book. These user stories could be categorized topically and organized textually using themes6. A theme aids understanding and can be useful for allocation of work. The themes could be derived from the affinity diagram of the interviews conducted as part of a realization of USPM (Step2: Meeting). This is illustrated in Figure 6.

Figure 6. The organization of a sample collection of user stories into themes. STATEMENT This entry includes the user story statement.
6

URL: http://www.allaboutagile.com/themes-in-agile-software-development/ .

11

A user story statement could be structured by using basic (or primitive) questions: who, what, and why. These questions can, in turn, be mapped to include (1) a user role, (2) a user goal, and (3) a specific value to the user role by the realization of the user story in the software system, respectively. Using the above, a systematic format for the statement of a user story could be adopted. For example, in the following format, a user story statement is structured using role, goal, and value (with interspersed text denoted by ellipsis):

A <Role> ... <Goal> ... <Value> ...

ROLE A user plays a role with respect to the software system. A user, by virtue of the explicit mention of role, is first-class in a user story statement. (This gives credence to the claim that a user story is a kind of user requirement.) A role must have a name. There must be a basis for this name. This basis can be provided in one of the following ways: User Model. If user roles have been elicited, then the names of user roles can serve as role names for user stories. Use Case Model. If a use case model has been constructed, then the names of a subset of the human actors, can serve as role names for user stories.

GOAL Definition [Goal] [ANSI, 2001; ISO, 1998]. An intended outcome of user interaction with a product. A user has a (implicit or explicit) goal for using a software system. To achieve that goal, the user carries out a collection of tasks. It is important to distinguish between a user goal and a software system feature [Cohn, 2004].

12

Let G be a user goal and let F be list of features of a software system S upon completion and delivery. However, that does not automatically imply that S meets G, that is, it does not imply automatically imply that F is sufficient to carry out the tasks required to achieve G. Therefore, there needs to be parity between G and F. VALUE A value provides the rationale or reason for the existence of a user story. It is important to note that the value system of software engineers, and customers/users, may not be identical, or even overlapping. In general, the value must be explicit. However, at times, the value can be implicit in the goal. Remark. The attention to value forms a premise for Value-Based Software Engineering (VBSE) [Biffl, Aurum, Boehm, Erdogmus, Grnbacher, 2006] and Strategic Software Engineering [McGregor, 2007; McGregor, 2008]. CONSTRAINT This entry includes constraints, if any, on the user story statement. A user story statement is not necessarily absolute, and must be situated in its context wherever necessary. There may be one or more constraints on the user story statement. These are usually related to non-functional requirements, including quality requirements. NOTE This entry includes notes that result from communicating with the customer/user. A user story reflects shared understanding as a result of conversation followed by negotiation with the customer/user. This communication must be made explicit as necessary. For example, a note may be about a pending issue that needs to be conferred with the customer/user before a decision takes place. A note can also act as a placeholder for

13

miscellaneous information, that is, information otherwise not included elsewhere in the card. PRIORITY This entry includes the indicator of priority of the user story. A prioritization is a kind of ordering, or ranking. The prioritization of user stories is based on the assumption that the user stories are comparable with respect to some property, and are on an ordinal scale [Fenton, Pfleeger, 1997, Section 2.3.2] with respect to that property. For example, such a property could be perceived degree of relevancy (or value) to users [Ratcliffe, McNeill, 2012, Section 8.11], risk, relevancy to other (dependent) user stories, and so on. The prioritization of user stories assists in the selection of user stories for a specific purpose. For example, user stories may need to be prioritized so that the most significant ones are met by the earliest product releases. The current approaches for prioritizing software requirements vary in a number of ways, including their rigor and sophistication. In [Wiegers, 2003], the High-Medium-Low approach is used for prioritizing software requirements. In [Cohn, 2004], the MoSCoW approach is used for prioritizing user stories. The abbreviation MoSCoW stands for MUST, SHOULD, COULD, and WOULD, and the approach has its origins in the Dynamic Systems Development Method (DSDM) [Stapleton, 2003], an agile methodology. In [Layon, 2012, Page 16], it has been suggested that the Kano Model7 can be used for prioritizing user stories. ESTIMATE This entry includes an estimate of the user story. The estimate is usually an estimate of size of the user story.
The Kano Model is part of a theory of product development and customer satisfaction developed in the 1980s by Noriaki Kano, and is used for Quality Function Deployment (QFD) in industrial engineering. It provides a classification of customer preferences, such as satisfiers/dissatisfiers, and so on.
7

14

The inclusion of an estimate is important for managing time, and for making sure that the development is on the right course. Remark. A unique aspect of the user story approach for expressing software requirements is its application towards estimation. Indeed, the definition of a user story acknowledges the significance of an estimate. ACCEPTANCE CRITERIA
Testing must be an unavoidable aspect of development, and the marriage of development and testing is where quality is achieved. James Whittaker, Jason Arbon, and Jeff Carollo

Definition [Acceptance Criteria] [ISO/IEC/IEEE, 2010]. [The] criteria that a [software] system must satisfy in order to be accepted by a user, customer, or other authorized entity. The acceptance criteria for a user story are a collection of conditions under which an implementation of that user story is accepted by a customer/user. These conditions usually manifest themselves as tests. The acceptance criteria may list one or more tests. The order in which the tests are listed is not significant, but a logical order of reading should be preserved. Remark. In having acceptance criteria upfront, user stories support Test-Driven Development (TDD) [Adzic, 2009; Beck, 2003; Koskela, 2008; Madeyski, 2010]. QUALITY OF TESTS It has been pointed out in [Koskela, 2008, Section 2.1.2] that a good test has a number of characteristics, including the following: Atomic (or Singular) Isolated

The style (or tone) of expressing a test is relevant. For example, the tests should not be expressed as a negative.

15

Let T be a test. Understandability. If T is expressed as a negative, then a failed T means a negative of a negative. This leads to a double negative, which can be difficult to understand [Higham, 1998]. Executability. If T is expressed as a negative, then it may not be possible to execute T. (For example, consider the following T: The system should never display a blank screen.)

REMARKS There proposed variations for describing user stories. These extensions are motivated by different reasons, for example, certification [Qasaimeh, Abran, 2011] and usability [Moreno, Yage, 2012]. 13. QUALITY OF USER STORIES
It Was the Best of Sentences, It Was the Worst of Sentences

June Casagrande There are a number of reasons for paying attention to the quality of user stories. There are a number of stakeholders of a user story including project managers, software designers, and software testers. It is imperative that a user story, like many other software artifacts, is communicable to its stakeholders. It is known that the success of a software project is intimately related to the quality of software requirements [Knauss, Boustani, Flohr, 2009]. It has been pointed out that the quality of a software system depends intrinsically on the practices of software requirements engineering [Nuseibeh, Easterbrook, 2000]. There have been a number of initiatives towards addressing the quality of user stories [Jeffries, 2001; Wake, 2002; Alexander, Maiden, 2004, Page 271; Cohn, 2004; Patel, Ramachandran, 2009], each with its own share of advantages and disadvantages. REMARKS To alleviate some of the burden on the customer [Sillitti, Succi, 2005], new roles can be created, such as Coordinator [Hoda, 2011], Liaison Officer [Hochmller, 2011], and Story Master [Read, Arreola, Briggs, 2011].

16

QUALITY ATTRIBUTES STATEMENT

RELEVANT

TO

SINGLE

USER

STORY

Atomic (or Singular) Estimatable Feasible Problem Domain-Specific Traceable Understandable Uniguous (or Uniquely Interpretable) Verifiable RELEVANT TO MULTIPLE USER STORY

QUALITY ATTRIBUTES STATEMENTS

Acyclic (or No Cyclic Dependencies) Consistent

14. EXAMPLES OF USER STORIES

I want to set an example that will never be forgotten.

Terry Fox ATM An Automated Teller Machine (ATM) is an interactive system. Its users include, but are not limited to, bank customers that have an account. EXAMPLE 1 For example, consider following user story statement. It has all the three aspects, namely role, goal, and value: A bank owner should be able to set an ATMs withdrawal parameters so that the ATM will provide funds to customers and, in doing so, be protected against fraudulent activities. Name. Set Withdrawal Parameters of ATM.

17

EXAMPLE 2 For example, consider following user story statement. In it, the role and goal are explicit; the value is implicit8. A bank customer can withdraw money from a bank account. Constraint. The total amount of funds withdrawn in a day (24 hours) should not exceed $500. The funds should be dispensed in multiples of $20. Note. Need to discuss the possibility of withdrawal of funds in the denominations of $5 and $10. Acceptance Criteria. The bank card inserted is valid. The PIN is valid. The amount requested for withdrawal is less than or equal to the balance of the account. The amount requested for withdrawal is less than or equal to $500. The amount being dispensed is a multiple of $20. EXAMPLE 3 For example, consider following user story statement. In it, the role and goal are explicit; the value is implicit9. A bank customer can transfer funds from one bank account to another bank account. There can be several reasons that can be attributed to a transfer. It may not be useful to state a clients intent of a transfer, or to equate that to value.

An obvious, and therefore implicit, value in withdrawing money from an account is the increase in the amount of money in a customers possession. 9 An obvious, and therefore implicit, value in transferring funds across accounts is the increase in the balance of the target account.

18

Name. Transfer Funds. Constraint. The funds should be transferred in multiples of $10. Note. Need to discuss the possibility of transfer of funds in multiples of $5. Acceptance Criteria. The bank card inserted is valid. The PIN is valid. The source account has sufficient funds to accommodate the amount being transferred. (In other words, if A is the amount being transferred and S is balance of the source account, then S A.) The amount being transferred is a multiple of $10. (In other words, if A is the amount being transferred, then A = n 10, where n is a non-negative integer.) HRIS A Human Resources Information System (HRIS) is an interactive system. Its users are job seekers. EXAMPLE 1 For example, consider following user story statement. It has all the three aspects, namely role, goal, and value: A student can search the system for employment opportunities. Name. Search for Job. Constraint. The following could be the usability constraints: Usability-1: There should only be 20 search results presented at a time to a student. Usability-2: It should take less than or equal to 5 seconds on average for the search results to be presented to a student. The following could be the rationale for Usability-2:

19

The ethnographic studies have indicated that users expect a facility for searching. However, for search to be effective, it should be reasonably fast. It has been shown empirically that large amount of information can overwhelm users and users typically do not like to wait more than 5 seconds for search results. Remark. It is evident that usability constraints (and associated rationale) depend on the context of use. For example, mobile phones tend to have screens with small horizontal and vertical dimensions. Therefore, it can be difficult to present 20 search results on such screens without a lot of vertical scrolling (that, in turn, is prohibitive towards operability, a necessary condition for usability according to the ISO/IEC 9126-1 Standard [ISO/IEC, 2001], and its successor, the ISO/IEC 25010 Standard [ISO/IEC, 2011]). VOD A Video-On-Demand (VOD) system is an interactive system. It has customers. EXAMPLE 1 For example, consider the following user story statement. It includes an explicit value that is essentially repeating information (or, at least, not adding any special information beyond the goal). A VOD customer, upon the selection of the Movie Channel, should be able to see the information on that movie so that the customer can know more about that movie. EXAMPLE 1' The following user story statement includes an explicit value that adds information beyond the goal. However, that value can still be perceived as obvious. A VOD customer, upon the selection of the Movie Channel, should be able to see the information on that movie so that the customer is better informed about that movie before deciding to view that movie. 15. SUPPORT FOR USER STORIES In recent years, the notion of a user story has found increasing support. The depth and breadth of support are both important for longevity, as well as for further proliferation of user story as a means for expressing a user requirement. Figure 7 provides a glimpse of the current environment that supports of user stories. 20

Figure 7. A panorama of the support environment for theory and practice of user stories. 15.1. SUPPORT FOR USER STORIES IN AGILE METHODOLOGIES The user stories are supported explicitly in the Agile Project Management (APM) Delivery Framework [Highsmith, 2009], as shown in Figure 8.

Figure 8. The user stories have a prominent place in Agile Project Management (APM) Delivery Framework [Highsmith, 2009]. 21

15.2. USER STORIES IN BEHAVIOUR-DRIVEN DEVELOPMENT The user stories are supported explicitly in Behaviour-Driven Development (BDD)10 [Chelimsky, Astels, Dennis, Hellesoy, Helmkamp, North, 2010]. In BDD, user stories are part of the BDD process. 15.3. USER STORIES IN EXTREME PROGRAMMING The user stories are supported explicitly in Extreme Programming (XP) [Beck, Andres, 2005]. In fact, the notion of a user story was first introduced in XP [Beck, 2000]. The importance of user stories in XP is signified by the statement everything in XP revolves around user stories [Stephens, Rosenberg, 2003, Page 80]. For example, in an XP project, the estimates of the user stories that were finished during the iteration are used as input to Release Planning, to determine Project Velocity, and as an input to Iteration Planning. This is illustrated in Figures 9 and 10.

Figure 9. The user stories are an input to release planning in XP11.

10 11

URL: http://behaviour-driven.org/ . URL: http://www.extremeprogramming.org/ .

22

Figure 10. The user stories are an input to iteration planning in XP12. 15.4. USER STORIES IN SCRUM The user stories are supported explicitly in Scrum [Schwaber, Beedle, 2002; Schwaber, 2004]. For example, in a Scrum project, user stories are part of the Product Backlog. This is illustrated in Figure 11.

Figure 11. The user stories are included in the Product Backlog in Scrum [Schwaber, 2004].

12

URL: http://www.extremeprogramming.org/ .

23

15.5. USER STORIES IN USER-CENTERED AGILE PROCESS In [Beyer, 2010, Chapter 5], User-Centered Agile Process (UCAP) is presented. UCAP, as shown in Figure 12, builds upon previous knowledge of Contextual Design [Holtzblatt, Wendell, Wood, 2005; Holtzblatt, 2008], XP, and Scrum.

Figure 12. UCAP is an agile development process that integrates user experience upfront [Beyer, 2010, Chapter 5]. UCAP attempts to make agile development truly user-centered by preceding agile development with a phase 0 for user research and user experience design. The idea is that [after] a sound understanding of the user [], the team can then write good user stories and go into agile development sprints confident that they know what problem they are solving and have an initial direction for solving it. The user stories are supported explicitly in UCAP. They are developed in the Release Planning Session of UCAP. The user stories are among the artifacts of Agile Experience Design (AXD) [Ratcliffe, McNeill, 2012, Page 101]. Figure 13 shows elements of a conceptual model for AXD.

Figure 13. A conceptual model for AXD [Ratcliffe, McNeill, 2012, Page 11]. 24

15.6. SUPPORT FOR USER STORIES IN STANDARDS There are standards for software requirements, such as the IEEE Standard 830-1998 [IEEE, 1998] and, its successor, the ISO/IEC/IEEE 29148 Standard [ISO/IEC/IEEE, 2011]. There are standards that cover user requirements, such as the ISO 13407 Standard [ISO, 1999] and, its successor, the ISO 9241-210 Standard [ISO, 2010]. There is currently no standard that is dedicated specifically to user stories, although there are standards that indirectly address user stories. ISO/IEC/IEEE

There is an attempt to align user stories (as given in XP) to meet ISO 9001 Formality Requirements by proposing extensions to user stories [Qasaimeh, Abran, 2011]. The user stories are mentioned (in the context of agile user documentation) in ISO/IEC/IEEE 26515 Standard [ISO/IEC/IEEE, 2012]. IIBA

The user stories have been covered (in the context of means for specifying software requirements) in a Guide to the Business Analysis Body of Knowledge (BABOK) [IIBA, 2006, Section 5.14.7; IIBA, 2009, Section 9.33]. 15.7. SUPPORT FOR USER STORIES IN INDUSTRY In recent years, user stories have received increasing attention in industrial contexts that carry out software-intensive projects. For example, there are reports of deployment of user stories in organizations providing products/services related to computer games [Keith, 2010, Chapter 5], student welfare [Bang, 2007], and telecommunications (like Shaw Communications).

25

However, for apparent reasons, such publicly available literature is rare. This situation is unlikely to change in the foreseeable future. 16. USER STORIES IN CONTEXT There are similarities and differences between user stories and use cases. There are similarities and differences between user stories and software requirements, as given by the IEEE Standard 830-1998 [IEEE, 1998] and, its successor, the ISO/IEC/IEEE 29148 Standard [ISO/IEC/IEEE, 2011]. 17. THE LIMITATIONS OF USER STORIES There are a few inherent limitations of user stories that limit their applicability for certain types of software projects. These limitations are anthropological, organizational sociological, and, technical. The limitations related to user stories can be broadly classified along the following dimensions: Culture Personnel Skills Language

ORGANIZATIONAL CULTURE In an organizational culture of contract-based development, the adoption of user stories is not automatic. There are different governance styles of an organization, leading to different kinds of organization cultures. In one of the models for software organization cultures [Constantine, 1993], there are four cultural paradigms: open, closed, synchronous, and random. An organization may have a certain approach (philosophy) to software development [Wiegers, 1996]. The Conways Law13 states:

13

URL: http://www.melconway.com/research/committees.html .

26

Any organization that designs a system [] will inevitably produce a design whose structure is a copy of the organizations communication structure. In a transition by an organization from one software development approach to another, say from rigidity to agility, the culture of that organization plays a critical role. A discussion of the issues involved in such a transition is beyond the scope of this document. INVOLVEMENT OF PERSONNEL The support for explicit involvement of customers/users during requirements elicitation in a software process is not automatic. Indeed, a successful involvement of customers/users depends on a number of factors. For example, software process models of the 1970s did not have such support. In particular, the Waterfall Model does not have any explicit support for involving users14. In XP, there is a practice of Onsite Customer. The advantages and disadvantages of customer involvement, especially if it is on a full-time basis, in XP-based software projects have been considered in [Mohammadi, Nikkhahan, Sohrabi, 2009]. Furthermore, even if XP-based software project does aim to do so, the customers/users may not be readily available due to space constraints (for example, they may be remotely located) or time constraints (for example, they may be occupied with their own work [Beyer, 2010]). PRESENCE OF REQUISITE SKILLS The user stories involve technical as well as non-technical skills. It is known that negotiation is a skill that is acquired with experience. It is not automatic that a person has, or can acquire, the negotiating skills at the level expected for developing user stories [Kovitz, 2003]. The same can be said of other aspects of user stories. It is not automatic that a person has, or can acquire, skills for (1) authoring user stories at the level expected for developing user stories of high-quality [Kovitz, 2003], (2) formulating and expressing tests for user stories [Wiegers, Beatty, 2013], and (3) estimating user stories.
14

This should not be taken to imply that the involvement of users is prohibited in the Waterfall Model.

27

USE OF NATURAL LANGUAGE The limitations of the use of natural language for expressing software requirements have been studied previously [Meyer, 1985]. It is known that natural languages are inherently (and deliberately) ambiguous and allow variations in writing styles. These properties, if not managed, can make a software requirement difficult to understand (prohibitive to understandability) and therefore difficult to verify (prohibitive to verifiability. The adoption of user stories is unlikely in software projects in which these limitations are unacceptable. ACKNOWLEDGEMENT The inclusion of images from external sources is only for non-commercial educational purposes, and their use is hereby acknowledged.

28

REFERENCES [Adzic, 2009] Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing. By G. Adzic. Neuri Limited. 2009. [Alexander, Maiden, 2004] Scenarios, Stories, Use Cases through the Systems Development Life-Cycle. By I. Alexander, N. Maiden. John Wiley and Sons. 2004. [ANSI, 2001] ANSI-NCITS 354-2001. Common Industry Format for Usability Test Reports. American National Standards Institute (ANSI). 2001. [Bang, 2007] An Agile Approach to Requirement Specification. By T. J. Bang. The Eighth International Conference on Agile Processes in Software Engineering and Extreme Programming (XP 2007). Como, Italy. June 18-22, 2007. [Beck, 2000] Extreme Programming Explained: Embrace Change. By K. Beck. AddisonWesley. 2000. [Beck, 2003] Test-Driven Development By Example. By K. Beck. Addison-Wesley. 2003. [Beck, Andres, 2005] Extreme Programming Explained: Embrace Change. By K. Beck, C. Andres. Second Edition. Addison-Wesley. 2005. [Beyer, 2010] User-Centered Agile Methods. By H. Beyer. Morgan and Claypool. 2010. [Biffl, Aurum, Boehm, Erdogmus, Grnbacher, 2006] Value-Based Software Engineering. By S. Biffl, A. Aurum, B. Boehm, H. Erdogmus, P. Grnbacher (Editors). Springer-Verlag. 2006. [Brooks, 1987] No Silver Bullet: Essence and Accidents of Software Engineering. By F. P. Brooks, Jr. Computer. Volume 20. Number 4. 1987. Pages 10-19. [Chelimsky, Astels, Dennis, Hellesoy, Helmkamp, North, 2010] The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends. By D. Chelimsky, D. Astels, Z. Dennis, A. Hellesoy, B. Helmkamp, D. North. Pragmatic Bookshelf. 2010. [Cohn, 2004] User Stories Applied: For Agile Software Development. By M. Cohn. Addison-Wesley. 2004.

29

[Cohn, 2005] Agile Estimating and Planning. By M. Cohn. Prentice-Hall. 2005. [Constantine, 1993] Work Organization: Paradigms for Project Management and Organization. By L. L. Constantine. Communications of the ACM. Volume 36. Issue 10. 1993. Pages 35-43. [Constantine, Lockwood, 1999] Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. By L. L. Constantine, L. A. D. Lockwood. AddisonWesley. 1999. [Fenton, Pfleeger, 1997] Software Metrics: A Rigorous and Practical Approach. By N. E. Fenton, S. L. Pfleeger. International Thomson Computer Press. 1997. [Higham, 1998] Handbook of Writing for the Mathematical Sciences. By N. J. Higham. Second Edition. Society for Industrial and Applied Mathematics. 1998. [Highsmith, 2002] Agile Sofware Development Ecosystems. By J. Highsmith. AddisonWesley. 2002. [Highsmith, 2009] Agile Project Management: Creating Innovative Products. By J. Highsmith. Addison-Wesley. 2009. [Hochmller, 2011] The Requirements Engineer as a Liaison Officer in Agile Software Development. By E. Hochmller. The First Workshop on Agile Requirements Engineering (AREW 2011). Lancaster, U.K., July 26, 2011. [Hoda, 2011] Self-Organizing Agile Teams: A Grounded Theory. By R. Hoda. Ph.D. Thesis. Victoria University of Wellington. Wellington, New Zealand. 2011. [IEEE, 1990] IEEE Standard 610.12-1990. IEEE Standard Glossary of Software Engineering Terminology. IEEE Computer Society. 1990. [IEEE, 1998] IEEE Standard 830-1998. Recommended Practice for Software Requirements Specifications. IEEE Computer Society. 1998. [IIBA, 2006] A Guide to the Business Analysis Body of Knowledge, Release 1.6. International Institute of Business Analysis (IIBA). 2006. [IIBA, 2009] A Guide to the Business Analysis Body of Knowledge, Version 2.0. International Institute of Business Analysis (IIBA). 2009.

30

[ISO, 1998] ISO 9241-11:1998. Ergonomic Requirements for Office Work with Visual Display Terminals (VDTs) Part 11: Guidance on Usability. The International Organization for Standardization (ISO). 1998. [ISO, 1999] ISO 13407:1999. Human-Centred Design Processes for Interactive Systems. The International Organization for Standardization (ISO). 1999. [ISO, 2010] ISO 9241-210:2010. Ergonomics of Human-System Interaction -- Part 210: Human-Centred Design for Interactive Systems. The International Organization for Standardization (ISO). 2010. [ISO/IEC, 2001] ISO/IEC 9126-1:2001. Software Engineering -- Product Quality -- Part 1: Quality Model. The International Organization for Standardization (ISO)/The International Electrotechnical Commission (IEC). 2001. [ISO/IEC, 2010] ISO/IEC TR 25060:2010. Systems and Software Engineering -- Systems and Software Product Quality Requirements and Evaluation (SQuaRE) -- Common Industry Format (CIF) for Usability: General Framework for Usability-Related Information. The International Organization for Standardization (ISO)/The International Electrotechnical Commission (IEC). 2010. [ISO/IEC, 2011] ISO/IEC 25010:2011. Systems and Software Engineering -- Systems and Software Quality Requirements and Evaluation (SQUARE) -- System and Software Quality Models. The International Organization for Standardization (ISO)/The International Electrotechnical Commission (IEC). 2011. [ISO/IEC/IEEE, 2010] ISO/IEC/IEEE 24765:2010. Systems and Software Engineering -Vocabulary. The International Organization for Standardization (ISO)/The International Electrotechnical Commission (IEC)/The Institute of Electrical and Electronics Engineers (IEEE) Computer Society. 2010. [ISO/IEC/IEEE, 2011] ISO/IEC/IEEE 29148:2011. Systems and Software Engineering -Life Cycle Processes -- Requirements Engineering. The International Organization for Standardization (ISO)/The International Electrotechnical Commission (IEC)/The Institute of Electrical and Electronics Engineers (IEEE) Computer Society. 2011. [ISO/IEC/IEEE, 2012] ISO/IEC/IEEE 26515:2012. Systems and Software Engineering -Developing User Documentation in an Agile Environment. The International Organization for Standardization (ISO)/The International Electrotechnical Commission

31

(IEC)/The Institute of Electrical and Electronics Engineers (IEEE) Computer Society. 2012. [Jeffries, 2001] Essential XP: Card, Conversation, and Confirmation. By R. Jeffries. XP Magazine. August 30, 2001. [Jokela, Abrahamsson, 2004] Usability Assessment of an Extreme Programming Project: Close Co-operation with the Customer Does Not Equal to Good Usability. By T. Jokela, P. Abrahamsson. The Fifth International Conference on Product Focused Software Process Improvement (PROFES 2004). Kausai Science City, Japan. April 5-8, 2004. [Kamthan, Shahmir, 2010] Towards an Understanding of the User Story Environment. By P. Kamthan, N. Shahmir. The Fifteenth IBIMA Conference on Knowledge Management and Innovation: A Business Competitive Edge Perspective. Cairo, Egypt. November 6-7, 2010. [Keith, 2010] Agile Game Development with Scrum. By C. Keith. Addison-Wesley. 2010. [Knauss, Boustani, Flohr, 2009] Investigating the Impact of Software Requirements Specification Quality on Project Success. By E. Knauss, C. El Boustani, T. Flohr. The Tenth International Conference on Product-Focused Software Process Improvement (PROFES 2009). Oulu, Finland. June 15-17, 2009. [Koskela, 2008] Test Driven: TDD and Acceptance TDD for Java Developers. By L. Koskela. Manning Publications. 2008. [Kovitz, 2003] Hidden Skills that Support Phased and Agile Requirements Engineering. By B. Kovitz. Requirements Engineering. Volume 8. Number 2. 2003. Page 135-141. [Layon, 2012] Mobilizing Web Sites: Strategies for Mobile Web Implementation. By K. Layon. Peachpit Press. 2012. [Leffingwell, 2011] Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. By D. Leffingwell. Addison-Wesley. 2011. [Madeyski, 2010] Test-Driven Development: An Empirical Evaluation of Agile Practice. By L. Madeyski. Springer-Verlag. 2010.

32

[McGregor, 2007] Value. By J. D. McGregor. Journal of Object Technology. Volume 6. Number 10. 2007. Pages 9-15. [McGregor, 2008] An Increase In Value. By J. D. McGregor. Journal of Object Technology. Volume 7. Number 3. 2008. Pages 7-16. [Messerschmitt, Szyperski, 2003] Software Ecosystem: Understanding an Indispensable Technology and Industry. By D. G. Messerschmitt, C. Szyperski. The MIT Press. 2003. [Meyer, 1985] On Formalism in Specifications. By B. Meyer. IEEE Software. Volume 11. Issue 1. 1985. Pages 6-26. [Mohammadi, Nikkhahan, Sohrabi, 2009] Challenges of User Involvement in Extreme Programming Projects. By S. Mohammadi, B. Nikkhahan, S. Sohrabi. International Journal of Software Engineering and Its Applications. Volume 3. Number 1. 2009. Pages 19-32. [Moreno, Yage, 2012] Agile User Stories Enriched with Usability. By A. M. Moreno, A. Yage. The Thirteenth International Conference on Agile Processes in Software Engineering and Extreme Programming (XP 2012). Malm, Sweden. May 21-25, 2012. [Nuseibeh, Easterbrook, 2000] Requirements Engineering: A Roadmap. By B. Nuseibeh, S. Easterbrook. The Twenty Second International Conference on Software Engineering (ICSE 2000). Limerick, Ireland. June 4-11, 2000. [Patel, Ramachandran, 2009] Story Card Based Agile Software Development. By C. Patel, M. Ramachandran. International Journal of Hybrid Information Technology. Volume 2. Number 2. 2009. Pages 125-140. [Qasaimeh, Abran, 2011] Extending Extreme Programming User Stories to meet ISO 9001 Formality Requirements. By M. Qasaimeh, A. Abran. Journal of Software Engineering and Applications. Volume 4. Number 11. 2011. Pages 626-638. [Ratcliffe, McNeill, 2012] Agile Experience Design: A Digital Designers Guide to Agile, Lean, and Continuous. By L. Ratcliffe, M. McNeill. New Riders. 2012. [Read, Arreola, Briggs, 2011] The Role of the Story Master: A Case Study of the Cognitive Load of Story Management Tasks. By A. Read, N. Arreola, R. O. Briggs. The Forty Fourth Hawaii International Conference on Systems Science (HICSS-44 2011). Koloa, U.S.A. January 4-7, 2011.

33

[Schuler, Namioka, 1993] Participatory Design: Principles and Practices. By D. Schuler, A. Namioka (Editors). CRC Press. 1993. [Schwaber, 2004] Agile Project Management with Scrum. By K. Schwaber. Microsoft Press. 2004. [Schwaber, Beedle, 2002] Agile Software Development with Scrum. By K. Schwaber, M. Beedle. Prentice-Hall. 2002. [Sillitti, Succi, 2005] Requirements Engineering for Agile Methods. By A. Sillitti, G. Succi. In: Engineering and Managing Software Requirements. A. Aurum, C. Wohlin (Editors). Springer-Verlag. Pages 309-326. [Stapleton, 2003] DSDM: Business Focused Development. By J. Stapleton. AddisonWesley. 2003. [Stephens, Rosenberg, 2003] Extreme Programming Refactored: The Case Against XP. By M. Stephens, D. Rosenberg. Apress. 2003. [Wake, 2002] Extreme Programming Explored. By W. C. Wake. Addison-Wesley. 2002. [Wiegers, 1996] Creating a Software Engineering Culture. By K. Wiegers. Dorset House. 1996. [Wiegers, 2003] Software Requirements. By K. E. Wiegers. Second Edition. Microsoft Press. 2003. [Wiegers, Beatty, 2013] Software Requirements. By K. Wiegers, J. Beatty. Third Edition. Microsoft Press. 2013.

34

This resource is under a Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported license.

35