The entries in the Scrum Product Backlog are often written in the form of User Stories. A User Story tells a short story about someone using the product. It contains a name, a brief narrative, and acceptance criteria and conditions for the story to be complete. The advantage of user stories is that they focus on exactly what the user needs/wants without going into the details on how to achieve it. There are different recommendations how to define User stories.
A template could be as follows:
As an [actor], I [want|must] [action] so that [achievement] Or in a shorter version: As an [actor], I [want|must] [achievement]
Actor: The ‘owner’ of the user story. This is often a user but it is recommended to be more specific here. By using specific actors (e.g. “Administrator”, “Logged in Customer”, “Unauthenticated visitor”) it’s easier to understand and sets the user story into context.
Action: What the actor wants to do. If it is a mandatory action it can be prefixed by “must”. Otherwise “want” is used.
Achievement: What the actor wants to achieve by performing the action. This is the result from executing the action seen from the actor’s point of view.
A good user story example
As a <power user> I want to <edit the grade page of my class> so that < I can always have the most up to date grades for a student>
The story has a specific user. The goal is is small enough so that it will not be considered an epic. the reason is clear and shows the value the power user is trying to get.
A bad user story example
As a <user> I want to <backup the whole system regularly> so that < I never lose data>
Firstly the user is not specific enough. We need to know what type of user. Secondly the goal is far too large and vague. This would need to be broken down into a number of user stories.