Thoughts on writing user stories
Basic story answers the questions: Who, what, why? As a I want so that ?
Alternative: In order to as a I want
Why you want to INVEST in stories: Independent?
- Easier to sashimi
- Avoids problems with prioritization
- Avoid volatile dependencies
- Explicit dependencies are OK
Negotiable?
- Avoid bundling - eg: VHS, DVD, Blu-Ray and HD DVD
Valuable?
- If it's not valuable, then don't do it.
- Why waste time on features that aren't valuable to most users?
- Try to front-load value during the planning
- "Waste is anything that does not add value" mary & tom poppendieck
Estimable?
- Well, you want to know when you're going to be done
- If you can't tell how long it will take, then maybe the story's not complete, or it's missing other info.
Sized?
- Also want to make stories the right size for completing in a sprint (iteration)
- Avoid absolute sizing - that's tough.
- Go for relative sizing - that's easier
- 20 ways to split stories http://xp123.com/xplor/xp0512/
Testable? "Writing a story card carries an implicit promise: " I understand what I want well enough that I could write a test for it." William C Wake Write acceptance criteria along with the story Documentation could be a simple bulleted list.
Stories vs Tasks Stories in the product backlog Tasks in the iteration backlog
Stories identified by anyone, owned by the PO Tasks are Identified by the delivery team, Owned by the individual
Stories are Completed in an iteration Tasks are Completed in an iteration
Stories Estimated in story points Varying levels of granularity Tasks Estimated in ideal hours Usually 2-16
Warning: beware of partial stories!