The document discusses six attributes for writing good user stories for agile software development: independent, negotiable, valuable, estimatable, small, and testable. It provides examples and methods for ensuring stories have these attributes, such as splitting large compound stories into smaller individual stories, adding notes for negotiation, and making stories focused on functionality that can be tested.

1. User Stories Applied:
For Agile Software Development
–
Ch 2. Writing Stories
Chen Jing Fung @iii
2011/6/7

2. Six attributes for a good story
• Independent
• Negotiable
• Valuable to user or customers
• Estimatable
• Small
• Testable

3. Method - Independent
• Dependencies problem
– Prioritization + planning problems => make estimation
(hard)
• Independent
– Combing the stories into a single large story
• Ex: how companies can pay for job openings…
A company can pay for a job posting with a Visa Card
A company can pay for a job posting with a MasterCard
A company can pay for a job posting with an American Express card
=> A company can pay for a job posting with a credit card
– Alternative split by different dimension
A customer can pay with one type of credit card (3 days),
A customer can pay with two additional types of credit cards(2 days)

4. Method - Negotiable
• Key: reminders to have a space to talk
• Worries case – too much detail
A company can pay for a job posting with a credit card
Note: Accept Visa, MasterCard & American Express.
Consider Discover card. On purchases over $100, ask for card ID num. from
back of card. The system can tell what type of card it is from the first 2 digits
of the card numbers. Collect the expiration month and date of the card
The system can store a card number for future use.
Split to another
• Solution: story
– A phrase or two that act as reminders to hold the conversation
– Notes about issues to be resolved during the conversation
A company can pay for a job posting with a credit card
Note: Will we accept Discover cards?
Note for UI: Don’t have a field for card type
(it can be derived from first two digits on the cards)

5. Method – Valuable to Purchasers or Users (1)
• Key: user vs. purchaser are distinction
– User just use the software
– Purchaser cares all configuration info.(user
capabilities) from a central location (but users
don’t care)
• Software quality index. Ex: pass an ISO 9001 audit
or CMMI L3 certification => imply test cases from
the story is important!!)
Test with Visa, MasterCard and American Express (pass).
Test with Diner’s Club (fail).
Test with good, bad and missing card ID numbers.
Test with expired cards.
Test with over $100 and under $100

6. Method – Valuable to Purchasers or Users (2)
• Avoid
– All connection to the database are through a
connection pool. => too chaos !!
– All error handling and logging is done through a set of
common classes. => think more to describe out of
control situations 
• Solution
– Up to 50 users to use the application with a 5-user
database license.
– All errors are presented to the user and logged in a
consistent manner.
• Remove the use of a connection pool & a set of error
handling classes
– Developers trained customer or users to write a story

7. Method - Estimatable
• Non-estimatable reasons
– Developers lack domain knowledge => need to ask
customers frequently until understanding the overview
story
• Ex: Give new users a diabetic screening
– Developers lack technical knowledge => call a spike
• No one on the team had done
• Extreme Programmers learn enough the spike(1. gather
info.), then they can estimate the task(2. to do the real
work).
• Spike is always a maximum amount of time (called a timebox)
– The story is too big => split into small

8. Method – small (splitting Stories) (1)
• Compound story => split to small one
Developers mean:
• that a resume can include education, Too small
prior jobs, salary history, publications, • enter a date for each community
presentations, community service, and service entry on a resume.
an objective • edit the date for each community
• that users can mark resumes as service entry on a resume.
inactive • enter a date range for each prior job
• that users can have multiple resumes on a resume.
• that users can edit resumes • edit the date range for each prior job
• that users can delete resumes on a resume.
Split individually Re-compose
• A user can add and edit education information.
• A user can add and edit job history information.
• A user can add and edit salary history information.
• A user can add and edit publications.
• A user can add and edit presentations.
• A user can add and edit community service.
• A user can add and edit an objective.

9. Method – small (splitting Stories) (2)
• Complex story (unestimatable story) => split into 2
stories
focus on developing new or extending algorithms
– Story I: One investigative
research and determine the feasibility of extending
expectation maximization
• Difficulty on estimating how long to research
• Consider putting the Spike in a different iteration
– Story II: Developing the new feature
=> add that functionality to the product
• Combining stories into large one
– Maybe a half-day to several days of work
– Put several story cards to a cover card

10. Method - Testable
• Testable story => successfully developed
– Pass its tests means a story can be successfully
developed
• Untestable stories => nonfunctional
requirements
• Examples:
A user must find the software easy to use
Solution:
1. involve having a human factors
2. put to an iteration to investigate them, and then really run it
A user must never have to wait long for any screen to appear
Solution: Quantification => can verify it
New screens appear with in 2 seconds in 95% of all cases

11. Summary
• Ideally, stories are independent from one another
• Stories could be negotiated btw user & developers
– Avoid too much detail => no space to talk
– 1 or 2 phases are good
• Customers write the stories are well
– stories value is from user
• Write appropriate length of stories
– Too big, (compound & complex stories) split into smaller
stories
– Too small, combine several stories into one bigger story
• Stories need to be testable
– Write test case for the story