The main component of an use story are the 3C’s:
Card
– what do you want, as a higher level
Conversation
- Who is the user, what he wants and why?
- What happens outside software? What can go wrong? (Happy path and exceptions)
Confirmation
- Acceptance tests
- How does the Product Manager validate the user stories once they are done? How will we demonstrate it at a product review? What will we test that is indeed done?
- Use user language, don’t be too technical
- What the user wants to do and not how it should be done
Stories can be written at many levels of abstractions:
Epic, Feature, Capability – Right sized for business
User story – right sized for users
Dev story, small user story – right sized for dev
Spikes
These stories are needed when you have to do some research work/knowledge gathering. It should be time-boxed and a clear definition of done. Most of the time, it is not part of the production code.
What is a good user story?
INVEST: These are guidelines to be used to create better user stories but don’t let them come in the way of building effectively.
- I – Independent
- N – Negotiable
- V – Valuable
- E – Estimable
- S – Small
- T – Testable