General
User Stories are meant for a conversation or are a pointer to a conversation. Cards are intentionally small.
Short simple statements told from the perspective of the user. The story text we write on cards is less important than the conversations they trigger
Three C’s of User Stories
- Card (Stories are traditionally written on cards, Cards may be annotated with estimates / notes)
- Conversation (Details behind the story come out during conversations with product owner)
- Confirmation (Acceptance tests confirm the story was coded correctly)
Recommended Format
As …
So that … (Optional)
I want …
Conditions of Satisfaction
- Written on the back of the card. If these things are done, the story is complete.
- Can be considered as acceptance criteria.
- Mike Cohn prefers to call these conditions of satisfaction because it avoids the word “tests” instead of acceptance tests.
Details added in smaller sub stories
Big stories break down into smaller stories.
Small stories break down into conditions of satisfaction or acceptance criteria.
Useful Terms
Epic - a big user story
Theme - a group of related user stories
Story Writing Workshops
- Story writing workshops should happen every few sprints
- Whole team present
- Brainstorm to generate stories
- Have a boundary set on what will be discussed
- Start with epics and iterate
- Have a graphical arrangement or order to display them
Why are user stories a good thing
- User stories help us shift from doucments to discussion
- Myth that if requirements are written down, the user will get what they want
- Documents encourage you to build what they ask for, but not what they need - user stories encourage the opposite
- Words are imprecise (Entree comes with sour or salad and bread)
- User Stories are understandable (most people understand them, low training level)
- Support and encourage iterative development (start with epics and disaggregate close to development time)
- User Stories are the right size for planning
- User Stories support opportunistic design (Mix of top down and bottom up design)
- User Stories support participatory design
- By focusing on the system goals instead of the system attributes we are more like to build what we need
References
User Stories for Agile Requirements Video User Stories for Agile Requirements Slide Deck
