Agile writing stories


Published on

Writing a good story is must to cowork with customers & developers. That includes skills:
1. independent each part,
2. negotiable,
3. involving the value with users & customers,
4. estimatable,
5. separating approximately one
6. testable

Published in: Business, Technology
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
  • Discover Card is another credit card company & its rival MasterCard and VISA. Discover Card has no annual fee and offered a higher credit limit than small cards (just service in USB & China- 上海 ) (
  • User: use the software; purchaser: buy the software
  • Agile writing stories

    1. 1. User Stories Applied:For Agile Software Development – Ch 2. Writing Stories Chen Jing Fung @iii 2011/6/7
    2. 2. Six attributes for a good story• Independent• Negotiable• Valuable to user or customers• Estimatable• Small• Testable
    3. 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. 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. 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. 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. 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. 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. 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. 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. 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