The Product Owners and especially those who discover the profession often have an essential question: how to make a good user-story? And that’s why I present you this format that I find very interesting: the story A4 (I’m not the creator of this format).
All Product Owner will be able to tell you that writing a user-story is “As [persona], I want to [wish]” (an optional So that); however this format does not answer all the problems and it is not the goal.
If you want to know how to split a user-story, one of the essential steps in the creation of it, I suggest you to read this article before continuing:
Article : How to split his user-stories?
In a normal sequence, your Agile Coach will propose you to make a Definition of Done (and Ready) of user-stories to determine how make a complete user-story; we will also define the format of the user-story.
This is an article of the Definition of Done : Definition of Done (DOD)
An effective format in many projects
I remind you that this format will not necessarily adapt to 100% of your projects but I think it is applicable and effective in a good majority.
An A4 story format will contain:
Maintenant que le message est passé, voilà ce que contiendra une story A4 :
- An identifier (that of the software used is not bad)
- A type of story
- As [persona], I wish [wish] so that [goal]
- Management rules
- Acceptance tests
Here is the result on a nice A4 sheet if we want to materialize our user story. By displaying this on a wall, it allows to have a quick vision of how to write our user-story:
Software like Jira can perfectly adapt to this format, you will just have administrator rights. On Trello, it will rather use the description field and create boundaries as a sequence of ==== between each part.
Management rules ?
For those who just arrive in the job of Project Manager or Product Owner, here are the rules of management.
The management rules are the essential business rules for the development of this user-story. These rules are written in English with the aim of putting the minimum sentence; you will be more effective if you go to the simplest because developers will understand your requests faster.
Do not hesitate to use classic lists to facilitate readability and signs known to all. Here is an example below on a cart of an e-commerce site:
I add an additional element of a product in my cart.
– if quantity> stock then error “not enough stock available”
– if quantity <stock then add +1 to the quantity
You can admit that it is very easy to read like that; you understand directly the work to be done. If this case is relatively simple, the idea is to make it very simple especially for the most complex cases.
This part is a bit more complex to understand. We will create very structured sentences that will describe scenarios that validate the entire user-story.
The way to write it will be very important because the day you want to do BDD (Behavior Driven Development), everything will already be prepared.
Qu’est-ce que la BDD ?
Without going into detail, the BDD (Behavior Driven Development) is an Agile practice created by Dan North in 2003 that aims to create functional tests with a natural language understood by all.
This practice encourages a lot the bringing together of technical teams, functional teams and even business teams.
To put it simply, the BDD has as principles:
- The participation of non-technical teams in the project to write our functional tests
- Automated scenarios to describe behaviors to make non-regression
- Better understand the expected behavior for the technical teams.
How to write the scenarios?
Here is a first example of 2 scenarios that we will write for our cart of our e-commerce site (previous example):
Given I am on my cart
And that I have a product of id “1234” in quantity “1”
And the remaining stock on this product is “0”
When I add “1” quantity to my product
Then my cart will show an error
Given I am on my cart
And that I have a product of id “1235” in quantity “1”
And the remaining stock on this product is “10”
When I add “1” quantity of my product
So my product will have “2” quantities
We have two scenarios that meet the management rules that we wrote previously.
Quotation marks are essential because they allow functional test automation software to send variables to functions that have the program of the tests. Knowing that the sentences are identical but that only these elements change, the tools will know that it will be necessary to call the same function.
So as a Product Owner, do not change your sentences if you make two identical scenarios with the exception of specific elements as the quantity because this will allow you to capitalize on your tests as much as possible.
This famous language known by test tools like Behat or Cucumber is called Gherkin.
You already know a lot to start writing your tests as a Product Owner. I think that now all the Product Owner who will have passed through this page will now impress you.
Conclusion Story A4
Now, you have all the keys in hand to succeed in writing a complete and quality user-stories.