Story Cards


Published on

Elicitation Of Requirements By Using Story Cards (User Story)

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Add slides to each topic section as necessary, including slides with tables, graphs, and images. See next section for sample table, graph, image, and video layouts.
  • Story Cards

    1. 1. AgendA• What Is Story Cards• Creating Story Cards• Story Cards Templates• Examples• Benefits & Limitation• Characteristics Of Good Story Card
    2. 2. What Is Story Cards?• a user story is one or more sentences in the everyday or business languageof the end user or user of a system that captures what a user does orneeds to do as part of his or her job function.• User stories are used with agile software development methodologies asthe basis for defining the functions a business system must provide, and tofacilitate requirements management. It captures the who, what andwhy of a requirement in a simple, concise way, often limited in detail bywhat can be hand-written on a small paper notecard.
    3. 3. Creating Story Cards-1• Story Cards are written by or for the businessuser as that users primary way to influencethe functionality of the system beingdeveloped. User stories may also be writtenby developers to express non-functionalrequirements (security, performance, quality,etc.),[1] though primarily it is the task of aproduct manager to ensure user stories arecaptured.
    4. 4. Creating Story Cards-2• When the time comes for creating Story Cards-2, one of thedevelopers (or the product owner in Scrum) gets together with acustomer representative.• The customer has the responsibility for formulating the user stories.• The developer may use a series of questions to get the customergoing, such as asking about the desirability of some particularfunctionality• If the developer and customer find a user story deficient in someway (too large, complicated, imprecise), it is rewritten until it issatisfactory - often using the INVEST guidelines to insure the storycard written correct.
    5. 5. 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 asoptional.• "As a <role>, I want <goal/desire>"• Chris Matts suggested that "hunting the value" was the first step in successfullydelivering software, and proposed this alternative as part of Feature Injection.• "In order to <receive benefit> as a <role>, I want <goal/desire>"
    6. 6. 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 thatmust be fulfilled for proper software operation versusstories that improve the operation, but are not criticalfor correct behavior.
    7. 7. 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 changedin data• since the last save!).
    8. 8. Characteristics Of Good Story Card1) 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 isa reminder of features for the team to discuss and collaborate to clarify thedetails near the time of development.3) Valuable – User Stories should be valuable to the user (or owner) of thesolution. They should be written in user language. They should be features, nottasks.4) Estimatable – User Stories need to be possible to estimate. They need toprovide 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 toosubjective and to provide clear details of how the User Story will be tested.
    9. 9. Benefits (Advantages)1. Being very short. They represent small chunks of business value that can beimplemented in a period of days to weeks.2. Allowing developer and the client representative to discuss requirementsthroughout 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 poorlyunderstood. 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 mostvalued parts of the software get implemented.
    10. 10. Limitations (Disadvantages)1. They can be difficult to scale to large projects.2. They are regarded as conversation starters.
    11. 11. Different Between Story Cardsand use casesStory Cards Use Case1- Provide a small-scale and easy-to-use presentation of information.2- Must be accompanied byacceptance testing procedures(acceptance criteria) for clarificationof behavior where stories appearambiguous.Describe a process and its steps indetail, and may be worded in termsof a formal model. A use case isintended to provide sufficient detailfor it to be understood on its own. Ause case has been described as “ageneralized description of a set ofinteractions between the systemand one or more actors, where anactor is either a user or anothersystem”2- May be delivered in a stand-alonedocument.
    12. 12. •Examples