User stories are part of an approach that helps shift the focus from writing about requirements to talking about them. All user stories include a written sentence or two and, more importantly, a series of conversations about the desired website’s functionality.
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:
As a (type of user), I want (some goal) so that (some reason).
As a Registered Member, I want Members to login so that They may access a Membership list.
User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.
How is detail added to user stories?
Detail can be added to user stories in two ways:
- By splitting a user story into multiple, smaller user stories.
- By adding “conditions of satisfaction.”
Who writes user stories?
Anyone can write user stories. It’s the product owner’s responsibility to make sure a product backlog of user stories exists, but that doesn’t mean that the product owner is the one who writes them. Over the course of a good agile project, you should expect to have user story examples written by each team member.
This post was written by kadmin