RULE OF THUMB: User story consist of following 3 parts:
-
Need
: As a
, I want so that (~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.)
An Example
- 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)
I ndependent
- 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 reect 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
References
- Agile Rules of Thumb [ rules ]
- Introduction of user stories [ presentation ]
- Scrum Alliance on user stories [ various articles ]
- User story and backlog management [ article ]
No comments:
Post a Comment