什麼一個好的User Story?
- form User Stories Applied: For Agile Software Development
好的User Story會具備哪些要素:
- Independent
- Negotiable
- Valuable to users or customers
- Estimatable
- Small
- Testable
Independent
(1) Avoid making dependencies between stories
- Hard to prioritize and plan
(2) Instead,
- Combine dependent stories
If the combined story is longer, it is usually to find a different dimension along which to split the stories
- Split in another way
(3) Example
- 你可能會寫出這樣的user story
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
Negotiable
(1) User stories are not written contracts
- Story cards are short descriptions of functionality
- The details are to be negotiated in a conversation between the customer and the development team
(2) Consider them placeholders/reminders for a conversation you should have
(3) Consider what is the right amount of information written in a user story
(4) Details that have already been determined through conversations become tests.
- Tests can be noted on the back of the story card or
- in whatever electronic system is being used
(5) Example:
Valuable to users or customers
(1) Stories with value for the user is a given
(2) Remember stories for the customer
(3) Avoid stories that have only value for the developers
- Rewrite them so they have value for the customer
(4) The best way is to have the customer write the stories.
- Ensure that each story is valuable to the customer or users
(5) Keeping in mind the distinction between user and purchaser
- These stories might be only valued by purchasers
Throughout the development process, the development team will produce documentation suitable for an ISO 9001 audit.
The development team will produce the software in accordance with CMM Level 3.
- These stories might be only valued by users
Each of the 5,000 computers is using the same configuration for the software.
(6) Find business values, not technology and the advantages to the programmers
- Examples:
All connections to the database are through a connection pool.
All error handling and logging is done through a set of common classes.
- Better examples:
Up to fifty users should be able to use the application with a five-user database license.
All errors are presented to the user and logged in a consistent manner.
Estimatable
(1) Without estimates, no plan
(2) Typical reasons why a story is hard to estimate
- Developers lack domain knowledge
- Developers lack technical knowledge
- The story is to big
Small
(1) Size matters
- Wrong size makes planning hard
(2) No definitive answer to size
(3) Faced with too large a user story see if it is
- A compound story
- A complex story
(4) A compound story
- Epic that comprises multiple shorter stories
- What does the user story: “A user can post her resume” mean ?
It should be split
- But not to small…
- CRUD operations can work as guidelines
(5) A complex story
- Cannot easily be disaggregated
- Stories are often complex because of uncertainty
- Split in two stories
An investigation store
A development story
Testable
(1) Stories must be written so as to be testable.
- Successfully passing its tests proves that a story has been successfully developed.
(2) If a story cannot be tested, how can we know when we are done coding ?
(3) Un-testable stories commonly show up for nonfunctional requirements
(4) If possible, make test automated
- form User Stories Applied: For Agile Software Development
好的User Story會具備哪些要素:
- Independent
- Negotiable
- Valuable to users or customers
- Estimatable
- Small
- Testable
Independent
(1) Avoid making dependencies between stories
- Hard to prioritize and plan
(2) Instead,
- Combine dependent stories
If the combined story is longer, it is usually to find a different dimension along which to split the stories
- Split in another way
(3) Example
- 你可能會寫出這樣的user story
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
Negotiable
(1) User stories are not written contracts
- Story cards are short descriptions of functionality
- The details are to be negotiated in a conversation between the customer and the development team
(2) Consider them placeholders/reminders for a conversation you should have
(3) Consider what is the right amount of information written in a user story
(4) Details that have already been determined through conversations become tests.
- Tests can be noted on the back of the story card or
- in whatever electronic system is being used
(5) Example:
Valuable to users or customers
(1) Stories with value for the user is a given
(2) Remember stories for the customer
(3) Avoid stories that have only value for the developers
- Rewrite them so they have value for the customer
(4) The best way is to have the customer write the stories.
- Ensure that each story is valuable to the customer or users
(5) Keeping in mind the distinction between user and purchaser
- These stories might be only valued by purchasers
Throughout the development process, the development team will produce documentation suitable for an ISO 9001 audit.
The development team will produce the software in accordance with CMM Level 3.
- These stories might be only valued by users
Each of the 5,000 computers is using the same configuration for the software.
(6) Find business values, not technology and the advantages to the programmers
- Examples:
All connections to the database are through a connection pool.
All error handling and logging is done through a set of common classes.
- Better examples:
Up to fifty users should be able to use the application with a five-user database license.
All errors are presented to the user and logged in a consistent manner.
Estimatable
(1) Without estimates, no plan
(2) Typical reasons why a story is hard to estimate
- Developers lack domain knowledge
- Developers lack technical knowledge
- The story is to big
Small
(1) Size matters
- Wrong size makes planning hard
(2) No definitive answer to size
(3) Faced with too large a user story see if it is
- A compound story
- A complex story
(4) A compound story
- Epic that comprises multiple shorter stories
- What does the user story: “A user can post her resume” mean ?
It should be split
- But not to small…
- CRUD operations can work as guidelines
(5) A complex story
- Cannot easily be disaggregated
- Stories are often complex because of uncertainty
- Split in two stories
An investigation store
A development story
Testable
(1) Stories must be written so as to be testable.
- Successfully passing its tests proves that a story has been successfully developed.
(2) If a story cannot be tested, how can we know when we are done coding ?
(3) Un-testable stories commonly show up for nonfunctional requirements
(4) If possible, make test automated
全站熱搜
留言列表
