How to write a user story
User stories are part of the Agile process. Agile development is iterative and broken down into sprints. Each sprint delivers “shippable product” – something that can actually be used by users, and which has business value.
A user story looks like this:
“as a [role], I want to do [task], so that I can achieve [goal]”.
A non-technical reader who knows nothing about the system should be able to read your user story and understand it.The user story should not describe the technical details of how the goal will be realised; this should be left to the developers. The aim of a user story is to describe how the system will deliver business value to the end users.
There are different types of user stories for different situations. You should write "epics" at an early stage, when you are working out the concepts behind the system, and the overarching problems you want to solve. Later, break your epics down down into more manageable user stories (features) at the point when you are nearly ready to start work on them.
|Bug||A story to fix an error in the software (doesn’t necessarily deliver new business value).|
|Epic||An overarching user story which describes a user’s main goals, and can be broken down into smaller user stories. Epics identify the user’s context and needs.|
|Spike||A time-boxed investigation of how to implement a particular feature. It should not occur in the same sprint as the story to do the work.|
|Feature||A user story which identifies a person with a role, who needs to do a task, which achieves business value.|
“identifies who the user is, what she needs, and why she needs it.”