There are many ways of writing a user story, and none of them can be considered the perfect way since the purpose of the user story might differ from project to project. There are some common guidelines that’s good to follow.
In general, the user story should be a short story that describes the needs or requirements of the user. A user story should always be written from the point of view of the user and should ideally not be too technical or specific.
If a story becomes too big one should consider splitting it into several stories. One example might be, to separate the actual login logic from lost password and create account stories, even though it all might happen in the same “page”.
Story title
The title should be simple, clear, and straight to the point. It should make it clear who, of what role wants to do what.
- As <role>
- I want <objective>
- For <motivation>
So, in the case of a login page the title should be something like “As a customer I want to be able to login to access the solution”.
Description
The description of the user story should give the title context. The goal here is to keep it simple, but still include the information needed so that anyone reading it will understand exactly what should be accomplished (on a high level).
The description field, in addition to the detail’s fields can be used to reference an attachment on the User story. Ideally only physical data should be referenced like images, pdf etc. Linking to 3d part site should not be done unless it’s supported by a physical upload as well, this to keep historic data should any 3d part link stop working at a later stage.
Acceptance criteria
Here the different test cases should be defined. Here one should not only include the “best case” scenarios, what happens when the customer is happy and has accomplished the task, but also what happens if an error occurs, or the user makes a mistake.
As a general rule, the acceptance criteria are a list of items that has to be verified and approved by those testing the user story. If one item isn’t fulfilled the story will fail the test and will not be considered ready for release.
In the case of the login page acceptance criteria might be:
- The username MUST have value, otherwise a relevant error message will be displayed
- The username MUST be in the form of an email, otherwise a pertinent error message will be displayed
- The password MUST have value, otherwise a pertinent error message will be displayed
The acceptance criteria should not contain a repetitive list of items/subjects covered by the project requirements.