While it’s easy to write “as a user”, there are many more parts to a great User Story, including:
The “User” in the User Story is a person, end user, customer or persona. It’s not:
Don’t use the User Story format when:
In these cases, use other formats like:
There is often a preference for how features will work. This is often based on business rules, compliance needs, or process-driven requirements. These are often written as “acceptance criteria”.
Write the acceptance criteria as bullet points
If the item needs to be delivered by a specific date, write the date and any related rationale as part of the acceptance criteria.
When there is a workflow or user experience that is expected of the User Story, write a this as acceptance criteria. GIVEN/WHEN/THEN format is useful pattern to use.
GIVEN I’ve got items in my shopping card
AND I get to the payment area
WHEN I enter the data
THEN it validates the credit card information
AND THEN I receive a message indicating the information is correct before it asks me to submit the data
Some of the benefits of using this approach:
When dealing with software development, many programming tools such as Cucumber and JBehave provide test features that accommodate tests defined in the Given-When-Then format. Though this is the case, the approach to testing business requirements is not limited to software products.
An estimation for each User Story provides the Product Owner with important information on:
Estimate the size of the work needed for the whole team to deliver to meet the Definition of Done.