User Story Format – with example

Are you seeking guidance on how to compose your user stories? Wondering which user story format to employ for your project? This article will elucidate the process and offer a multitude of recommendations.

User Story Format

In reality, there isn’t a standardized user story format that universally applies. The format you choose will hinge on your product and the associated requirements. However, initially, this task might not be straightforward. Let’s explore the process together in this article.
To start, a user story evolves from an epic. An epic is not merely a collection of user stories; rather, epics stem from initiatives. A helpful illustration by Atlassian aptly delineates this hierarchy:

initiatives / epics / user stories – user story format

Thus, when necessary, we decompose an epic into multiple stories. For instance:

epic: Product Page
story 1: Display the product sheet
story 2: Rate the product
and story 3: Comment on the product

However, we emphasize “user story” over “story” to concentrate on the user in the product backlog item. To facilitate this, a widely adopted user story format is as follows:

As a < type of user >, 
I want < some goal > 
so that < some reason >.

Alternative templates are proposed by some, which will be discussed in future blog entries.
With this user story format, let’s rewrite our stories to center them on users:

user-story 1: As a customer, I want to view the product sheet to access information about the product
user-story 2: As a customer, I want to rate the product to share my impressions with other customers
and user-story 3: As a customer, I want to post a comment on the product sheet to seek clarifications about the product

As evident, this process isn’t intricate. A small recommendation: ensure accurate user targeting.
Is this enough for the development team? Not quite…

The Management Rules

In your user story, the development team requires more comprehensive details regarding the request. For precise development aligned with the request, additional demand-specific details are essential. In project management, these details are known as management rules.
Some teams employ the A4 story format as a user story template. It simplifies the process of crafting all your user stories. This format is designed to encapsulate management rules in a concise manner. You can explore our article on story 4 for more insight.

story A4 – user story format

Testing in Our User Story Format

It’s imperative that your user story format comprehensively encompasses elements for the team to conduct thorough testing of each user story. Some consider management rules sufficient for testing, while others find them lacking.
Consequently, more teams are embracing acceptance testing to formulate their tests. They adopt the Gherkin format, similar to what’s used in the A4 story format.

Here’s an instance of a test written in Gherkin language:

Scenario: Add a product to my cart
Given I am on my cart
And I have a product with ID “1234” in quantity “1”
And the remaining stock for this product is “0”
When I add “1” quantity to my product
Then my cart will display an error

Given I am on my cart
And I have a product with ID “1235” in quantity “1”
And the remaining stock for this product is “10”
When I add “1” quantity to my product
Then my product will have “2” quantities

This approach is intriguing because it provides clear insights into expected behaviors for the development team. It enhances the likelihood of robust testing in accordance with all management rules.

Remember: each team should devise the most fitting user story format for their context!