The document discusses story cards, which are short descriptions of features or user needs used in agile software development. Key points: - Story cards capture who needs what in a simple, concise format to define system requirements from the user perspective. - They are created by talking with users/customers to understand desired functionality. Common templates include "As a <role> I want <goal> so that <benefit>". - Examples of good story cards are provided, such as "As a user I want to search for customers by name". - Characteristics of good story cards include being independent, negotiable, valuable, estimatable, small, and testable. Benefits are representing small chunks of

1. AgendA
• What Is Story Cards
• Creating Story Cards
• Story Cards Templates
• Examples
• Benefits & Limitation
• Characteristics Of Good Story Card

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

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

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

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

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 that
must be fulfilled for proper software operation versus
stories that improve the operation, but are not critical
for correct behavior.

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 changed
in data
• since the last save!).

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

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

10. Limitations (Disadvantages)
1. They can be difficult to scale to large projects.
2. They are regarded as conversation starters.

11. Different Between Story Cards
and 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.

12. •Examples