User Stories Introduction

8/14/2019 User Stories Introduction

1/35

1

INTRODUCTION TO USER STORIES

BY PANKAJ KAMTHAN

1. INTRODUCTION

It is more helpful [...] to recognize that the solution is located in the computer and itssoftware, and the problem is in the world outside. [...] The computers can provide solutions tothese problems because they are connected to the world outside. [...] To study and analyse aproblem you must focus on studying and analysing the problem world in some depth, and inyour 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 mostresponsive 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.

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


2/35

2

The variabilitiesin 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.

3. THE INCEPTION OF AGILE METHODOLOGIES AND USER STORIES

The Agile Manifesto2, in general, and the inception of agile methodologiesfor softwaredevelopment [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 grammaticalentity, whereas

a statement is a logicalentity.

There are a number of definitions of requirement, including the following.

2URL: http://agilemanifesto.org/ .

The beginnisomething


3/35

3

DEFINITION 1

Definition [Requirement] [IEEE, 1990].

(1) A condition or capability needed by a user to solve a problem or achieve anobjective.

(2) A condition or capability that must be met or possessed by a system or systemcomponent 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.


4/35

4

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 ofadoption, 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 theuser goals that a software function will satisfy.

This definition does not highlightaspects of a user story that are uniqueas compared to

other forms of expressing user requirements.

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


5/35

5

REMARKS

A user story reflects a particular styleof expressing a user requirementfor 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 relationshipbetween software engineers and

customers/users [Alexander, Maiden, 2004, Page 268] from conversing and listeningto

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].


6/35


7/35

7

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 viewsof 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.


8/35

8

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 stepsin USPM, and a number of activitiesin 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 inputsto each step of USPM. The outputof 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.


9/35

9

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 describedadequately.

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 VersionThe 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 notbe necessary.


10/35

10

The typical candidate elements of information include the following:

Statement Constraint Note Priority Estimate Acceptance CriteriaThere 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-US-

007 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.


11/35

11

The names of user stories may need to be interwovenwith text. For example, a name

may appear in another software artifact. In order to distinguisha user story name from

surrounding text, some orthographic conventioncould 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 typesuser stories in a given user story book. These user stories

could be categorized topically and organized textuallyusing themes6

.

A theme aids understanding and can be useful for allocation of work.

The themes could be derived from the affinity diagramof the interviewsconducted as

part of a realizationof 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.

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


12/35

12

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 valueto 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

A user plays a role with respect to the software system.

A user, by virtue of the explicit mention of role, is first-classin 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 basisfor 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 asrole names for user stories.

Use Case Model. If a use case model has been constructed, then the names of asubset 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].


13/35

13

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 notautomatically 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 paritybetween G and F.

VALUE

A value provides the rationale or reasonfor 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 bynegotiation 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


14/35

14

miscellaneous information, that is, information otherwise not included elsewhere in the

card.

PRIORITY

This entry includes the indicatorof 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-Lowapproach is used for prioritizing software

requirements.

In [Cohn, 2004], the MoSCoW approach is used for prioritizing user stories. The

abbreviation MoSCoWstands 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 Model7can be used for

prioritizing user stories.

ESTIMATE

This entry includes an estimate of the user story. The estimate is usually an estimate of

sizeof the user story.

7The Kano Model is part of a theory of product development and customer satisfactiondeveloped in the1980s 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.


15/35

15

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 andtesting 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 orderin which the tests are listed is not significant, but a logical order of readingshould 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) IsolatedThe style (or tone)of expressing a test is relevant. For example, the tests should not be

expressed as a negative.


16/35

16

Let T be a test.

Understandability.If T is expressed as a negative, then a failed T means a negativeof 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 executeT. (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 communicableto its stakeholders.

It is known that the success of a software projectis 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 rolescan becreated, such as Coordinator [Hoda, 2011], Liaison Officer [Hochmller, 2011], and

Story Master[Read, Arreola, Briggs, 2011].


17/35

17

QUALITY ATTRIBUTES RELEVANT TO SINGLE USER STORY

STATEMENT

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

STATEMENTS

Acyclic (or No Cyclic Dependencies) Consistent14. 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 ATMwill provide funds to customers and, in doing so, be protected against fraudulent

activities.

Name.Set Withdrawal Parameters of ATM.


18/35

18

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 notbe useful to

state a clients intentof a transfer, or to equate that to value.

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


19/35

19

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 amountbeing 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 rationalefor Usability-2:


20/35


21/35

21

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].


22/35

22

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 areused 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.

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


23/35

23

Figure 10.The user stories are an input to iteration planning in XP12

.

15.4. USER STORIES IN SCRUM

The user stories are supported explicitlyin 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].

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


24/35

24

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 Sessionof 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].


25/35

25

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 indirectlyaddress user stories.

ISO/IEC/IEEE

There is an attempt to align user stories (as given in XP) to meet ISO 9001 Formality

Requirementsby 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 tocomputer games[Keith, 2010, Chapter 5], student welfare

[Bang, 2007], andtelecommunications(like Shaw Communications).


26/35

26

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 differencesbetween 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, organizationalsociological, and, technical.

The limitations related to user stories can be broadly classified along the following

dimensions:

Culture Personnel Skills LanguageORGANIZATIONAL 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]. TheConways Law

13states:

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


27/35


28/35


29/35

29

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. Addison-

Wesley. 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.


30/35

30

[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. Addison-

Wesley. 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. Addison-

Wesley. 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.


31/35


32/35

32

(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 forTeams, 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.


33/35

33

[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. Pages19-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 toAgile, 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.


34/35

34

[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. Addison-Wesley. 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.


35/35

This resource is under a Creative Commons Attribution-Noncommercial-NoDerivative Works 3.0 Unportedlicense.

Documents

User Stories Introduction