One of the most popular formats for writing agile user stories follows this template:
As a [role], I want to [feature] so that [goal]
Many organizations translate this into a spreadsheet where each column represents a different field the story writer can fill in:
I have used this template on almost every agile project I have participated in. For the most part, it works very well. It typically provides a great launch point for additional discussions before it makes it into a sprint.
One of the most common mistakes I see when introducing the template (and agile stories in general) to a new team is a tendency to define every role as just a generic “user”. For example, I’ve seen user stories as generic as:
“As a user, I want to upload photos to a library so that I can use them on a post”
Although its syntactically correct, it is vital that we define a role and not a “seat” on the system. A more valuable user story would look like this:
user designer content author, I want to upload photos to a library so that I can use them on a post”
Notice how this story now has a better context of who will be using the feature and how. This could provide valuable insight into the intended audience and how best to implement the feature — a designer may imply more advanced features while a content author would use the image as is.
Always avoid the generic “user” role in your user stories.
Hope this helps.