User Stories Applied:

For Agile Software Development

–

Ch 2. Writing Stories

Chen Jing Fung @iii

2011/6/7

Six attributes for a good story

• Independent

• Negotiable

• Valuable to user or customers

• Estimatable

• Small

• Testable

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…

– Alternative split by different dimension

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 customer can pay with one type of credit card (3 days),

A customer can pay with two additional types of credit cards(2 days)

=> A company can pay for a job posting with a credit card

Method - Negotiable • Key: reminders to have a space to talk

• Worries case – too much detail

• Solution: – 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: 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.

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)

Split to another

story

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

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

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

Method – small (splitting Stories) (1)

• Compound story => split to small one

• that a resume can include education,

prior jobs, salary history, publications,

presentations, community service, and

an objective

• that users can mark resumes as

inactive

• that users can have multiple resumes

• that users can edit resumes

• that users can delete resumes

• enter a date for each community

service entry on a resume.

• edit the date for each community

service entry on a resume.

• enter a date range for each prior job

on a resume.

• edit the date range for each prior job

on a resume.

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

Too small

Split individually

Developers mean:

Re-compose

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

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

1. involve having a human factors

2. put to an iteration to investigate them, and then really run it

Solution:

A user must never have to wait long for any screen to appear

New screens appear with in 2 seconds in 95% of all cases

Solution: Quantification => can verify it

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