The user story is the atomic functionality
of what the user wants to achieve
by delivering the business value
under system constraints. It can be derived under two domains: the business domain or the technology domain.
In my opinion, using INVEST is the best way to write an excellent user story. Here is what the acronym means:
I - Independent -
The story should be independently identified -- that is, defined at the atomic level. It has no inherent dependency with another user story.
N - Negotiable -
The user story can always be rewritten to respond to change.
V - Valuable -
The story should always deliver the business value.
E - Estimable -
The story should always be estimated in terms of size, in order to maintain the team's velocity.
S - Small -
It should be small enough to complete within the iteration. If its size is big, the story must be broken down into smaller stories as much as possible.
T - Testable -
The user story should follow test-driven development. Based on acceptance criteria, the test scripts should be developed first, before code is written, as the story should provide the necessary information to make test development possible.
The 3 Cs
The author of the user story can follow the "3 Cs" for writing a well-structured user story:
Card: As a <user>, I want to do <function>, so that I can achieve <business value>.
Conversation: The detailed description of the story needs to be included. This means its step-by-step execution, basic flow and alternate scenarios, mock-up design, etc.
Confirmation: This describes the acceptance criteria of the story. This means that the story is passed and accepted if the specific criteria for the story are in fact fulfilled in execution.
I have found these to be the most effective methods for writing excellent user stories.