RULE OF THUMB: User story consist of following 3 parts:
- Need: “As a <type of user>, I want <some goal> so that <some reason>” (~10 words)
- Conversation: Details are captured as a narrative texts that describe an interaction of the user and the system, focusing on the value a user gains from the system. This results in conversation with the product owner. A true user story is a metaphor for the work being done.
- Confirmation: User criteria written in the form of acceptance criteria, which can be used to determine when a story is complete. These acceptance criteria become a fundamental building block for Test Driven Development (TDD.)
- Need: As a ScrumMaster, I want to order a book from amazon so that I can learn advanced Agile concepts
- Conversation: I should be able to search book by title or author name and purchase it using my Visa card.
- Confirmations:Verify that confirmation email is sent and book is shipped within 24 hours.
INVEST in User Stories (reference Mike Cohn's presentation)
- Dependencies lead to problems estimating and prioritizing
- Can ideally select a story to work on without pulling in 18 other stories
- Stories are not contracts
- Leave or imply some ﬂexibility
- To users or customers, not developers
- Rewrite (most) developer stories to reﬂect value to users or customers
- Because plans are based on user stories, we need to be able to estimate them
- Sized Appropriately
- Complex stories are intrinsically large
- Compound stories are multiple stories in one
- Stories need to be testable
- Agile Rules of Thumb [rules]
- Introduction of user stories [presentation]
- Scrum Alliance on user stories [various articles]
- User story and backlog management [article]