Agenda

• What Is Story Cards• Creating Story Cards• Story Cards Templates• Examples• Benefits & Limitation• Characteristics Of Good Story

Card

What Is Story Cards?

• a user story is one or more sentences in the everyday or business language of the end user or user of a system that captures what a user does or needs to do as part of his or her job function.

• User stories are used with agile software development methodologies as the basis for defining the functions a business system must provide, and to facilitate requirements management. It captures the 'who', 'what' and 'why' of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard.

Creating Story Cards-1• Story Cards are written by or for the business

user as that user's primary way to influence the functionality of the system being developed. User stories may also be written by developers to express non-functional requirements (security, performance, quality, etc.),[1] though primarily it is the task of a product manager to ensure user stories are captured.

Creating Story Cards-2• When the time comes for creating Story Cards-2, one of the

developers (or the product owner in Scrum) gets together with a customer representative.

• The customer has the responsibility for formulating the user stories.

• The developer may use a series of questions to get the customer going, such as asking about the desirability of some particular functionality

• If the developer and customer find a user story deficient in some way (too large, complicated, imprecise), it is rewritten until it is satisfactory - often using the INVEST guidelines to insure the story card written correct.

Story Cards Templates-1• the traditional user-story template :

• "As a <role>, I want <goal/desire> so that <benefit>"• Mike Cohn, a well-known author on user stories, regards the "so

that" clause as optional.

• "As a <role>, I want <goal/desire>"• Chris Matts suggested that "hunting the value" was the first step

in successfully delivering software, and proposed this alternative as part of Feature Injection.

• "In order to <receive benefit> as a <role>, I want <goal/desire>"

Story Cards Templates-2• Another template based on the (5W) specifies:

• "As <who> <when> <where>, I <what> because <why>."• The <what> portion of the user story should use

either "need" or "want" to differentiate between stories that must be fulfilled for proper software operation versus stories that improve the operation, but are not critical for correct behavior.

Examples• As a user, I want to search for my customers by their first and last names.• As a non-administrative user, • I want to modify my own schedules but not the schedules of other users.• As a mobile application tester, • I want to test my test cases and report results to my management.• Starting Application• The application begins by bringing up the last document the user was working with.• As a user closing the application, • I want to be prompted to save if I have made any change in my data since the last

save.• Closing Application• Upon closing the application, the user is prompted to save (when ANYTHING has

changed in data• since the last save!).

Characteristics Of Good Story Card

1) Independent – User Stories should be as independent as possible.2) Negotiable – a User Story is not a contract. It is not a detailed specification.

It is a reminder of features for the team to discuss and collaborate to clarify the details near the time of development.

3) Valuable – User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks.

4) Estimatable – User Stories need to be possible to estimate. They need to provide enough information to estimate, without being too detailed.

5) Small– User Stories should be small. Not too small and not too big.6) Testable – User Stories need to be worded in a way that is testable, i.e. not

too subjective and to provide clear details of how the User Story will be tested.

Benefits (Advantages)

1. Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks.

2. Allowing developer and the client representative to discuss requirements throughout the project lifetime.

3. Needing very little maintenance.4. Only being considered at the time of use.5. Maintaining a close customer contact.6. Allowing projects to be broken into small increments.7. Being suited to projects where the requirements are volatile

or poorly understood. Iterations of discovery drive the refinement process.

8. Making it easier to estimate development effort.9. Require close customer contact throughout the project so

that the most valued parts of the software get implemented.

Limitations (Disadvantages)

1. They can be difficult to scale to large projects.2. They are regarded as conversation starters.

Different Between Story Cardsand use cases

Story Cards Use Case

1- Provide a small-scale and easy-to-use presentation of information.

2- Must be accompanied by acceptance testing procedures (acceptance criteria) for clarification of behavior where stories appear ambiguous.

Describe a process and its steps in detail, and may be worded in terms of a formal model. A use case is intended to provide sufficient detail for it to be understood on its own. A use case has been described as “a generalized description of a set of interactions between the system and one or more actors, where an actor is either a user or another system”

2- May be delivered in a stand-alone document.

•Examples